It seems we are using MathJax version 2.7.5 That is apparently 4 years out of date. Can Math.se update the MathJax it uses? Or do we have to wait for the whole SE system to do it?
$\begingroup$
$\endgroup$
10
2 Answers
$\begingroup$
$\endgroup$
I was asked to comment on this question, so here is some information on the various MathJax versions and some issues StackExchange might want to think about.
One of the reasons that SE hasn't upgraded to version 3 is that it didn't include the automatic line-breaking support that is part of v2, as it plays an important role for many posts, particularly on mobile devices. Line breaking is included in v4, as @SAAD points out, so waiting for that is reasonable (it should be released in early 2023). He also mentioned that v4 includes in-line breaking, which is lacking in v2; it also has better breaking in tables, and included the ability to break text at whitespace. There are a number of new macros to help control line breaking, and support for more array preamble types for handling fix-width columns with line-breaking. See the v4.0-alpha release notes for more details of the changes.
Another important feature of v3 is that MathJax now has a lazy-typesetting extension where MathJax will typeset only the expressions that are in view, and will typeset others as they scroll into view. That will provide a significant speed improvement on pages that have many equations.
So there are many reasons to consider version 3 (or the upcoming v4). But I suspect the real reason SE hasn't updated to v3 is that the v3/v4 API is different from the v2 API, and that will require changes to the SE code that calls MathJax. That will affect how MathJax is loaded and configured, and how it is called from the javascript on the page. This will have a particular impact on the editor preview code that processes MathJax in the preview. This is a non-trivial change, and is not just a drop-in replacement. I wrote the original code used to update the math in the previews, and would be happy to work with SE on updating that code for v3/v4, but I no longer have contacts in the development team, so don't know how to make the offer. (SE was once a MathJax supporter, but they dropped that some time ago.)
Because these changes are significant, and would require careful development and testing, both of which take time, I would recommend starting the process now with v3 (the v4 API is substantially the same as v3), so that when v4 is out, SE will be ready to go.
As for version 2.7.5, SAAD is correct that the current v2 release is v2.7.9 (two years old), and updating to that would require no changes to the code, so that could be done quickly and easily. But most of the new features would require the more substantial update to v3/v4.
SAAD also suggested moving to something like TeXZilla. There are a number of issues to keep in mind when considering such a change. First, while native MathML support is coming for the Blink engine used in Chrome and modern versions of Edge, my understanding is that this is "MathML core", which is a limited version of MathML, and so may not be able to support all the needed features; for example, equation numbers use the <mlabeledtr>, which does not appear to be part of MathML core.
Since mathematical layout, even through native MathML, requires specialized fonts, and I'm not sure how that is being handled in the browsers theses days. Originally, Firefox required a separate font download and install, but they may come with the browser now. I'm not sure how that works on mobile devices. Variants such as double-stuck, Fraktur, script, calligraphic, etc., may not be available to all readers. Calligraphic presents a special problem in that MathML3 did not include a variant for calligraphic as separate from script, and unicode doesn't include a location for math calligraphic letters, so there is no natural way to handle \mathcal and \mathscr separately in MathML. Some fonts do include both versions, but the method of accessing them depends on the font.
Some people may also find the quality of the output to be unacceptable in some browsers. For example, Safari's (i.e., WebKit's) MathML support traditionally has been less effective than Firefox's, and I don't know if they are planning to port over the changes from Blink back to WebKit.
I don't think the native MathML implementations have the equivalent of MathJax's contextual menu (for viewing the TeX or MathML source, for example), and there is no natural way to get SVG output. Also, MathJax's expression explorer would not be available for generating speech text for screen readers. I don't think any current native MathML implementation does automatic line breaking (but I haven't looked recently, so I may not be up on their latest developments).
As for changing the TeX engine used by SE from MathJax to something else, one has to keep in mind the set of commands that are available in both programs. I am not very familiar with TeXZilla, but trying some tests on their interactive page suggests that there are important commands that are not implemented. For example, it doesn't seem to process \begin{align}...\end{align}, which will be problematic for this community. Also, \mathcal{C} and \mathscr{C} both produce the same character (though it is a different one in Firefox than in Safari). It doesn't seem to support \newcommand or a number of other common features, and there doesn't seem to be a list of the available commands.
MathJax also implements some non-standard macros, like \unicode, and \style, which are used on SE, but won't be available with TeXZilla. So switching could break a lot of existing posts, and substantial clean-up would be required.
Finally, TeXZilla doesn't seem to have been updated since 2019, so it does not seem to be currently maintained.
These are just some things to keep in mind as you consider potential updates to MathJax.
$\begingroup$
$\endgroup$
We'll hopefully be less out of date with a partial rollout starting today via user preference toggle for folks who would like early access to v3 and also help carve a path to v4 (once it's out of beta)
Read more and find the full details at Upgrade plans for MathJax v3/v4 to document work and track bugs
<br>to be very helpful. Further, if there is a substitute MathJax mechanism that some users employ, where these users might not know about<br>, then I don't think it is a good idea to lose a MathJax oriented line breaking mechanism. Also, although I have never employed it, a MathJax oriented line breaking mechanism does allow someone to format a single$...$paragraph, rather than separate$...$lines. $\endgroup$