- From: Bill Kasdorf <bkasdorf@apexcovantage.com>
- Date: Tue, 4 Oct 2016 14:47:21 +0000
- To: Florian Rivoal <florian@rivoal.net>, Paul Topping <pault@dessci.com>
- CC: Tab Atkins Jr. <jackalmage@gmail.com>, Avneesh Singh <avneesh.sg@gmail.com>, www-style list <www-style@w3.org>, "W3C Digital Publishing IG" <public-digipub-ig@w3.org>, Peter Krautzberger <peter.krautzberger@mathjax.org>
I think we may be drifting away from the original intention of the MathML MQ request. So here's a recap. --It came about because publishers, who often have MathML, do not put it in their EPUBs because they can't trust that it renders properly. They just put in images, which are inherently not accessible and typically not properly scaleable (they can be SVG but usually aren't). --MathML is _extremely_ widely used in STM publishing. It is considered the lingua franca for math. Perfect? No. But millions and millions of math equations currently exist, reasonably happily, as MathML within standard STM production and dissemination workflows. --This means that it _does_ work for much of what it is used for; just not well in browsers and most EPUBs. --One thing it works reasonably well for is accessibility. I remember being told by a member of the accessibility community a couple of years ago that, in the case of a student needing a physics textbook in accessible form, the difference between the math being in MathML or just images can be a difference of $50,000 worth of work and six months of delay to get her that book in a form she can use. THIS MATTERS!!!!! --We are looking for a way to make it safe for publishers to put their MathML in an EPUB so that it can be used for accessibility, even if it is not used for rendering visually. --We are NOT looking to see if every possible aspect of MathML is correct. We just need to know whether or not it is there, and to provide the reading system with information about whether or not to prioritize using the MathML or using the companion image. --MQ was suggested as a simple mechanism to enable that. Unless I'm mistaken, that's it. That's what we're looking for. Bill Kasdorf VP and Principal Consultant | Apex CoVantage p: 734-904-6252 m: 734-904-6252 ISNI: http://isni.org/isni/0000000116490786 ORCiD: https://orcid.org/0000-0001-7002-4786 -----Original Message----- From: Florian Rivoal [mailto:florian@rivoal.net] Sent: Tuesday, October 04, 2016 10:27 AM To: Paul Topping Cc: Tab Atkins Jr.; Avneesh Singh; www-style list; W3C Digital Publishing IG; Peter Krautzberger Subject: Re: [mediaqueries] MathML > On Oct 4, 2016, at 07:07, Paul Topping <pault@dessci.com> wrote: > > I will admit to not being an expert on media queries but is the state of MathML implementation in browsers really a deciding factor on whether there should be a math MQ? It doesn't help. If we were in a world where all browsers had a flawless implementation of MathML, and we were just trying to tell them apart from more primitive UAs with no support at all, then the mathml MQ would have an easier time. Arguments saying that MathML might not want to be the format you want to use for distribution anyway may still stand, but if you did want to use it you could at least rely on the MQ. If we were to devise an army of a few hundred MQs, allowing you to test every single feature of MathML you plan to use in a particular formula before deciding whether to show it or not, you could theoretically make a more informed decision, but it is unlikely that any author would bother writing such a beast, and even then, it still wouldn't tell you if the feature is implemented well. > I appreciate there's a difficulty in deciding how good an implementation must be but that is surely a problem shared by other complex media types. Isn't MathML's value in accessibility enough to justify the creation of a math MQ? I am not a good judge of this myself, but the opposite statement was being made: MathML is not semantic markup and therefore not very good at accessibility, and there are more capable alternatives (e.g. involving HTML or SVG together with ARIA). - Florian
Received on Tuesday, 4 October 2016 14:47:55 UTC