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

> Begin forwarded message:
> 
> From: Paul Topping <pault@dessci.com>
> Subject: [Moderator Action] RE: Fwd: [Moderator Action] RE: Active lobbying: Math
> Date: 25 Aug 2015 01:04:42 CEST
> To: Richard Schwerdtfeger <schwer@us.ibm.com>, Doug Schepers <schepers@w3.org>
> Cc: Peter Krautzberger <peter.krautzberger@mathjax.org>, "W3C Digital Publishing IG" <public-digipub-ig@w3.org>
> X-W3C-Hub-Spam-Status: No, score=-8.6
> 
> With MathJax there is a huge amount of MathML content out there. Of course, this is all relative but I would challenge anyone to say that MathML is not important. Besides, there is the obvious chicken-and-egg situation here. How can a browser maker say that MathML is not used when people can’t put MathML in their pages because browsers don’t implement MathML? There are a lot of tools that produce MathML. Most people just don’t know it. Around 90% of all math submitted to scientific journals is in Microsoft Word format and uses either its built-in equation format or my company’s MathType equations. Both of these formats are readily convertible to MathML. The rest of the equations are LaTeX and there are lots of LaTeX-to-MathML convertors out their. I could go on but I can’t buy the “no MathML demand or content” argument.
> 
> I don’t see the performance issue either. MathML rendering performance is only an issue for pages containing MathML. Performance was never an issue in MathPlayer in IE. We did rendering tests where we displayed 30 simultaneous windows full of equations in just a couple of seconds. It was orders of magnitude faster than a human could open windows and read them. I am sure the Firefox implementation was just as fast. MathPlayer is a lot slower due to JavaScript but even more due to the hoops it has to jump through because it is not a native implementation that is part of the browser.
> 
> Paul Topping
> 
> From: Richard Schwerdtfeger [mailto:schwer@us.ibm.com <mailto:schwer@us.ibm.com>]
> Sent: Monday, August 24, 2015 3:40 PM
> To: Doug Schepers <schepers@w3.org <mailto:schepers@w3.org>>
> Cc: Peter Krautzberger <peter.krautzberger@mathjax.org <mailto:peter.krautzberger@mathjax.org>>; W3C Digital Publishing IG <public-digipub-ig@w3.org <mailto:public-digipub-ig@w3.org>>
> Subject: Re: Fwd: [Moderator Action] RE: Active lobbying: Math
> 
> What I have heard from some browser vendors is that there is just not enough MathML content out there and it is difficult to justify the performance hit. I believe this is due to a lack of easy to use authoring tools for Math that could be made available to educators. That is starting to change.
> 
> I sit on a Technical Advisory Board for Namo Interactive. Their Namo Author EPUB authoring tool has some phenomenal templates for math (this is not a plug) that are easy to use by educators that help promote MATHML in their EPUB authoring tool. There is also the chicken and egg problem that because we did not have a lot of MathML generated on the web that the browser support has been dropping off. Readium is building math support into their EPUB readers which will help fill some of those gaps. This will result in greater use of digital math in education. I think the adoption of EPUB is going to grow greater adoption of MathML.
> 
> Rich
> 
> Rich Schwerdtfeger
> 
> Doug Schepers ---08/24/2015 04:43:56 PM---Hi, folks– MathML was developed a long time ago, in isolation from HTML and CSS.
> 
> From: Doug Schepers <schepers@w3.org <mailto:schepers@w3.org>>
> To: Peter Krautzberger <peter.krautzberger@mathjax.org <mailto:peter.krautzberger@mathjax.org>>, W3C Digital Publishing IG <public-digipub-ig@w3.org <mailto:public-digipub-ig@w3.org>>
> Date: 08/24/2015 04:43 PM
> Subject: Re: Fwd: [Moderator Action] RE: Active lobbying: Math
> 
> 
> 
> 
> 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.
> 
> Regards–
> –Doug
> 
> 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 <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 <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> <mailto: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
> >
> >
> 


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