improve display on mobile phones

[domel]

---

Preview | Diff

[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 https://github.com/w3c/rdf-star-wg/issues/61

[ktk]

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

[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 #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.