- From: Dave Cramer <dauwhe@gmail.com>
- Date: Mon, 8 Oct 2018 13:37:16 -0400
- To: "Brian O'Leary" <brian@bisg.org>
- Cc: "McCloy-Kelley, Liisa" <lmccloy-kelley@penguinrandomhouse.com>, public-publishingbg@w3.org, AUDRAIN LUC <LAUDRAIN@hachette-livre.fr>, "Johnson, Rick" <Rick.Johnson@vitalsource.com>
On Mon, Oct 8, 2018 at 12:09 PM Brian O'Leary <brian@bisg.org> wrote: > With respect to agenda item 4, I heard from two education publishers at a Firebrand community conference that the lack of Math ML support in certain browsers was a deal-breaker in their use of EPUB. I'd given a talk that I'll post next week that included advocacy for EPUB and other standards, and they provided real-life feedback. It's a supply-chain problem that the W3C could use as an argument for membership if they can find a path forward with various players, particularly device manufacturers and browsers. I think we've had poor and confusing messaging around ends and means, when it comes to MathML. If I'm an educational publisher, my goal is not to present MathML to my readers. My goal is to present math to my readers. MathML isn't magic, and doesn't guarantee accessibility. But how to handle getting math to readers is very much part of what W3C should be doing (and is, to some extent). This will likely be part of the EPUB 3 CG's best practices. Peter K. talks to the CSSWG about what low-level CSS features would make it easier to display math. WPUB or EPUB will eventually have a sane security model, so JavaScript could work, and thus MathJax. Extensions to browser markup (custom elements) or rendering capabilities (Houdini) could help. Ultimately I think all domain-specific languages will just compile to SVG (with appropriate a11y support) and be displayed in the browser that way. We have lots of ways of making progress that don't involve convincing browsers to natively support MathML. Dave
Received on Monday, 8 October 2018 17:37:48 UTC