Media Specific Formatting Requirements

[wfree-aph]

Use media queries (media=) to determine if the hardware being used is a tactile tablet, embosser, refreshable braille display, or a visual screen.

Reading systems will need to incorporate this information into their software. Many reading systems will be made specifically for specific hardware, so should be able to bake this in. For example, a tactile tablet will likely have its own reading system that supports eBraille and will know that the hardware is a tactile tablet.

Multiplatform reading systems may have issues knowing which kind of hardware is being used if the hardware has no method for the query to be answered. Not sure how this part of it will work but it seems that hardware developers will need to add a means to answer these queries appropriately.

[mattgarrish]

Note that Media Queries 4 deprecates braille and embossed as media types (among others). These are now supposed to match nothing.

The spec points to media features as a replacement, but I don't see anything that would enable distinguishing between an embosser, braille display, etc.

[wfree-aph]

@mattgarrish Very good to know. That calls this method into question and we may need to figure out some other way to do what we need to here. Is it bad form to match embossers to "print" and dynamic devices to "screen"?

[bertfrees]

I don't think it is necessarily a problem that we would use media types ("braille" and "embossed") that existing user agents like browsers ignore. In fact it might even be desired. What matters is that the user agents that will implement our standard will not ignore them.

Note that according to the CSS spec, the media types "print" and "screen" will eventually be deprecated as well, "as appropriate media features are defined which capture their important differences". It's not very logical that "braille" and "embossed" were already deprecated, but it's also kind of understandable because these media types have probably never seen a real use.

So while on the one hand it's unfortunate that "braille" and "embossed" were deprecated, on the other hand we don't need to be concerned about compatibility with other user agents.

Until appropriate media features become available, I don't see another way to do it than to use the media types.

We could of course also come up with the necessary media features ourselves. This pretty much boils down to the same thing. The benefit would be that the custom features might be picked up in some next version of the CSS specification. This might become important if our hope is that browsers will implement the e-braille standard in the future.

If we are concerned about being able to view an e-braille file on a regular screen with the style sheet for a braille tablet applied, we can always do something like this (notice the comma on the first line):

<link rel="stylesheet" media="braille and (max-aspect-ratio: 3/1), screen" href="braille-tablet.css"/>
<link rel="stylesheet" media="braille and (min-aspect-ratio: 3/1)" href="braille-display.css"/>
<link rel="stylesheet" media="embossed" href="embosser.css"/>

Is it bad form to match embossers to "print" and dynamic devices to "screen"?

This is a possibility too, yes. The downside is that you won't be able to distinguish between a regular screen and a dynamic braille device, and between a regular printer and an embosser, but that might be acceptable because the principle goal of e-braille is to contain braille and to be renderable on a braille device.

[mattgarrish]

What matters is that the user agents that will implement our standard will not ignore them.

This is what worries me about straying from the current specs, although it sounds like the queries were never implemented anyway (and granted MQ4 is still only a working draft, so technically the values aren't yet officially deprecated, but it's a sign of where the web is heading).

If the idea is to leverage browser cores/css libraries to do the bulk of the rendering work (like epub), it probably means we'll have to define how these media types operate in practice, and it means anyone developing a renderer will have to have the skills to make the media types function in their respective environments. I personally don't do user agent development, so unknowns like this always give me pause. It would have been much nicer if something were already in place that we could leverage.

[bertfrees]

We now do some recommendations regarding media queries: https://daisy.github.io/ebraille/#media-queries.

• Discriminating between a braille display and a visual screen: technically the spec allows it, but eBraille creators are discourages to do so.
• Determining whether the hardware being used is an embosser: the spec allows it, but whether it will be possible will depend on reading systems.
• Discriminating between a tactile tablet and a refreshable braille display: in the spec we mention refreshable braille displays, but not tactile tablets. In which ways does a tactile tablet differ from a regular braille display?

[wfree-aph]

Great! Thanks @bertfrees! Closing these as resolved.