MathML-mania cripples Wikipedia mathematics, again
Last week, the Wikimedia developers switched mathematics rendering on the English-language Wikipedia to a new system, so badly broken that it cannot correctly render the inequivalence relation symbol \(\not\equiv\), with formulas often partially obscured by other content such as images preventing them from being viewed, and intermittently not showing some formulas in footnote mouseovers at all. The changeover does not appear to have fixed old and long-unfixed bugs such as the inability to use mathematical formulas in image captions (if you do, clicking on the image will give you an expanded view with a broken caption). They did this without any large scale testing, without the ability for individuals to use their viewing preferences to restore the old system, with essentially no consultation with the mathematics editors on Wikipedia, without advance notice to Wikipedia, and over the repeated strong objections of the mathematics editors who despite all this found out ahead of time that this change was imminent. How did we get here?
When Knuth developed TeX in the late 1970s, it combined a shorthand textual notation for mathematical formulas that already by that time had become commonplace in networked email conversations between mathematicians, with Knuth’s obsessive care and attention to the fine details of mathematical typography. Others extended TeX in the early 1980s, producing AMS-TeX and LaTeX, which became and remain the standard for all professional mathematics. The relative ease of creating formulas in text, and the high-quality results, were never replicated by the word processors and point-and-click equation editors of the later 1980s. But this was all aimed at creating paginated mathematical documents, so when Wikipedia was founded in 2001 the web was in something of a mathematical dark age. You could write formulas as text, or you could use LaTeX on the server side to create a bitmap image file displaying the formula. It would be pixelated, with likely the wrong font size and alignment, but at least it would match the carefully developed formula layout that Knuth had designed. That was what Wikipedia chose, and it was the right choice at the time. Wikipedia editors could write formulas formatted as TeX, and the results would be far from beautiful, but at least they would be sort of legible.
MathJax became available in 2009, and quickly changed all that. One could write mathematical formulas as LaTeX formulas in the source code of web pages, and a JavaScript library in your browser would convert the formulas into something very close to Knuth’s layout, but formatted as text rather than as an image (so it would be affected by other text formatting like the coloring of links to other sites), in a font closely matching the one used for the rest of the web page’s text. MathJax quickly caught on, both for big sites (like MathSciNet, a database of reviews of mathematics publication) and small ones like personal blogs, and continues to be used with some competition from KaTeX, a similar JavaScript library. Early versions of MathJax were slow to render and worked best with big local font library installations but both of these issues were subsequently much improved.
There were desultory efforts to incorporate MathJax into Wikipedia, never fully supported, but by 2015, they had been ripped out again and Wikipedia’s mathematics formatting was still server-side images only. That remained true until last week, although the images gradually became higher-quality vector graphics, and closer to the body font in size and alignment, as this method was polished over time. The situation was already so frustrating to me in 2015 that I wrote a long blog post about it, “MathML considered harmful”. As the title suggests, I blamed MathML for the failure of Wikimedia’s developers to provide Wikipedia with MathJax, or with anything resembling MathJax in its combination of ease of use by Wikipedia editors and high quality output presented to viewers. The developers of Wikipedia’s formula-presentation software had focused all their attention on MathML, a dead end, at the expense of improving its image-based rendering system, and appeared to have been intentionally blocking the use of MathJax because they saw it as a competitor to their favored system, MathML.
MathML is an XML-based format for encoding mathematics formulas, first released in the late 1990s when XML was being used for everything. That has since changed; the standards bodies that control html have backtracked on XML compatibility, and JSON has taken over much of the data formatting that had been done with XML. One XML format that is unproblematic and remains in wide use is SVG, a vector graphics format; it is the preferred format for uploading technical illustrations to Wikipedia (although the servers convert them to bitmaps before presenting them to readers) and was the image format presented to readers for mathematics formulas in Wikipedia before the recent changes. However, MathML has been much less successful than SVG. It is neither easy to edit by hand (unlike TeX-based formats) nor easy for browsers to render well (maybe in part because there is little commercial pressure for them to do so). By 2013, MathML had become so disused that Google removed MathML support from its Chrome browser, and the only plugin available for Internet Explorer stopped working. And as of my 2015 post, the MathML designers had fallen back on a dual language design: one variant of MathML for semantics, an entirely different variant for formatting, with marketing that cherry-picked the supposed benefits of each variant as if they were all the same thing. But because the MathML designers neither tried to mimic TeX nor had Knuth’s focus on producing mathematical typography, the formatting version of MathML adequately described the rough layout of a formula but did not lend itself well to high-quality typography. And the dream of a semantically meaningful XML-based interchange language for mathematics was always a dream: when used as a natural language for communicating mathematics between humans, there are too many ambiguities and abuses of notation for a mechanical formalization to work.
It seems the developers never stopped dreaming. A 2023 web page from the Daisy Consortium (which develops MathML) proclaims “Now that MathML is natively supported in Safari, Firefox, Chrome, and Edge, websites and publishers can confidently use MathML for math expressions, with the benefits this brings for accessibility”. There are no benefits for accessibility: TeX, based as it is on textual email shorthands, is much better than MathML for screen readers. And side-by-side comparisons of LaTeX versus browser renderings of MathML reveal that, still today, the MathML rendering does not achieve the same high quality as TeX. But as recently as 2024, the Wikimedia developers were prepared to replace all mathematics rendering on Wikipedia with MathML: TeX formulas in the Wikipedia source code would be converted on the server side to MathML, and sent to readers whose browsers would render and display the MathML as something. When the plan was discovered, Wikipedia’s mathematics editors raised an outcry over the resulting degradation in typographic quality, and the developers backed off.
Nevertheless, the old server-side image-based rendering needed to be replaced, because the image caching database that it was based on had become unmaintainable. And the 2024 debacle meant that direct MathML would not work. So this brought us to a new plan and last week’s update. The new rendering system is called “client-side SVG”. But what that really means is: the server converts the TeX source code from Wikipedia to MathML, and sends it to browsers, just like the developers always wanted to do. But because the browsers do not render MathML well, there’s one more step: on the browser side, they use MathJax to convert the MathML back into a rendered formula.
MathJax does use MathML as an internal format for its formulas, so this is not complete nonsense, but needless to say, this is not how MathJax is intended to be used. It should not be surprising that translating mathematics formulas from TeX into what is essentially a foreign language and back before rendering them has some problems. The surprise is, instead, that it works at all. But there are many bugs, the system is inevitably fragile and unlikely to survive any updates to MathJax, and the fact that the Wikimedia side of the conversion is being handled by a small project with very few developers makes triaging and fixing any bugs very slow.
As for the broken inequivalence symbol bug: it’s at the cosmetic level, an ugly rendering but one that can still be read. Instead of \(\not\equiv\), it is displayed with the slash off-center, farther to the right than it should be. It’s the sort of thing that distracts and slows down readers, but doesn’t really prevent them from understanding the intended meaning. So it may be a long time before it is fixed. But I think it makes a good test case for the overblown claims that MathML makes formulas more accessible, more readable, and render well. In TeX, in MathJax-based systems (such as this blog), and in Wikipedia’s content editor, one codes this symbol by \not\equiv. The backslashes mark the beginning of the name of something, the first \not puts a slash through the next thing, and the next thing is the name of equivalence relation symbol. If a screenreader spoke “not equiv” I think it would be clear enough. On my blog, you should be able to control-click or left-click on the rendered symbol at the start of this paragraph and reach an accessibility menu that includes text-to-speech options. But in MathML, as currently coded by Wikipedia from this input, and indented for greater readability, it becomes:
<math xmlns="http://www.w3.org/1998/Math/MathML"
class="mwe-math-element mwe-math-element-inline"
typeof="mw:Extension/math" about="#mwt159" id="mwBkI"
data-mw="{"name":"math","attrs"
;:{},"body":{"extsrc":"\\not\\equiv
"}}">
<mrow data-mjx-texclass="ORD">
<mstyle displaystyle="true" scriptlevel="0">
<mo stretchy="false">≢</mo>
</mstyle>
</mrow>
</math>So readable! So accessible! So semantic! The meaningful part is hidden in the inner line (the one with the most indentation): the two characters ≡ (the equivalence symbol) and ̸ (the unicode “combining long solidus overlay” symbol). When placed together in text they would normally appear one after the other but somehow the client-side rendering library knows to overlay them and does so, but fails to center them vertically. In this example it would be possible to combine them into a single unicode inequivalence symbol, ≢, but I wouldn’t want them to try to patch this bug by trying to convert to it, because then the bug would still be present for all the more-obscure symbols that didn’t get the same treatment. And on Wikipedia, as well as rendering badly, there is no accessibility menu, and the image displaying the badly-rendered inequivalence symbol appears not to have any alt text. There’s an “Explain mathematical formulae on hover” option in Wikipedia’s viewing preferences, for logged-in users, but it appears to do nothing in my browser. So the only choice for accessibility seems to be to set one’s preferences to display the TeX source code directly rather than doing anything to render a formula.
In the absence of visible effort from the developers to catalog and prioritize the many bugs in this new rendering system, some Wikipedia editors have made their own catalog: Wikipedia:WikiProject Mathematics/MathFormattingBugs. It is a few months old, created when (despite no communication from Wikimedia) the editors caught wind of the plans to implement the new system, and hoped to either head it off (unsuccessfully) or at least delay its launch until the system worked reliably (also unsuccessfully). It at least had the effect of triggering the fixes of other bugs that were even more severe than the ones still listed, that otherwise likely would still not be fixed. But this bug catalog, too, was broken by the changeover to the new rendering system. It previously showed, for each example of a buggy formula, a side-by-side comparison of the old rendering system (“server-side SVG”), the new rendering (“client-side SVG”), and the rendering you would get by passing the MathML directly to your browser. This comparison is no longer available, because the developers ripped out the old rendering system at the same time that they made the new system the default.