W3C home > Mailing lists > Public > public-digipub-ig@w3.org > October 2016

Re: [mediaqueries] MathML

From: Ivan Herman <ivan@w3.org>
Date: Tue, 4 Oct 2016 05:59:25 +0200
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, 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>
Message-Id: <3ED4483C-5E88-47DF-8CDA-31AA4285C499@w3.org>
To: Paul Topping <pault@dessci.com>

> On 4 Oct 2016, at 00: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? 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?

The issue is how to ensure that the math content is displayed in some form. Ie, if the browser does include a MathML renderer, this is what one would want to use, otherwise (as a fallback) an image. How to put both formats into the code and ensure that what gets displayed is the optimal one for that specific environment? How to avoid that, for example, *both* the mathml content and the corresponding jpg image gets displayed? Or none of the two? (Alas!, the fallback image approach within MathML does not work; browsers that ignore MathML also ignore that feature as well.)


> 
> One of things that has held MathML back since its creation is that people keep coming up with excuses why it shouldn't be supported. Or they kick the can down the road by leaving it out of this version with a promise that it will be looked at next time around. This creates a chicken-and-egg situation. When MathML is not included in some web infrastructure standard, it is weakened. Later, people use such an omission as a reason why they don't need to support it in some other standard. Often this is due solely to lack of knowledge or someone willing to do the work.

I do not disagree with what you write, but I am not sure this is relevant for the original problem. The whole issue is to *use* MathML whenever possible, not the contrary...

Ivan


> 
> Paul Topping
> 
> Design Science, Inc.
> "How Science Communicates"
> Makers of MathType, MathFlow, MathPlayer, Equation Editor
> http://www.dessci.com
> 
> 
>> -----Original Message-----
>> From: Tab Atkins Jr. [mailto:jackalmage@gmail.com]
>> Sent: Monday, October 03, 2016 2:23 PM
>> To: Avneesh Singh <avneesh.sg@gmail.com>
>> Cc: 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>
>> Subject: Re: [mediaqueries] MathML
>> 
>> On Mon, Oct 3, 2016 at 4:52 AM, Avneesh Singh <avneesh.sg@gmail.com>
>> wrote:
>>> We have not defined this variant of MQ yet, but some of the facts that
>>> support it are:
>>> - Publishers are already using MathML in their production workflow. But
>> they
>>> have to comment it due to lack of support on consumption side. so,
>> MathML is
>>> already available.
>> 
>> Yes, it was stated by at least one of the publishers (I don't recall
>> anyone's names, I'm sorry) that they use MathML to initially
>> *generate* the equation images (in MathJax, iirc), then they include
>> the generated images in their actual publications.  They argued that
>> even if they could detect support for MathML, they would continue
>> using their current production method, as it ensures the math is
>> displayed as intended, and given the current state of browser/ereader
>> MathML support, they can't just assume that their MathML will be
>> rendered correctly.
>> 
>> This is an argument *against* providing a math MQ.  It argues that
>> MathML is useful as an authoring format, but is not (given the quality
>> of the current supporting implementations) worth using as a
>> publication format.  We similarly don't support Photoshop file formats
>> on the web, despite them being extensively used in authoring image
>> content; we instead rely on a handful of image publication formats
>> (png, etc).
>> 
>>> - JAWS and NVDA, the two most popular Windows screen readers support
>> MathML.
>>> It is also supported by Voiceover, but I remember the statement from
>> Peter
>>> that support in Voiceover is not up to the mark. So, assistive technology
>>> support MathML. It would need some more refinements, but the support
>> is
>>> there.
>> 
>> Per the discussion, this does not require MathML to be used to display
>> math; near the end several people discussed reasonable techniques for
>> using MathML (properly annotated) as a source of a11y info without it
>> having to be visually displayed.  So, this is also not an argument for
>> the MQ; at best, it's neutral on the matter.
>> 
>>> - The variant of MQ also give an option to fall back to alttext if the
>>> assistive technology does not support MathML.
>> 
>> This is already possible today with <img alt>, no?
>> 
>> ~TJ
> 


----
Ivan Herman, W3C
Digital Publishing Technical Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704





Received on Tuesday, 4 October 2016 03:59:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 25 April 2017 10:44:46 UTC