Over the Summer MathML was announced as an ISO/IEC International Standard.1 I was delighted by the news, since it might encourage better browser support for MathML (currently only Firefox has tolerable MathML support). I have been surprised, however, by how apathetic (and sometimes hostile) the community of math users on the web seems to be toward increasing this support. Much of the apathy/hostility seems to stem from a belief that math on the web is good enough as it is, largely as a result of the success of the MathJax project. I am a huge fan of what MathJax has accomplished, but I thought it might be useful to outline why I still think native MathML support in browsers is important.

Case study: Wikipedia

One hotbed of controversy regarding MathML and MathJax is Wikipedia. Sometime in the last couple months I noticed that Wikipedia switched from offering logged-in users math displayed with MathJax to math displayed with MathML. Searching around to find out more about this shift, I discovered a related task2 on the Wikimedia Phabricator. In the conversation, one of the user gave several reasons why MathML support is desireable:3

While having beautiful math is the ultimate end goal for the editorial staff, having accessible, fast to render, standards-compliant math are also valuable aspects that will feed a number of ecosystems. Having an HTML5 native solution is definitely the way to go forward in my mind.

At odds with these goals of accessibility, speed, and standards compliance is the fact that most browsers won’t natively display the MathML, so without MathJax they are left with the rather ugly PNG math presentation. One of the other commentators on the task expressed his frustration with that state of affairs in a reply to the above comment:4

I don’t care if it works in Firefox. It needs to just work, period. MathML is a distraction from that. It is diverting your attention from the actual problem, which is the not-logged-in view. MathML will never be the not-logged-in view and any developer work spent improving MathML is developer work wasted on not addressing the actual issue.

Fostering adoption

This highlights the chicken-and-egg problem inherent in getting MathML adoption: websites are not motivated to commit to MathML because browser support is so poor, and browsers don’t seem to be putting a lot of work into MathML because it is used so infrequently. A recent article in I Programmer suggested that MathJax itself is making browser developers ignore MathML:5

Now we know why browser makers are ignoring MathML. JavaScript in the form of MathJax does the job for them.

While I think the above statement is accurate, I don’t think blame should be leveled entirely at MathJax. The MathJax project lead offered a comment on the I Programmer article intending to clarify the goals of MathJax in relation to MathML:6

Saying that browser vendors don’t implement MathML because of MathJax is a bit odd from my perspective. One of MathJax’s original goals has been to break the cycle of no MathML support => no MathML in the wild => no need for MathML support.

One of the ways MathJax appears to make the transition to MathML difficult is that it allows websites to present math in LaTeX format, which MathJax then interprets and displays using HTML and CSS. This is how MathOverflow works, for instance. An alternative (while still using MathJax) is to present math as MathML and have MathJax interpret that (like this mathematics paper). Math presented in this second way is ready for a day when there is ubiquitous native MathML support, while math presented in the first way is dependent on MathJax.

The MathML interpreted by MathJax also allows those of us using Firefox to take advantage of the speed advantage of native MathML support. The above paper takes forever to load using MathJax, but using the MathJax Native MathML Add-on bypasses MathJax and allows me to load the paper almost instantly. When I see comments like We believe the needs of MathML can be sufficiently met by libraries like MathJax and doesn’t need to be more directly supported by the platform.,7 the biggest point of disagreement I have concerns rendering speed. I regularly run across papers that take an unacceptably long amount of time to load with MathJax, and do lots of symbolic calculations with Sympy in the Jupyter notebook that suffer from the same sluggish rendering times.

Usability

Another point made by the I Programmer article is that MathML is terrible to write:8

At this point you might want to object that verbosity is irrelevant because both MathML and LaTeX are going to be generated by programs. What might surprise you is that a large number of mathematicians write LaTeX almost as their first language. In this case it does matter how verbose a notation is.

As a theoretical physicist, I identify as someone who writes LaTeX almost as my first language, and yet I find this point irrelevant. I have never coded up a MathML formula by hand, yet I use MathML in many of my presentations. Tools like pandoc and Jupyter allow me to write math as LaTeX and copy it as MathML for use in web-based contexts. MathML is also capable of storing semantic information about formulae that might be ambiguous in LaTeX, so if I generate MathML with a package like Sympy and post it on my website, it is conceivable that someone could copy the formula and put it directly into another program. This difference between LaTeX (as simply a formatting language) and MathML (able to retain semantic information) is a big reason why LaTeX alone is not a solution for math on the web, despite some suggestions to the contrary.

Conclusions

I hope the recent ISO/IEC standardization of MathML will encourage browsers to take MathML more seriously, and that sites using MathJax will transition to serving their content as MathML rather than raw LaTeX, so that MathJax can more successfully fulfill its original goal of transitioning the web to MathML. I know the MathML support Firefox provides has made my experience with math in the browser much more pleasant than relying on MathJax for everything.

As I was writing this article, I realized that I was as guilty as everyone else of using raw LaTeX interpreted by MathJax on my site. In order to practice what I’m preaching, I have taken the step to present my mathematical content in MathML, which is then interpreted by MathJax to give cross-browser compatibility. Now when I load my first blog post in Firefox, the MathJax Native MathML plugin gives me a fast, browser-native presentation of my equations! The best part was that all I had to do was change out the pandoc --mathjax option for --mathml in my jekyll _config.yml. If you serve mathematical content on your site, I encourage you to take a similar step!

  1. W3C MathML 3.0 Approved as ISO/IEC International Standard, 2015-06-23↩︎

  2. T99369 Remove client-side MathJax rendering mode↩︎

  3. Comment posted 2015-07-19 by Dginev on task T99369↩︎

  4. Comment posted 2015-07-19 by DavidEppstein on task T99369↩︎

  5. MathML 3.0 Is An International Standard by Mike James, 2015-07-03↩︎

  6. Comment posted 2015-07-07 by Peter Krautzberger on MathML 3.0 Is An International Standard↩︎

  7. Comment posted 2013-10-29 by Ojan Vafai on Chromium issue 152430: Enabling support for MathML↩︎

  8. MathML 3.0 Is An International Standard by Mike James, 2015-07-03↩︎