See minutes online for a more detailed record of the discussions. (The headers below link into the relevant sections of the minutes.)
(The meeting was cut shorter because the main speaker had to leave unexpectedly; the discussion topic is planned to be continued next week.)
Peter Kreutzberger, from MathJax, gave an overview of some of the latest developments.
The current Math WG at W3C has had a fairly low activity lately, essentially doing maintenance work only. Formally, the WG will have to be rechartered around March 2016; if the group continues to do maintenance work only, it may move into a Community Group instead. The question is what work should/could be done to move the current situation forward; this has also been discussed at the Math WG.
One area is connection with ARIA. ARIA has a glaring hole when it comes to mathematics, which makes accessibility very difficult. There is some interests from ARIA experts to fill this gap, although it is not clear whether similar interest is there from the MathML people. The other area of possible work connects to the Houdini work at the CSS WG, and would evolve around the problem mathematical layout in browser engines. The spec for math layout is very challenging in terms of CSS and this has to be looked at. There was not that much interest from the Math WG itself, but there is interest, for example, in the MathJax community. It may be possible to continue some work in the DPUB Interest Group (that, under a new charter, has the possibility to do more technical work).
One of the issue discussed was around the role of LaTeX, which is still a favorite syntax for many in the mathematical community; the question is whether that impacts the support of MathML. However, LaTeX is more about input, and can be mapped onto MathML; its relation to MathML is a bit like MarkDown vs. HTML. In this sense, this is not a real debate. Actually, publishers overwhelmingly prefer using MathML.
The level of MathML support in browsers came up. The “Can I use Math?” gives a misleading impression: WebKit went through several volunteers and failed to gain interest; Google/Chrome has some voice output but does not render Math. Gecko/Firefox is better, but they do not have their own developers on the code, it is fully volunteer effort. Although Mozilla does invest time to fix issues they create around it, but that is not enough.
MathML is very complex and math layout itself is complex, it expects a high level of typography that the Web does not yet have. Polyfill does not cut it yet, and the current implementations have major efficiency issues. Actually, the next release of MathJax may include some server side generation possibilities that may help. B.t.w., Readium includes MathJax, but many reading systems do not integrate them into their reader because they want to rely on Apple OS’s claim that they have support for it (but they don’t). Obviously, a polyfill approach also has issues with accessibility. )B.t.w., Benetech is busy setting up a description document, a matrix, showing what can be used for which engine.)
The discussion will continue next week.