make entailment patterns mobile-friendly

[pchampin]

following @bert-github's advice, this PR changes the layout of the "entailment patterns" tables on narrow screens, making all the cells stack vertically.

Note that, in this layout, the text present on the tables' first lines ("if S contains", "then S entails") is then repeated in each "row", to keep them understandable.

Note also that, in fact, the text "then S entails" that is repeated in each "row" is slightly less precise than the original table header ("then S RDF entails, recognizing D", then S RDFS entails, recognizing D"). But it should be clear from the context which entailment we are talking about.

Injecting exactly the right text in the small-screen layout is possible but

• it would increase the amount of text, which on small screens is not necessarily the best strategy, and
• it would require ad-hoc CSS rules for each tables, which makes it harder to maintain; so I personally vote for keeping the more generic "then S entails" text.

---

Preview | Diff

[pchampin]

For examples of the change:

• https://pr-preview.s3.amazonaws.com/w3c/rdf-semantics/pull/40.html#rdf_entailment_patterns
• https://pr-preview.s3.amazonaws.com/w3c/rdf-semantics/pull/40.html#rdfs_patterns
• https://pr-preview.s3.amazonaws.com/w3c/rdf-semantics/pull/40.html#entailment_rules

[pfps]

Although the changes here are better than the font-size changes they have several problems.

First, the content changes as viewport width decreases. The document is very precise about which version of entailment is involved, and this is a very important aspect of the document, but this precision is ignored for small viewport widths. Further, as the viewpoint width decreases even more, line breaks appear at non-optimal locations resulting in non-optimal presentation.

Second, the breakpoint is just an arbitrary number and unrelated to whether horizontal scrolling is required or not. At the breakpoint there is still extra horizontal space available inside the current margins as well as often other possibilities for using less horizontal space such as, for some tables, putting the table header on two lines.

Third, there is space available outside the current margins. This space should be eliminated or impinged on before changing font size or presentation format. This problem is particularly striking when I view the document in portrait mode on my phone (which is middle-of-the-road device from about five years ago), with about 20% of the horizontal space being used for blank space and other non-content uses. This should be eliminated before doing anything about the tables.

Fourth, there are often better methods for displaying tables when viewport width is small. On my phone, again in portrait mode, triples are split between lines on some tables in the current editor's draft, which isn't great but looks better to me than either reducing font size or changing format.

Fifth, it is generally possible to zoom out to view content that extends beyond the edges of the viewport. This is under user control, and in my opinion a much better method than size or format changes that are not under user control. On many small screens it is also possible for the user to rotate the displayed document so that the larger side is in the horizontal direction. On my phone, all tables in the editor's draft can be displayed without going beyond the current document margins when in landscape mode.

What I would like to see is a style that has the following characteristics:

• when the viewport is large some of it is utilized for nice-to-have features such as blank margins, navigation buttons, and branding
• for smaller viewports these nice-to-have features become smaller and are eventually eliminated or displayed in a manner that does not reduce the maximum content width or height, permitting more content to be seen
• the user is provided with control over how to view content that does not fit into the viewport under the current display settings, for example by zooming out or rotating to a landscape view

What I view as unacceptable is a style that changes presentation settings based on a fixed value of a parameter of the viewport unconnected to whether there are any current problems with viewing current displayed content.

[pchampin]

First, the content changes as viewport width decreases.

As mentioned above, this can be fixed if the current behavior is deemed unacceptable (to the cost of slightly more complex CSS rules).

Second, the breakpoint is just an arbitrary number

No, it roughly corresponds to the point where the table starts to overflow in my browser. But I'm not surprised that other configuration have a different breakpoint, and I don't know how to make this better in pure CSS. And relying on Javascript for this kind of thing seems overkill...

Third, there is space available outside the current margins

Not sure what you mean, the new layout takes all the width it needs, in the limits of the viewport's width (see for example the RDFS patterns). The first table might give the impression that it is needlessly narrow, but this is due to <br>s in the text itself, not to the CSS.

Fourth, there are often better methods, [e.g. splitting triples between lines].

We are reaching a point where better is quite subjective here, I'm afraid. This PR has one objective goal (avoiding horizontal scroll on small screens) and one subjective premise (a vertical layout of table rows is better than smaller fonts or aggressive wrapping). We may collectively decide against the latter. The goal of this PR was to demonstrate that particular option.

Fifth, [leaving it to the user to zoom out or rotate their phone]

I sympathize with this argument, but the advice I got from @bert-github was that most users prefer not having to scroll.

for smaller viewports these nice-to-have features become smaller and are eventually eliminated

I wouldn't fiddle with the W3C banner or the table of content. They are part of the template of official W3C documents... It is not our prerogative to change that (but we can of course make suggestions ;).

[pfps]

On my laptop in a viewport width of about 2 13/16" the left margin is about 1/4" and the right margin is about 3/32". So the margins consume about 12% of a scarce resource. On my phone in portrait mode the viewport width is 2 9/16", the left margin is about 3/8", and the right margin is about 3/16". So here the margins consume about 22% of this scarce resource. If W3C is concerned about supporting narrow devices this resource should be better managed before anything else is done.

[pfps]

Here are two screenshots from my laptop showing part of the current content RDF 1.2 Semantics on a narrow viewport. Both screenshots are for Firefox tabs with the same viewport width and rendering options. (At least the rendering options are as close as I could make them. I can't guarantee that Firefox is doing something completely different in the two tabs, but the font size, etc., look to me to be the same between the two.) The first is the current editor's draft and the second is this PR.

Note that the first screenshot displays both entailment pattern tables with no non-explicit line breaking at all and the tables fitting within the current document margins. The second table actually does not use up nearly all of the width available for it and the first table has an obvious extra line break that would reduce the horizontal size of the table at the expense of only one extra line in the table header. The seond screenshot shows that the viewport width is under the value that changes these table displays to the narrow mode.

So at least in this case the narrow mode is used when there is no reason to do so.

[TallTed]

Fifth, [leaving it to the user to zoom out or rotate their phone]

I sympathize with this argument, but the advice I got from @bert-github was that most users prefer not having to scroll.

Rotating the phone is not scrolling.

Zooming out is not scrolling.

Rebutting points of contention requires direct focus thereon.

[TallTed]

I wouldn't fiddle with the W3C banner or the table of content. They are part of the template of official W3C documents... It is not our prerogative to change that (but we can of course make suggestions ;).

These elements scroll off the top as you scroll down the document.

Unless you are referring to sidebar navigational content, in which case they absolutely should be minimized, concealed, eliminated when the main content of the document requires the full screen width in order to be clearly presented.

[TallTed]

Here are two screenshots from my laptop

As before, these are hard to visually compare when stacked vertically, so here they are (both scaled down to 45% for github presentation) side-by-side —

     

In the first, I would absolutely advocate for a <br> in the middle of the third column header, i.e., changing then S RDF entails, recognizing D to then S RDF entails, <br> recognizing D, throughout the document.

In the second, I would advocate a line-break + indent between the bold header text and the un-bold cell text, something like this —

rdfD1 :       if S contains             xxx aaa "sss"^^ddd . for ddd in D       then S RDF entails, recognizing D             xxx aaa _:nnn . _:nnn rdf:type ddd .

Tangent 1 — We should make RDF entails recognizing (without comma) or RDF entails, recognizing (with comma) consistent throughout.

Tangent 2 — It is absolutely unclear that the block below is one sentence, because the RDF statement ends with . and the next phrase starts with a capital RDF.

For example,

ex:a ex:p "123"^^xsd:integer .

RDF entails recognizing { xsd:integer }

ex:a ex:p _:x .
_:x rdf:type xsd:integer .

I strongly advise using em-dashes to indicate continuations, something like this —

For example, —

ex:a ex:p "123"^^xsd:integer .

— RDF entails recognizing { xsd:integer } —

ex:a ex:p _:x .
_:x rdf:type xsd:integer .

Indents of such Turtle and other blocks can also help comprehension of such sentences.

[domel]

According to the minutes, I was supposed to prepare some screenshots (sorry I'm late, but I've been having health problems). Here are some screenshots of specs with tables.

1. Iphone13 iOS 17 Safari

A.

B.

2. Samsung S22 Android 12 Firefox

3. Google Pixel6 Android 12 Chrome

4. Vivo Y22 Android12 Firefox

5. Oppo A78 Android13 Edge

This problem affects most specs with the prefix rdf12, e.g., Turtle, N-Triples, N-Quads, etc. I propose changing tables to blocks on mobile phones. CSS:

@media (max-width: 600px) {
  #responsive-table {
    display: block;
  }

  #responsive-table tr {
    display: flex;
    flex-direction: column;
    margin-bottom: 10px;
  }

  #responsive-table td {
    display: block;
    width: 100%;
    box-sizing: border-box;
    text-align: left;
  }
}

HTML:

<table id="responsive-table">
...
</table>

In this example, when the screen width is less than or equal to 600px (you can adjust this value according to your needs), the table layout will change. The rows will become flex containers, and the cells will be displayed as block elements.

[TallTed]

In this example, when the screen width is less than or equal to 600px (you can adjust this value according to your needs), the table layout will change. The rows will become flex containers, and the cells will be displayed as block elements.

Assuming the flex containers work well for the small window size, is there any reason not to use them for all windows sizes?

[domel]

@TallTed yes you can use it every where, but I don't know why? If the table fits on a (large) displays, why change it (and get rid of the columns)?

[TallTed]

@domel -- I had thought this was focused on the "one column" tables which are already effectively column-less. My misread.

[pfps]

These screen shots appear to show that some tables at some screen widths extend past the right-hand margin. Given this, it seems to me that an acceptable solution should be that if this is the case, and only when it is the case, to use an alternative display mechanism. But to use an alternative display mechanism when the table does not overflow is, to me, not a good solution unless it can be shown that the alternative display mechanism is at least as good as the table one when the table does not overflow.

[domel]

@pfps Probably the only option for you to judge is to check it out. In my opinion, this is definitely a noteworthy solution.

[domel]

For those who have not dealt with RWD before, I suggest reading this (or at least glancing at the final conclusions).