improve display on mobile phones

[domel]

---

Preview | Diff

[gkellogg]

Looks like some markup problems; dn inside dfn.

[pfps]

There are lots of changes that appear to be formatting. They should be separated out into a separate PR.

[pfps]

What does this actually do?

[TallTed]

Suggested change

	table { word-break: break-all; max-width: 80vw; }
	table { word-break: break-word; max-width: 80vw; }

[TallTed]

@pfps — I see only CSS changes — whitespace on several lines (looks like no effect on the stylesheet), and addition of one line (99):

table { word-break: break-all; max-width: 80vw; }

I think that should be break-word instead of break-all, as discussed in another PR, and have no problem with the whitespace cleanup.

@gkellogg — How are you seeing those "dn inside dfn" issues?

[TallTed]

@gkellogg's concerns came from the Echidna Auto-publish failure report, to wit:

  "file:/home/runner/work/rdf-semantics/rdf-semantics.w3c/spec/index.html":1535.7-1535.130: error: The element “dfn” must not appear as a descendant of the “dfn” element.
    "file:/home/runner/work/rdf-semantics/rdf-semantics.w3c/spec/index.html":1535.131-1535.285: error: Start tag “a” seen but an element of the same type was already open.
    "file:/home/runner/work/rdf-semantics/rdf-semantics.w3c/spec/index.html":1535.131-1535.285: error: End tag “a” violates nesting rules.
    "file:/home/runner/work/rdf-semantics/rdf-semantics.w3c/spec/index.html":1536.7-1536.103: error: The element “dfn” must not appear as a descendant of the “dfn” element.
    "file:/home/runner/work/rdf-semantics/rdf-semantics.w3c/spec/index.html":1536.104-1536.233: error: Start tag “a” seen but an element of the same type was already open.
    "file:/home/runner/work/rdf-semantics/rdf-semantics.w3c/spec/index.html":1536.104-1536.233: error: End tag “a” violates nesting rules.
    "file:/home/runner/work/rdf-semantics/rdf-semantics.w3c/spec/index.html":1536.269-1536.272: error: Stray end tag “a”.
    "file:/home/runner/work/rdf-semantics/rdf-semantics.w3c/spec/index.html":1536.269-1536.278: error: Stray end tag “dfn”.
    "file:/home/runner/work/rdf-semantics/rdf-semantics.w3c/spec/index.html":1536.269-1536.282: error: Stray end tag “a”.
    "file:/home/runner/work/rdf-semantics/rdf-semantics.w3c/spec/index.html":1536.269-1536.288: error: Stray end tag “dfn”.

Now, those errors appear to be about lines 1535 and 1536 —

  <p>Both of these can be handled by allowing the rules to apply to a generalization of the RDF syntax

— which clearly do not contain the tags flagged by Echidna.

Hopefully, once my change request is merged, which will re-trigger Echidna and PR-Preview, the issues will magically resolve, or the errors will be revised and point to lines that actually contain problematic tags.

[pfps]

These may all be the result of malformed XML around line 202. I'll put in a PR to try to fix the problem.

See #31

[pfps]

I'm leaving the needs discussion label, not because there hasn't been discussion but because the final version of the PR needs careful consideration.

[domel]

According to telecon and different suggestions, I've just changed CSS for the tables here. If you accept this layout for small devices, I will implement these changes in other specs.

[gkellogg]

Seems pretty readable across a variety of devices.

[domel]

I have prepared other PRs (some of them I improved more if needed). So I'm waiting for 'yes'.

[pfps]

I thought the changes were going to be conditioned on the type of device. Why is this not happening?

It appears that the width of tables are being restricted to 80% of something. This seems wrong to me. Why not allow tables to be as wide as that thing?

This document is not a very good one for testing out the changes as there are only a few tables with more than one column and none of them are very wide.

[TallTed]

Looks far better to me, overall. I see breaks are not happening mid-word. This does mean that some side-scrolling will be necessary in some smaller-windowed environments. Echidna errors appear to have been resolved.

@pfps — I'm guessing that "It appears that the width of tables are being restricted to 80% of something" because you see table { word-break: normal; overflow-wrap: anywhere; max-width: 80vw; }, where the 80vw does indeed limit the table width to 80% of the viewport, which is the browser window. However, if you have large viewports available, you should see that this limit is subordinate to other limitations, so doesn't actually come into play. If you have small viewports available, you should see that this limit doesn't get enforced because the unbroken words cause the table cells to be wider than this setting, to contain those unbroken words.

[pfps]

As far as I can tell, the 80vw is limiting the width of tables in some places and, again as far as I can tell, the limit is active. For example, in the PR preview for some window widths the RDFS Semantic Conditions table is narrower than the text width and some lines overflow when at the same width they do not overflow without the PR.

So, again, why limit table width?

[domel]

Because 80vw is the default width in respec for the content. Note that 10vw are left and right margin.

[pfps]

This does not match with what I see. With the PR the width of the RDFS Semantic Conditions table is narrower than without the PR. So if there is a change, how can 80vw be the default?

In any case, if 80vw is the default then there should be no reason to include it (as it would currently be doing nothing) and a good reason to not include it (as it would override future changes in RESPEC).

[TallTed]

if 80vw is the default then there should be no reason to include it

I wonder if it wouldn't be worth creating a (or a few) separate PR for testing, perhaps made against one of our documents with more tables, especially tables that are problematic before whatever CSS tweak we find to be best?

[TallTed]

@pfps — If you could provide links (including fragment ID) to the table(s) you're seeing as problematic, that will help me (and, I imagine, others) to dig into possible solutions.

[pfps]

As stated above, it's the RDFS semantic conditions table. As far as I can tell there is no direct link to it. I've always either scrolled through the document or searched for the caption.

[TallTed]

@pfps — Do you mean the table immediately above this anchor? (which should indeed have its own ID! as I've added in PR#33), that has only one column?

Or the table following this anchor, now also at this direct link from PR#33 that has 3 columns of odd widths (left and right columns have odd wraps, and center could lose a bit of width to eliminate those wraps)...?

[TallTed]

It's hard to see the difference between those screenshots, with them stacked vertically. This may be helpful to others:

wider, has bigger font in the tables	narrower, has smaller font in the tables

I agree with @pfps that this makes the tabular data harder to read, even at the substantially blown-up size seen in these screenshots, vs the font sizes seen in the actual document.

[domel]

@TallTed OK, I propose to accept the PR (which is about CSS) and open a new one to refractor HTML. Yellow, pink, etc areas are the tables, and they shouldn't be (in HTML a table element is for tabular data and it is not for tabular data). So I propose to change HTML tables there to block elements (that should look like the normal text including font size).

[TallTed]

@domel — I agree that the pictured tables shouldn't be tables. Replacing these with block elements seems reasonable, presuming the background and text color effects are preserved.

That said, I think that the font size changes observed by @pfps are likely CSS-related, so I think @pfps should look at the actually tabular data in the other tables, and see whether they do the same font-size-shrinking with the same action — as if they do, this issue #30 should remain open and the CSS driving that should be addressed.

[domel]

All 10 PRs follow the same font size rules as this PR. Of course, if you want, I can change it, but it will be an exception. The other specs (that you have accepted) do just that. So what is the final decision?

[TallTed]

@domel — Have you observed the font size changes reported by @pfps when changing windows sizes? They're a problem, wherever they may occur. I am surprised that they only occur (or have only been reported) in one document and by one user — so maybe we should check that by getting browser and OS details, which may be having an impact. Maybe we should have other people check with that browser on their own OS, and have that person check other browser(s) on their OS.

Please understand that I'm not deciding nor dictating anything — only confirming that an issue reported by another viewer appears to be an actual issue, which should be resolved by some means, and CSS seems the right place for that fix. Elsewhere, I've reported my observations that the CSS changes there appear to have had the desired effect, but other viewers may report differently, and their observations should not be treated as any less important than mine.

[domel]

@TallTed I can't agree that this is a problem, on the contrary, thanks to this, the text has a chance to fit on small screens. You can go into the style editor in your browser (probably by pressing F12) and check that increasing the font size destroys responsiveness (in all spec with tables). In short, I can't do it the way you want it.

RWD is not about making the website look identical on a small smartphone and a huge monitor on a desktop, it should look so that it is legible.

[TallTed]

Again, I did not say "increase the font size".

I (and @pfps) said "When the viewport/window reaches some width smaller than full-screen, the font size of the content of these tables gets smaller, while the font size of the surrounding body remains as it was."

That remains a problem.

[domel]

No, it's normal behavior if you have media queries. It's the main feature of media queries that when it grows to its size, it changes styles. In this case, among other things, font size. You will find it on all websites in the world.
The basic component of RWD is media queries. This is exactly what they were invented for "when the viewport/window reaches some width smaller than full-screen" the rules (eg font size) of the content of these elements (eg. tables) gets that rule (eg. gets smaller).

[TallTed]

You will find it on all websites in the world.

This is trivially provable as inaccurate. At best, it is accurate only for those web pages which use "media queries" which is far from "all websites in the world."

Further, your response to @pfps said that in his screenshots, the font sizes were identical throughout, and you couldn't understand why he saw otherwise. Now you're saying, the smaller font size in the tables is the desired and intended effect. @pfps and I are both saying, that is an undesirable and problematic effect!

[domel]

From the beginning I say that the font is smaller by I reduced it myself. Thanks to this, the spec is finally responsive and I can view it on my phone right now.

[domel]

However, I do not understand this fuss about fonts a bit, since you agree with me that the yellow areas should be rewritten in HTML (as a block elements) and then they will meet the assumptions of RWD and will have a large font. Everything you want.

[TallTed]

I guess we should table this set this discussion aside for now, and see how the remaining tables look after the shouldn't-have-been-tables are made into blocks.

[pfps]

From a recent version of the PR:

 @media (max-width: 850px) {
        table th, table td { font-size: 12px; padding: 3px 4px;}
        .othertable {padding: 4px;}
        img {max-width: 85vw;}
    }  

So, although I am not a CSS expert by any means, it appears to me that the font size of all tables was forcibly changed to 12pc from whatever it would otherwise be when the window width was under a certain value. In all cases that I managed to test, this resulted in smaller fonts in tables.

Why did no-one else notice? Probably because they didn't test this PR where it actually changed the display of the document.

[domel]

Not true. Here is the recent version

    @media (max-width: 550px) {
        table th, table td { font-size: 14px; padding: 3px 4px;}
        table td.semantictable, table td.ruletable { font-size: 14px;}
        .othertable {padding: 4px;}
        img {max-width: 85vw;}
    }  

[pfps]

See w3c/rdf-star-wg#61

[ktk]

@pchampin will talk to the accessibility team at W3C to get some input on the issue.

[TallTed]

I would like the dynamic font size change to be removed. I may request other changes if that resizing is determined to be appropriate by a11y/accessibility folks.

[pchampin]

Trying to move forward with this...

1. I believe that before making this document mobile-friendly, we should ensure that we are happy with the base HTML/CSS, which I believe is not the case (e.g. many 1-column "tables" should probably not use <table>).
2. Then, we need to determine what is the best way to make the documents mobile friendly
   To that effect, I reached out to W3C CSS/a11y people, still waiting for their response.

In the meantime, I think the problem of this PR is that it tweaks too many parameters at the same time (wrap, font-size, width). My strategy would be to change one parameter at a time, and evaluate at each step the pros and cons.

As an example:

• changing the font-size below a certain viewport width seems to be controversial, because what is gain on one side (it helps the table to fit in the screen) is lost on the other side (the whole text of the table is smaller, so harder to read)
• likewise overflow-wrap: anywhere is a two-side sword: this has pros and cons in terms of readability

[pfps]

@pchampin I don't understand what is wrong with one-column tables. I also don't know what would replace one-column tables.

[domel]

@pfps As I wrote few weeks ago, now there are some places in the spec that use table elements but semanticly they are not a tables. They are blocks so it should uses block elements e.g. section elements. Thanks @pchampin for writing this obvious truth.

[pchampin]

@pchampin I don't understand what is wrong with one-column tables. I also don't know what would replace one-column tables.

• All axiom "boxes" (on lavender background) contain a single cell. They hardly qualify as "tables".
• The "boxes" containing semantic conditions (on yellow background) are more akin to lists than to tables, MO.

I agree that the difference can be blurry and somewhat subjective, but a pedantic reading of the HTML spec excludes the use-cases above:

The table element represents data with more than one dimension, in the form of a table.

(emphasis is mine)

[pfps]

I'm a bit puzzled how tables can represent data with, say, 1000 dimensions. So I don't give much weight to that statement.

As far as I can tell, tables are good for representing sequences in a way that emphasizes the commonality of the elements of the sequence. However, if there is a way of showing a sequence that puts the elements in equal-width boxes with no extra space between them, I'm not adverse to changing the HTML (even though it will be a pain for essentially no gain).

There are several tables that have multiple rows and multiple columns so it seems that there is content that is ideally suited be tables.

[domel]

However, if there is a way of showing a sequence that puts the elements in equal-width boxes with no extra space between them, I'm not adverse to changing the HTML

Yes, it is very easy to replace with any block element.

[pfps]

Can someone provide me an example of how a block can be used to substitute for one-element and one-dimensional tables?

[pchampin]

I discussed this issue with @bert-github, and my take-home messages are the following:

• we should indeed try to avoid horizontal scrolling on small screens
• reducing the font size and changing word wrap are however last resort solutions
• another option to make tables mobile friendly is to change their layout on small screens; I made a proposal in that sense make entailment patterns mobile-friendly #40
• the lists of axioms (example) and of semantic conditions (example) are not semantically tables, and should rather use other tags (typically <ul>). Note that this could be done while keeping the exact same presentation.

[pfps]

The remaining problem is that changes were made to the other documents, contrary to what was supposed to happen. These changes should be undone.