RE: [mediaqueries] MathML

Be aware that "MathML has been stagnating for a long time, and implementations do not seem to be making much progress" probably refers to MathML implementation in web browsers and is a fair statement in that context. However, MathML is actively used by publishers.

Paul Topping

Design Science, Inc.
"How Science Communicates"
Makers of MathType, MathFlow, MathPlayer, Equation Editor
http://www.dessci.com


> -----Original Message-----
> From: Florian Rivoal [mailto:florian@rivoal.net]
> Sent: Sunday, October 02, 2016 7:47 PM
> To: www-style list <www-style@w3.org>; W3C Digital Publishing IG <public-
> digipub-ig@w3.org>
> Cc: Peter Krautzberger <peter.krautzberger@mathjax.org>
> Subject: [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 14:47:32 UTC