A few days ago the MathJax consortium released a white paper called "Towards MathJax 3.0" (pdf). With my sinuses again in a reasonable condition I decided to read it, and see what it means for the average user. If you are an average user but don't care about why things are the way they are, you can skip to the changes.

Introduction

The question that is answered is:

"What do we expect from MathJax 3.0?"

It is actually interesting to first explain what the answer to this question was for version 1.0 and 2.0.

One should be aware that there is something called MathML which is a web standard for producing mathematical formulas on the web, just like HTML is a standard for producing what are basically hyperlinked text documents. But an important difference between these standards is their implementation. Whereas HTML is widely implemented, MathML has been largely ignored. I remember experimenting with it around 2005 or so, and back then I was happy if I could render something like $a^2+b^2=c^2$ properly. This was not only because of me: to render MathML you either had to use some obscure Internet Explorer plug-in, or use beta versions of Firefox (if I remember correctly).

Also, it is quite hard to produce MathML by hand, but that is not the point of the standard anyway. MathML is a mark-up language, so some level of semantics is contained in MathML code, unlike for instance LaTeX code which is purely a way of typesetting things. There is Presentation MathML vs. Content MathML, but let's not go in to that here.

It is safe to say that not much has changed. And this can be seen as part of a vicious cycle: because there was no browser support for MathML, not much content was produced using MathML, so there was no need to implement browser support for MathML, etc. Because of this we have seen the rise of tools to render LaTeX on the web, first by generating pictures on the server, later by rendering it using JavaScript (but observe that MathML was not related to any of these).

The original goal of MathJax was to break this vicious cycle. This was done by implementing MathML support using JavaScript, thereby circumventing the lack of browser support to obtain widespread MathML adoption, and spurring browser vendors to provide native implementations. In other words, the goal of MathJax was to make itself obsolete.

A convenient side effect of MathJax was a very good implementation of LaTeX mathematics for the web, which is the use case most often encountered (at least by me). But this is done via implementing MathML, and translating LaTeX to MathML, not directly rendering LaTeX as was the case before.

What is going to happen with MathJax 3.0?

The main point of the white paper is to re-evaluate all this, and whether it makes sense to keep this original goal. Depending on this two paths for the future of MathJax 3.0 are described.

But first it is made clear that the future of MathJax ought to be more modular with easier integration in other frameworks, and less of a complicated framework itself. The current structure of MathJax also reinvents the wheel at some points, for which external libraries are now available.

This can be achieved in two ways. One is focused on further enabling browser development as before, and continuing making MathJax a tool for a positive feedback loop for MathML. This is probably the most desirable approach, but it comes with great technical difficulties, and it is very naive to think that browser vendors will change their view towards MathML given that no browser vendor has worked or is planning to work on implementations and support for volunteer efforts is virtually non-existent.

The other path is to use the current HTML5, SVG and CSS3 implementations (which are very good indeed, across all browsers) to provide a MathML interpretation using MathJax, which was (maybe unfortunately) the current state of affairs anyway. And this is the path that will be taken for MathJax 3.0. The following quote from the conclusion sums this up nicely:

... - to no longer consider native HTML support in browsers an achievable of goal of MathJax.

Going down this path has a few effects on how MathJax is currently used, and how it affects you.

Changes

So what is going to change? Let me describe this from the point of view of the average Stacks project user, but it also applies to e.g. Wikipedia. Use cases such as formulas in ebooks or interactive mathematics environments such as SageMath can be discussed elsewhere, by someone who is more knowledgeable about these.

Nothing

To quote the white paper:

We can easily continue to supply compiled packages allowing the average users to use MathJax as they do today – inserting one line of JavaScript into their header and "forgetting" about it.

So if this is the way you use MathJax, and you are happy about it, you can go on using MathJax this way. The overhaul of the whole system will not preserve backwards compatibility, but that is something for the developer to be wary of. If you use MathJax to render mathematics on your weblog or spice up your personal webpage, you will be fine. Nothing will change in this respect (although it might turn out to be faster, or more compatible with special fonts, or ...)

Server-side MathJax

It should become possible to "pre-render" MathML on the server, and send out the appropriate HTML, SVG and CSS to the browser without passing through a JavaScript render phase. This might seem backwards at first, because it reminds us of ugly picture rending of LaTeX (of which WordPress.com is unfortunately still guilty...). But it is important to note that it will not replace the current client-side implementation, as explained in the quote above. And the result will be of the same high quality of the client-side implementation.

But e.g. for the Stacks project this will be a very interesting development. We have some rather lengthy pages, with lots and lots of mathematics on them, and these can be a performance hurdle for recent computers let alone for smartphones. It would be interesting to see if pre-rendering is feasible for the number of pages (and regular updates) that we have. Of course, client-side MathJax will not become obsolete for us, e.g. because of the comment preview.

Not just formulas

The Stacks project heavily depends on XyJax, a MathJax add-on for rendering xypic, for rendering commutative diagrams. This is an awesome plug-in, and what it accomplishes seems almost magical to me. But xy is a difficult language to implement, and it is only a partial implementation anyway, so sometimes we encounter some weird behaviour in diagram rendering.

If MathJax goes more heavily into using SVG, it becomes possible to improve the rendering of diagrams. Not much is said about this, but it is interesting to see any improvements to commutative diagrams. Or maybe someone implements an SVG renderer for PGF/TikZ, which could cooperate with MathJax to implement the functionality of tikz-cd. Who knows?

Conclusion

It seems that interesting times for mathematics on the web are ahead of us. I am looking forward to implementing some of the proposed new features in the Stacks project, but first we'll have to wait a little for the thing to be actually implemented.

Also, there are some various more technical interesting points raised in the white paper, which I decided not to discuss now. Maybe I come back to these at some point.