- From: Robin Berjon <robin@berjon.com>
- Date: Tue, 4 Oct 2016 09:25:31 -0400
- To: Florian Rivoal <florian@rivoal.net>, www-style list <www-style@w3.org>, W3C Digital Publishing IG <public-digipub-ig@w3.org>
- Cc: Peter Krautzberger <peter.krautzberger@mathjax.org>
On 02/10/2016 22:47 , Florian Rivoal wrote: > - 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. Just as a data point: we actually do ship MathML to the client but we do so in such a way that irrespective of browser support the actual MathML is always positioned off-screen and an SVG rendering of it is shown instead. The DOM is basically: span[role="math"] math --> this is made _visually_ invisible svg --> this contains the pretties The reason we do this is because the content may get long-term archived, and in that case we want to maintain semantics as much as possible (even if it's Presentation MML, it tells you more than just some squiggles). I'm not saying this is particularly original, I just want to ground the discussion. Based on such markup, we could very easily use an MQ to switch between the two. We would, however, *not* make use of a media query. Using a MQ has two modes of failure: 1) Browsers only report support when their support is perfect: you never get any support. 2) Browser report support when it's roughly there: you have an unreliable predictor. Note that we've been there, with `hasFeature()`. I know that some resurrection of that idea is happening with `@supports`, but I remain suspicious. I think that feature querying can work when it is very granular, but the bigger what is being queried is the more room for interpretation and the less useful it is. The notion of having a MQ somehow responding to a user preference to get MathML instead of alternatives is IMHO possibly worse. If I'm a MathML fanatic I might turn it on and deprive myself of some beautiful SVG squiggles. Conversely, if I'm a normal person or a mathematician I might benefit from getting MathML instead of the horrendously pixellated, tiny GIFs that publishers seem to insist are the thing to do but I have likely never heard of MathML let alone of an option to prefer it. If I had a wish my preferred option would be to have the ability to mark up alternatives in HTML, a bit like <switch> but *without* the built-in behaviour: <alternative> <variant><math>...</math></variant> <variant><svg>...</svg></variant> <variant><img></variant> <variant>some long textual description</variant> </alternative> As an author I could specify my preferred option (perhaps just through order) but the browser could override me ("nope I don't understand that well enough", "my user actually prefers that one") and could afford users the option of switching between representations. That would match my publishing needs far better (and as a user I would also love the option to switch to text in many cases). I do however realise that this is a much more involved change. -- • Robin Berjon - http://berjon.com/ - @robinberjon • http://science.ai/ — intelligent science publishing •
Received on Tuesday, 4 October 2016 13:26:00 UTC