Add section on CSS media queries and CSS restictions

[bertfrees]

@wfree-aph @avneeshsingh @mattgarrish @clapierre @GeorgeKerscher

This is not a PR yet. I first want to summarize what I'm about to write, ask whether it is in line with our previous discussion, and ask where exactly you think it should be put: in the formal specification, in a note, in the best practices?

CSS restrictions

Rather than restrictions, these could also be CSS features that authors may use but reading systems should ignore. In any case, I think these should be mentioned somewhere:

• Authors must use the relative length units em and ch for all lengths. There is really no reason to use absolute lengths, especially if the author has no control over the font (see next).
• Authors must not use font related properties. This is needed to be able to reliably use em and ch heights/widths in media queries (see below). There is no reason for the author to control the shape and dimensions of the braille dots anyway. That is a reading system/embosser thing.

CSS media queries

• When the target medium of a style sheet is a refreshable braille display (the main use case), the author should not use any media features that discriminate between a braille display and a screen. This comes down to not using at least screen, braille and grid[^1]. eBraille reading systems of type braille display must match either braille or screen, and should ideally match both.

  The logical consequence of this is that it is not possible to discriminate between visual and tactile access modes, in other words this decision forces rendering on a screen and on a braille display that are otherwise comparable, to be the same, and the CSS to have the same restrictions.

  Note that we don't recommend using braille, nor (grid), because there are currently no known implementations that match these, so requiring eBraille reading systems to match them could be problematic. Another reason to not recommend braille is because it is expected to become deprecated.

  We don't recommend using screen because we want to be forward-compatible with a possible future version of the specification that supports differences in styling for screens vs. braille displays, might that become a requirement.

• When the target medium of a style sheet is an embossed document, the author should use embossed.

  Alternatively, because embossed is expected to become deprecated, we could recommend using (grid) and (overflow-block: paged) and not (update) instead.

  We could also not mention embossers at all in the specification, as is the case right now, but I feel this use case deserves to be mentioned.

• To adapt the styling based on the dimensions of the viewport (or printable area of the page), the author should use the width and height features, with ch and em values. aspect-ratio might be another useful feature.

[^1]: grid is originally meant as a replacement for tty, but also applies to braille.

[mattgarrish]

I'm generally fine with all of this.

The only thing I wonder about is getting into embossing. You asked in the other pull request about mentioning the case in the intro. Maybe we should put it into the future directions section and mention there that we recommend not using the media type (and mention the possible alternatives), or at least to be aware that it may cause issues in the future and any use cases for it should be raised in the tracker. That way we don't accidentally paint ourselves into a corner with anything we say about it now.

[bertfrees]

OK, that sounds like a good approach!

[bertfrees]

OK, so how does this sound:

• Mention embossers: in Future directions
• About the use of media queries (in XHTML link and style elements, XHTML xml-stylesheet processing instructons, and CSS @media and @import rules): in a new section called "Media queries", after CSS support
• Recommend using relative lengths in CSS properties and in CSS media queries: in eBraille Styling Best Practices
• Explain why we omit certain standard CSS features, especially those that are not well supported in browsers: in eBraille Styling Best Practices

And what about these?

• Say that reading system are expected to ignore font-related CSS properties: should this go in CSS support?
• Clarify that reading systems are expected to apply default styles?
• Clarify that reading systems may apply styling through other means than CSS?

[bertfrees]

@mattgarrish Side question: how can ReSpec help us link from the best practices document to the main page?

[mattgarrish]

• in a new section called "Media queries", after CSS support

You could probably just make this a subsection of CSS.

The best practices have no weight, so if we recommend using relative lengths there then it's a bit informal. As it's only a recommendation and not a requirement, I'd be fine having this in the specification's CSS section.

• Explain why we omit certain standard CSS features, especially those that are not well supported in browsers: in eBraille Styling Best Practices

It might be worth a short note in the specification, that not all reading systems will support all features of CSS. EPUB does similar in its css intro. But if you think it'll take a lot of explanation, then maybe put a short note in the specification and expand on the details in the BP guide.

For these:

• Say that reading system are expected to ignore font-related CSS properties: should this go in CSS support?

Do you mean add a "should not"? I'm fine with that in the CSS section. If you want to also say that reading systems should ignore the properties, that should go in the reading systems section so we keep those requirements separate from authoring.

• Clarify that reading systems are expected to apply default styles?
• Clarify that reading systems may apply styling through other means than CSS?

I wonder if these belong in another subsection of CSS or perhaps in an introduction. Maybe we end up with:

Cascading Style Sheets (CSS)

• Introduction
• CSS requirements
• Media queries
• Reading system styling

Or possibly scrap the last subsection and the introduction is where we explain that not all CSS will be supported and that reading systems may apply their own default style sheets and/or modify the styling during rendering in other ways. See how it goes as you write it up, perhaps.

[mattgarrish]

Side question: how can ReSpec help us link from the best practices document to the main page?

You could create a local bibliography entry in the header metadata, although we don't have a stable URL for the document yet.

It would be something like:

   "ebraille": {
      "title": "eBraille 1.0",
      "href": "https://daisy.github.io/ebraille",
      "publisher": "DAISY Consortium",
      "authors": [
         "Willow Free",
         "et al."
      ]
   }

That should let you use [[ebraille]] for citations and <a data-cite="ebraille#some-hash">xyz</a> for linking.

(Edit: changed "url" to "href" in the entry.)

[wfree-aph]

I agree with what's being discussed here and appreciate how much you both know about this process. Only thing I'm wondering about is do we need to define what CSS features will not be supported? I'm not seeing that explicitly said anywhere and I just wasn't sure how that gets defined.

[mattgarrish]

what CSS features will not be supported

That's probably tough to do given the scope of CSS.

My inclination is to rely on the best practices to guide to steer authors to what they should be using and call out only the ones that if used are likely to be problematic, like the font properties.

[bertfrees]

Thanks for all the help!

• in a new section called "Media queries"

You could probably just make this a subsection of CSS.

My reasoning for putting it in a separate section was that media queries appear to be not necessarily tied to CSS. E.g. you could use a media query in JavaScript to enable functionality based on properties of the device. Or, the HTML media attribute can be used on other elements than style and link, e.g. you could have it on source elements to select different multimedia resources for different media queries.

As it's only a recommendation and not a requirement, I'd be fine having this in the specification's CSS section.

OK

• Explain why we omit certain standard CSS features

It might be worth a short note in the specification, that not all reading systems will support all features of CSS. EPUB does similar in its css intro.

OK makes sense. I'm planning to mention specific CSS features/modules in the BP that we deliberately omit or treat with care for now, but a short note in the specification seems appropriate too.

• Say that reading system are expected to ignore font-related CSS properties

If you want to also say that reading systems should ignore the properties, that should go in the reading systems section so we keep those requirements separate from authoring.

I was indeed thinking of saying reading systems should ignore the properties. Specifying all features that should be avoided/ignored might indeed be tough given the scope of CSS. That should not be an ambition. I'm hoping I can find a way to describe what we want to avoid (and show it in the BP) without going into the specifics.

• Clarify that reading systems are expected to apply default styles?
• Clarify that reading systems may apply styling through other means than CSS?

I wonder if these belong in another subsection of CSS or perhaps in an introduction. Maybe we end up with:

Cascading Style Sheets (CSS)

• Introduction
• CSS requirements
• Media queries
• (Reading system styling)

I was also thinking of eventually adding an appendix with a minimal default style sheet that user agents should apply, similar to https://www.w3.org/TR/CSS2/sample.html. Or this may end up along with all the locale-specific style sheets that we want to gather.

[mattgarrish]

media queries appear to be not necessarily tied to CSS.

Right, but the syntax is still defined by the CSS module. You could note that the restriction applies both within CSS style definitions and where media queries are used as a microsyntax, with a reference the relevant HTML section.

[bertfrees]

OK perfect.