W3C home > Mailing lists > Public > public-digipub-ig@w3.org > August 2015

Re: Fwd: [Moderator Action] RE: Active lobbying: Math

From: Doug Schepers <schepers@w3.org>
Date: Mon, 24 Aug 2015 17:43:14 -0400
To: Peter Krautzberger <peter.krautzberger@mathjax.org>, W3C Digital Publishing IG <public-digipub-ig@w3.org>
Message-ID: <55DB8FF2.3000706@w3.org>
Hi, folks–

MathML was developed a long time ago, in isolation from HTML and CSS.

I think we could really benefit from taking a look at _why_ browser 
vendors aren't implementing MathML, learning those lessons, and making a 
new version of MathML that's easier to implement and maintain, easier to 
author, easier to style, and is better integrated into HTML5.

I've voiced this opinion to Peter before. I don't think we differ much, 
and I think the years of experience the MathJax team and others have in 
implementing MathML in modern browsers could yield a lot more benefit 
than trying to push browser vendors to implement MathML as it is today.


On 8/24/15 3:47 PM, Peter Krautzberger wrote:
> Hi,
> This is a bit longer. Sorry about that.
> 1. Ivan suggested I should sum up what I've been involved in.
> * In 2013, when Chrome dropped WebKit's MathML code, we coordinated with
> our MathJax sponsors to reach out to Google management (non-publicly) to
> encourage the Chrome team to reconsider.
> * in 2013/14, MathJax looked into working on Gecko and WebKit directly;
> we could not find funding and we could not get WebKit companies to even
> have a discussion about long-term code ownership (let alone architecture
> or any other guidance). I'm aware of several efforts to find funding
> since then.
> * in 2015, the MathWG reached out to browser vendors to start a
> discussion of the overall situation; we put this on hold for lack of
> availability from the browser end
> 2. Regarding the discussion so far
> * re Paul Belfanti: "publishing at volume".
> I think from a browser vendors perspective, there will never be enough
> volume.
> * re Bill Kasdorf
>    +1 to all points. But also: publisher investments in MathML have been
> mostly internal. Not many have invested in polyfills, web development
> tools, web standards development, or browser development. Similarly for
> third party vendors.
> * re Paul Topping.
>  > I used all my votes for MathML but I am sure it didn't get many votes
> compared to other features.
> Actually, some features have fewer votes than MathML and get moved
> towards implementation.
>  > After MathJax, the problem is largely solved, at least from their
> perspective.
> This does not match my experience. Frequently, web developers are using
> MathJax's shortcomings as an excuse to dismiss MathML.
> * re Deborah Kaplan
>  > I want to stress that the push for native MathML is not out of any
> desire to get rid of MathJax.
> That's ok ;-) the MathJax project was designed to eliminate itself by
> encouraging browser support. But we'd also be happy to enable what comes
> after MathML 3.
>  > It is out of the need for publishers to be able to distribute native
> math that can be read by screen readers without users having to do
> anything special.
> This strikes me as orthogonal to native MathML rendering. Both exposing
> MathML to a11y interfaces and finding MathML-enabled AT are quite
> different (but equally messy) problems.
> Simply reading out MathML via MathML-enabled AT is theoretically easy;
> try the example at https://github.com/mathjax/MathJax-docs/issues/111.
> The much bigger problem is AT for visual users, e.g., sync-highlighting
> and exploration (see comment on ARIA below).
>  > Rather, the greater concern is non-browser-based reading systems,
> frequently used for textbooks, which have legal requirements for
> accessibility.
> How do you see browser implementations for MathML help here?
> * re Liam
> re (1) you make it sound easy ;-)
> re (3) is actually a huge, messy, overlooked issue; see my use cases on
> font metrics APIs for Houdini.
> re (4) I don't really think this is a big issue these days (although
> third party vendors are a different issue). TeX conversion has many
> options, Microsoft's own equation editor and Windows handwriting
> recognition can produce MathML, MyScript has great apps. Although
> high-quality MathML Editors are virtually non-existent (esp. if your
> focus is publishing on the  web) -- that probably means something?
> re (5) the examples are not quite right, I think, (long division etc is
> actually pretty easy in MathML 3 markup). But otherwise, yes.
> re (a) math content becomes quickly tabular and there's not a lot room
> for reflow in tables. But here's something fun
> https://github.com/mathjax/MathJax-RespEq
> re (c) the state of MathML accessibility is pretty messy, on both the
> content, browser, OS, and AT end.
> 3. Let me add a couple of entirely personal points.
> I think the main problem is that nobody really knows what it would
> technically require to implement good math layout in browser engines or
> what it would take to implement good MathML support.
> * Browser vendors have never worked on MathML.
>    * MathML in Gecko and WebKit has been almost exclusively implemented
> by unpaid volunteers
>    * Only Mozilla devs has actually supported its volunteer; they are
> the only knowledgeable browser devs regarding MathML.
> * In my experience, both browser vendors, publisher, and third party
> vendors have surprisingly little knowledge of
>    * MathML as a markup language
>    * math layout in general
>    * MathML layout specifically
>    * math layout using OWP tech
>    * math accessibility using OWP tech
> * third party vendors have a bit more knowledge of the first two but I
> sometimes see an incentive to keep things complicated (read: expensive).
> * The ARIA spec has a massive hole where mathematics should be.
> * Neither browsers nor publishers are active in the MathWG (ok, maybe 1
> exception).
> * The MathML spec needs some work in an HTML5 context
>    * MathML has been "out of sync" (for lack of a better term) with
> HTML/CSS/SVG for a while
>    * MathML duplicates HTML/CSS features (sometimes the features are not
> compatible though never critically so imho)
>    * MathML hides quite a few complex layout features behind math
> syntax, complicating the implementation of both
>    * ContentMathML has failed outside of CAS.
> Another key problem is: MathML is neither necessary nor sufficient for
> math layout on the web. Nowadays, HTML/CSS implementations are good
> enough for (high quality) math/MathML layout. I'm not speaking of
> client-side JS-driven rendering but of (server-side) HTML+CSS generation
> that looks the same on all recent browsers. (MathJax will introduce such
> a technology in our next release. It's not pretty markup code and it's
> not perfect but it works.)
> Personally, I don't think MathML will be implemented in browsers (though
> I'd be extremely happy to be wrong here and will support any effort in
> this group). I do think there are more realistic alternative goals such
> as improving CSS implementations incrementally and developing standards
> for exposing underlying data such as MathML to tools such as AT.
> Again, sorry about the length.
> Peter.
> On Mon, Aug 24, 2015 at 7:29 PM, Deborah Kaplan
> <dkaplan@safaribooksonline.com <mailto:dkaplan@safaribooksonline.com>>
> wrote:
>     On Mon, 24 Aug 2015, Paul Topping wrote:
>         Convincing them to implement EPUB would be a worthwhile cause.
>     Yes, absolutely.
>         Isn't the bigger problem convincing students and teachers to
>         adopt etextbooks?
>     I'm sure many of you here know the actual data, and anecdotes are
>     not data. But I do know that when I was a graduate student two years
>     ago, I had two choices: print, or the official electronic textbook
>     through our vendor, which was an epub which could only be read
>     through the vendor's reading system.
>     At that institution, in any case, the students and the teachers
>     aren't making the decisions. If you buy a textbook, you get the
>     electronic version as is delivered, which is usually EPUB.
>     But again, I'm sure many people on this list have the actual data.
>       (There was non-terrible accessibility on the reading system (since
>     it is an educational platform with compliance requirements), so it
>     was minimally usable without a mouse. But the textbooks were
>     unedited OCR, so I wouldn't have wanted to use them with a screen
>     reader.
>     That's a content problem, though. Unedited OCR isn't going to end up
>     with MathML markup no matter what the reader supports.)
>       Deborah
Received on Monday, 24 August 2015 21:43:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:36:08 UTC