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

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> 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
>
>