[mediaqueries] MathML

During TPAC at the join session between the CSSWG and the DPUB-IG, I was actioned to write the specification for a media query indicating support for MathML.

This was based on a statement from the DPUB group that such an MQ would be useful in addressing a number of epub/publication related use cases. The central thesis being that without such an MQ, and in environments where JS cannot be counted on, there was no good way to provide fallback content for MathML, and that therefore content authors simply defaulted to providing the fallback only (typically an image), without including the MathML at all.

During an ad-hoc (and unfortunately not minuted) follow up session at the end of the day attended by a few math and dpub people, as well as Tab and I on the CSSWG side, it became clear that there wasn't actually a consensus that this MQ would be useful.

Peter Krautzberger (CCed) has written his take on this here https://www.peterkrautzberger.org/0190/.

My understanding of what was said in that session is:

- MathML implementations vary significantly in quality and in their coverage of the specification. Having such an MQ would allow filtering out UAs that don't support MathML at all, but would not change the fact that those who do don't do it well enough.

- Even though MathML is markup, and therefore more amenable to support by screenreaders than plain images, it is not actually a good format for accessibility purposes, and screen reader integration is not that good either. Alternatives such as HTML or SVG representations of the content with sufficient ARIA annotations can give better results.

- MathML has been stagnating for a long time, and implementations do not seem to be making much progress. There is no reason to believe that implementations (either visual or screen readers) will improve sufficiently any time soon (or ever) to make the previous two problems go away.

- While a number of publishers do express the desire to use MathML in production and would welcome the help of such an MQ for doing that, most of those who have actually tried to use MathML in production give up after testing shows that neither the presentation nor the accessibility is up to their expectations, and therefore go back to publishing math in some other form (images, svg...).

- MathJax, while itself incomplete, seems to be the only MathML implementation people are willy to rely on for production content. While the MQ with the proposed API would enable detection of math support either natively or by script, if the only usable environment is the script based one, the MQ is not needed.

- A variant of the MQ was proposed. It would instead mean that MathML was supported AND that the user expressed explicit preference for MathML content (via a setting of some kind). This would be useful in an accessibility context for users who know the strengths and limitations of their environment, and based on that make a judgment call that a MathML rendition would serve them best. While this MQ wouldn't be wrong or harmful, it doesn't really change the fact that MathML is not great for accessibility and that there are better alternatives, and that implementations and integration with screen readers are not great either, so it would not be terribly useful.

I do not know nearly enough about MathML, Aria, accessibility or publishing to be a good judge the validity of these various statements, but they were made by people who, like Peter, should know what they are talking about. My conclusion is at the very least that there is not a clear consensus in the Math/publishing community about whether this MQ is a good idea.

Because of this, I do not plan to write the specification for this MQ for now. I encourage people who still think it is a good idea to talk to people who think it is not (Peter is probably a good representative of that position). Convincing Peter is not a prerequisite for putting this MQ back on track for standardization, but coming up with good counterpoints to his arguments probably is.

Detailed example uses (here is the markup, here is the CSS, here is kind of user would benefit, here is an environment where it would produce useful results, here is why this is better than alternative approaches) would also be very much appreciated.

 - Florian

Received on Monday, 3 October 2016 02:47:31 UTC