W3C home > Mailing lists > Public > www-style@w3.org > October 2016

Re: [mediaqueries] MathML

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 4 Oct 2016 11:02:02 -0700
Message-ID: <CAAWBYDBhRQg3yeFC6gLKxHyo7c6ZR+gcsV6UUpCc4anAMYmoHw@mail.gmail.com>
To: Paul Topping <pault@dessci.com>
Cc: Avneesh Singh <avneesh.sg@gmail.com>, Florian Rivoal <florian@rivoal.net>, www-style list <www-style@w3.org>, W3C Digital Publishing IG <public-digipub-ig@w3.org>, Peter Krautzberger <peter.krautzberger@mathjax.org>
On Mon, Oct 3, 2016 at 3:07 PM, 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? 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?

No.  The deciding factor is whether people actually want to *use*
MathML for displaying equations, in the UAs that support it.  Based on
discussion with publishers, it looks like the answer is "not really",
because of the poor quality of implementations; they'd rather use
MathML with a high-quality renderer to produce the equation once, then
just use the rendered result directly, as it means they don't have to
test all the UAs to ensure every equation display correctly.
(Contrast this with SVG - the implementation quality for SVG is
sufficient that people are fine with using it as a display format
directly, even tho rendering it to a raster image would give them more
control and assurance that it was correct.)

Every feature we add has a cost, and must be justified by sufficient
benefit.  If MathML simple isn't being used much as a display format,
then we don't need to worry about catering to it yet.  Yes, this is a
bit of a chicken-and-egg issue, but most things are; we can't
preemptively support everything just in case one of them becomes

Received on Tuesday, 4 October 2016 18:02:55 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:15:01 UTC