Update since last week ago (9 Sep, T271001#12301447), these were fixed and deployed:

• Missing table border. T435274: Missing table grid borders in Client side MathJax (check polyfills for SVG support)
• Prime superscript spacing. T422149: Space too wide between two \prime symbols (client MathJax)

Remaining tasks that I suggested as High prio blockers:

• MediaWiki: Restore hidden a11y tree. T436026: Include a11y MathML in client MathJax mode — Pending code review.
• Parsoid: Math in blockquote. T429711: MathML on a line containing a div renders as a block – Work in progress.
• MathML: Wrong arrow placement. T435703: Wrong placement of arrow in \underset{f}\rightarrow in MathML and Clientside SVG

New issues I suggest as blockers:

• MathML: Backslash does not stretch. T437131: \left / and \right \backslash do not stretch in Native MathML and Client-side SVG modes
• MathML: \sidestep with alphanum causes "Not implemented" error T437140: \sideset{_a_b}{_c_d}D causes "Not implemented" error in client-side MathJax mode
• MathML: Bad \sideset placement. T437142: Bad \sideset placement in client-side MathJax

There are many more critical problems that should block deployment to not break many, many Wikipedia articles. Many of them haven't been given bug reports here yet, but you can see a list of reported issues at https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Mathematics/MathFormattingBugs

To quote my comment from a while ago (removing a couple of things that seem resolved):

• ~ needs to be interpreted the same way by the "client-side SVG" renderer as it is by the "server-side SVG" renderer. I believe that this is the same as \: would be in LaTeX, a medmuskip, defaulting to 4 math units, a slightly larger space than \,
• Inline math needs to have baselines that match each-other and the surrounding text
• Equations involving = {} or {} = need to have the correct horizontal spacing (and likewise for + {}, etc.)
• horizontal spacing and alignment needs to work in the align and alignat environments
• \\[...] in align-type environments (also matrix, cases, array, etc.) needs to work the same as in the current "server-side SVG" mode for all of the units that Wikipedia's page "Help:Displaying a formula" advertises (that is, em, mu, ex, in, pc, pt, cm, mm). The most common are probably mu and pt, but there are plenty of pages that use others of these units because it was advertised to authors for the past many years that they could use these.
• Trailing \\ in align-type environments must be ignored, and not add gratuitous extra space at the bottom
• The bugs that cause all of the horizontal space to be messed up in various contexts (like under overbraces or overlines, inside parentheses in fractions when there are exponents involved, etc.) need to be fixed
• Vertical spacing of continued fractions needs to work as expected
• Tildes and other accent marks need to have uniform size irrespective of what they are put above. The current rendering of \tilde{a} \tilde{m} is ridiculous
• ...

Status update (since 16 Sep, T271001#12329974):

Sorry there was no update last week. It took a bit longer to agree on the remaining blockers while finishing one more pass through Wikipedia:WikiProject_Mathematics/MathFormattingBugs.

Previous blockers fixed (some deployed, some ride the train this week):

• T436026: Include a11y MathML in client MathJax mode
• T429711: Math in blockquote when in Parsoid mode renders as block instead of inline.
• T435703: Wrong placement of arrow in \underset{f}\rightarrow in MathML and Clientside SVG
• T437131: \left / and \right \backslash do not stretch in Native MathML and Client-side SVG modes
• T437140: \sideset{_a_b}{_c_d}D causes "Not implemented" error in client-side MathJax mode
• T437142: Bad \sideset placement in client-side MathJax

Other issues fixed:

• T386787: Trailing linebreak via `\\` in <math> matrix should be ignored
• T422149: Space too wide between two \prime symbols (client MathJax)
• T438415: Support px as LaTeX length unit
• T438417: vertical space is absorbed in multi-row multi-line environments such as align

New blockers that we'll tentatively postpone rollout another two weeks for (to Wed 13 Oct and Thu 14 Oct):

• T402029: Rendering of operators in client-side MathJax mode
• T437146: <math chem>\ce{\overbrace{\ce{H2O}}}</math> emits raw mathml in client svg and native mathml mode
• T439455: \nleqslant and \ngeqslant render the wrong symbol in client-side SVG and MathML modes
• T439458: \varnothing renders the wrong symbol in client-side SVG mode
• T439459: Super-superscripts and nested script levels are illegibly small in client-side SVG mode
• T439460: Sums and other large operators keep display style inside fractions and \sqrt (should use inline style)
• T439461: \mathop does not produce an operator: limits are placed as sub/superscripts

You still haven't bothered to ask Wikipedians what issues they consider essential to fix, and you still haven't even triaged all of the reported issues.

@Jacobolus Please criticise ideas, not people.

@Aklapper, could you expand on what you mean by "criticize ideas, not people"? I find it hard to see how that applies to what jacobolus has written in the past month.

In his latest message — which I assume is the one you’re reacting to, given the timing — he is criticizing the fact that, despite this having been pointed out several times, the current approach still shows no sign of asking Wikipedians which issues they consider essential to fix, or even of triaging all the issues that have already been reported.

That seems to me like criticism of the approach being taken, rather than of the person taking it.

And, for what it’s worth: I criticize the idea of invoking "criticize ideas, not people" as a generic way to dismiss legitimate negative feedback.

I think Akalapper is referring to generally agreed conventions that make bug tracking systems work well. When I teach software testing I distinguish error, mistakes and failures. People make error when writing code, including errors of omission; these errors lead to mistakes, or bugs, in the code, which cause failures of the system, say putting a superscript in the wrong place. A good bug tracking system focus on reporting failures leading to the identification of the bugs, but steers clear of blame for errors. Ideally we keep people out of it.

Jacobolus comment "You still haven't bothered ..." goes outside that convention directly blaming people for an inaction. It could have been rephrased "There is still no mechanism for asking Wikipedian which are the most important bug to fix". That a fine report of a failure in the system and is worthy of consideration. Just framed in language that does not wind everyone up.

On English Wikipedia, its actually easy: simple add "important" or "priority high" in the first column of MathFormattingBugs, or add a comment on the talk page. I watch that page and I've turned 20 odd reports there into bug reports here, many have now been fixed. So if something is flagged there, I'll hopefully spot it and turn it into a bug report.

On other wiki's I've concerns about lack of announcements. There are 40 other wiki with something similar to Wiki Project Mathematics, I don't know how many of those are aware of the upcoming change. My worry is there could be some common type on expression on the Chinese Wikipedia that causes a bad failure in SVG.

The issue here goes far beyond the bug tracker. The problem is a fundamentally broken high-level process, almost total lack of communication, and completely unprofessional project management.

In any kind of functional software development, the goal must be to serve the needs of end users, and end users' interests must be constantly top of mind. In this case, that means Wikipedia readers and Wikipedia authors. Instead, the priorities here are inverted. The needs and preferences of the end users were never sought in any way, comments of Wikipedians who came here feel conspicuously ignored, the development priorities are based on narrow and arbitrary internal bureaucracy that has basically nothing to do with anything Wikipedians want or care about, and the schedule continues to be totally unrealistic.

The way the process is being done right now feels extremely hostile and coercive, and the current schedule amounts to a threat to unilaterally severely damage Wikipedians' work, giving Wikipedians no recourse other than to complain.

Instead of "let's work together to figure out what the problems are, and then solve them", the message I get from this discussion is more or less: "We have already decided to break your stuff ASAP, in conversations you were not invited to participate in, and there's nothing you can do about it, but we might eventually unbreak some of it if you're lucky. Or not."

Since my original complaint nothing has been done to build anyone's trust or re-assure Wikipedians that their concerns are respected. The way Akalapper keeps replying in fact undermines Wikipedians' trust in the WMF and Mediawiki development. It does not reflect the kind of democratic consensus building normally found on Wikipedia.

Let me be concrete about how a better process would look, for a project as collaborative as Wikipedia:

Step 1: Developers or project managers start an open ended conversation with end users about what they like or dislike about the software, trying to identify what is working and what isn't working, and surface ideas for possible future improvements.

Step 2: A plan is drawn up of what new ideas or features to pursue based on the results of discussion from step 1. If there are going to be major changes to people's workflow or output, major stakeholders are included in the conversation.

Step 3: New features are developed without any pre-commitment to ship them, and the process keeps an eye toward backwards compatibility. Any breaking changes are pitched to users as a necessary tradeoff for some concrete benefits.

Step 4: The software is carefully tested and made available as an option, and feedback is sought about how well it works in practice.

Step 5: There is a substantial communication blitz to make sure that all end users who want can participate in a discussion about whether to deploy a new feature that might involve some backwards incompatible breaking changes. Users and developers work together to assuage people's fears and convince everyone that the new feature will be an improvement.

Step 6: A schedule is established for deployment that has broad support, so that users are confident that there is no rush job that is going to damage their work or cause them to scramble.

Step 7: The feature is further tested, and eventually deployed.

I want to thank @SalixAlba for creating https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Mathematics/MathFormattingBugs and @Jacobolus for adding entries and bringing these issues to attention. The situation is much better than it was back in August. Maybe we could have gotten here with more polite complaints, but then again its not clear why the complaints were required.

Thank you all for the activity and helping with issue reporting.

We have been using https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Mathematics/MathFormattingBugs to understand the issues that are essential to fix and asking the following question: Does it change what a reader understands?

I started to categorize it in four levels: output is missing, wrong, or shows markup as text (broken and high priority); symbols are right but the layout changes how the expression reads, or makes it illegible (misleading and high priority); it reads correctly but looks worse than today (degraded and medium priority); it is only noticeable side by side (cosmetic and low priority).

Every issue will be triaged and added to the board, but we are focusing on the most critical that are either broken or misleading and waiting for some fixes to get deployed to re-evaluate other issues reported.

Pixel by pixel parity is not the goal as we have discussed this before due to the RESTBase deprecation project, but we are moving carefully with attention to the reports.

@MSantos: Great. I think this classification makes sense. I have a few comments on it, though:

• first, I think it would make sense categorize some degraded renderings as high priority — based on the number of articles in which they are used and on how "bad" the new rendering looks. The main example I have in mind is the spacing around &= in the align environment: this is going to affect a ton of articles, and the effect is very noticeable.
• second, regarding legibility, I would like to know more about how this is can be affected by the user's set-up. I think I've seen people suggest that there is no platform dependence, because "the same SVG is generated" (I might be remembering incorrectly and/or oversimplifying)... But is that really the whole story? In particular,
  1. On my set-up (Debian stable on 3 different computers with very different screen sizes), mathjax-newcm consistently looks thinner and fuzzier than mathjax-tex. If everybody saw the exact same thing as I do, I don't think mathjax-newcm would have been chosen as the new default font by MathJax.
  2. The fact that MathJax describes its mathjax-newcm as "slightly lighter, so will not seem so bold and will fit in better on Windows machines, without losing too much on linux, Mac OS, and iOS displays" and that I happend to be on a linux machine leads to me to believe that their might indeed bit a difference in weight / sharpness between various OS's.

That second point matters for the classification. For instance, in the example below I would classify the new rendering as illegible:

Also, with the new font/rendering, many small symbols (e.g, most superscript and subscript) look fuzzy and therefore require me to squint. So, although there are not illegible, they are harder to read.

Finally, how can I — or, more generally, Wikipedia users — help with the classification of the bugs?

@MSantos No one is asking for Pixel by pixel parity parity. We are asking for quality rendering comparable to existing math typesetting. This is an entirely reasonable requirement before releasing a replacement.

@MSantos How important bugs are also depends on how often behavior is relied on, how important the relevant features are to the pages that use them, etc.

As a few example bugs that I think should be high priority (more or less required before deployment), even though they may seem to be only "cosmetic" or "degraded":

The horizontal and vertical spacing in \align, \alignat environments must be fixed. This is probably the most urgent issue of all.

The bug(s) causing spaces to get inexplicably removed in various contexts such as under overbraces and inside certain fractions nested with exponents are extremely problematic where they appear, even though they only involve horizontal spacing.

It seems trivial, but it would be an immediate help if ~ were interpreted the same way in client-side SVG mode as in server-side SVG mode. The server-side mode interprets it as (I believe, but please double check) a \medmuskip, usually typeset in standard LaTeX by \: (a command which is not supported in Mediawiki's LaTeX implementation), a space of 4 math units, intermediate between \, and \;. Such spaces, for better or worse, are used all over English Wikipedia, and the current behavior of the client-side SVG mode which makes them into much wider spaces causes ugliness all over. I imagine this could be fixed with quite little effort.

It is important for continued fractions, typeset with \cfrac, to have the same vertical spacing as expected from LaTeX and from the server-side SVG mode. While continued fractions are only used on a relatively small number of pages (compared to, say, integrals), they are very important to depict clearly in the contexts where they do appear, and the current rendering of them from the client-side SVG mode is unacceptably bad.

By comparison, some of the "shows markup as text" examples appear very rarely or never, and so while they are clearly extremely broken, are not necessarily as important for Wikipedia.

TL;DR; the confidence to proceed with the roll-out is high and we have performed thorough analysis to support that.

First of all I want to thank @Physikerwelt, @SalixAlba, and @Jacobolus for all the activity in this workstream. We are in a much better shape now to proceed with the roll-out.

@Jacobolus I agree that usage on wiki is an important triage factor, but I don't think they change the classifications that block the roll-outs. I'm going to create new tasks for the remaining issues that should be fixed right after the roll-out.

Balancing the RESTBase deprecation timelines and the state of fixes for client-side SVG generation I believe we have achieved a reasonable target. That's a decision made after conducting a visualdiff analysis on the most popular pages and the issues occurrences across the top 10 wikipedias.

The most severe \align, \alignat issues were fixed at T434424. The 3 biggest visual diff regressions reported were:

Which are regressions but doesn't fall into the criteria for the most severe bugs. So, usage across wikis can be used as a triage method for the fixes but they won't block the roll-out.

Roll-out confidence

Previous blockers
The only blocker listed before (T271001#12375659) is in progress with partial solutions in place, however it's impact is very minimal (90 of 673,419 enwiki formulae (~0.013%) hit the bug as filed) and the impact on top 10 wikipedias:

In this context, we can proceed with the roll-out since it will take ~30 days for the cache to expire and the fix will be available before then.

Client-side SVG regressions on top 10 Wikipedias
From the visualdiff no other issue reported as the high-priority tickets created and triaged from MathFormattingBugs and the top five issues that should be fixed right away have the following impact:

Next steps

• Create phab tasks for all Math formatting bugs reported with the priority label following the framework
• Monitor the roll-out
• Monitor downstream usage of Math articles
• Refresh page caching after the roll-out so the new rendered method is used
• Deprecate and remove RESTBase + Mathoid

In T271001#12484145, @MSantos wrote:

TL;DR; the confidence to proceed with the roll-out is high and we have performed thorough analysis to support that.

To be frank, no you have not. You still have not bothered asking Wikipedians what they think, and this entire process remains fundamentally, catastrophically broken. "Let's ship something substantially broken today and maybe we'll fix it later if you're lucky" is not a reasonable strategy for a major content rendering platform.

I also don't understand what "resolved" means, since some things marked "resolved" still seem broken.

Which are regressions but doesn't fall into the criteria for the most severe bugs.

I'm sorry but this is bullshit. Some of these are completely show-stopping bugs that make Wikipedia look like trash.

There are also still severe bugs that you haven't even yet made issue reports for, all these months later. You are still months of work away from a state that can be shipped without fundamentally breaking the encyclopedia.

@MSantos you have not replied to my question above — namely, how can Wikipedians get involved with the classification of the bugs and provide feedback on what they think should be blocking for the roll-out? So far it seems like there is no way to do this.

@Malparti we have been using https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Mathematics/MathFormattingBugs as place to connect with the community for this work and centralizing actionable feedback.

That page is an unsorted list of miscellaneous reported issues, not a discussion. It's also not "connecting with the community", but rather: a few members of the community, unsolicited, coming to tell you unidirectionally what problems they found, without any reply.

To add a positive note here:

It looks like some update very recently (today?) was deployed to Wikipedia that shows off a lot of the progress made in the past couple months, and a decent number of issues have been fixed or at least somewhat improved. Thanks to the software developers for continuing to fix rendering bugs with the new renderer. The current state is, to be sure, significantly better than a few months ago.

The transition to client-side rendering has been a technical/platform discussion for some years now here in phabricator, where the intent has always been to replace infrastructure but keep functionality, without adding or removing features. All driven by sustainability needs in RESTBase-Sunsetting.

I can understand that the expectations on communication are not met. I'm focusing on what we can do now and keeping a central place to report issues, and I'm using the MathFormattingBugs page considering that community (even if represented by a few members) had contribute to it and was fundamental to analyze and prioritize the blockers.

I'm happy to continue using it to find "broken" or "misleading" bugs and cataloging "regressions" and "cosmetic" bugs. Our visual diffs tests don't raise roll-out blockers (broken or misleading) and that's why we are confident to proceed knowing that we won't cause a burden to manually validate each formula/page.

@MSantos Thanks for the link to https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Mathematics/MathFormattingBugs, however I'm already aware of the existence of this page — in fact, I've added a few bugs to it — and in my opinion that does not answer my question.

I'm asking for a place to build consensus regarding which bugs should be high priority or not. MathFormattingBugs does not seem to be it. It looks more like a centralized place to dump "bugs", but it doesn't look like a good place to discuss how important they are. As I wrote above,

I think it would make sense categorize some degraded renderings as high priority — based on the number of articles in which they are used and on how "bad" the new rendering looks.

For instance, I personally do not care about the new behavior of \overline, since I actually think the new rendering looks better than the old one. By contrast, I think most math editors would agree that issues such as the horizontal alignment around &= in align environments are a major problem and should be blocking for the roll-out

I other words, when you wrote:

I started to categorize it in four levels: output is missing, wrong, or shows markup as text (broken and high priority); symbols are right but the layout changes how the expression reads, or makes it illegible (misleading and high priority); it reads correctly but looks worse than today (degraded and medium priority); it is only noticeable side by side (cosmetic and low priority).

That is really nice — and by the way thanks for your work on this — and I think it does make sense; but I also think your classification has some flaws (at least based on the simplified way you described it here) and it would be nice to allow motivated Wikipedia editors to be able to give feedback on it.

Finally, another thing I've mentioned several times without ever getting an answer is this:

• second, regarding legibility, I would like to know more about how this is can be affected by the user's set-up. I think I've seen people suggest that there is no platform dependence, because "the same SVG is generated" (I might be remembering incorrectly and/or oversimplifying)... But is that really the whole story? In particular,
  1. On my set-up (Debian stable on 3 different computers with very different screen sizes), mathjax-newcm consistently looks thinner and fuzzier than mathjax-tex. If everybody saw the exact same thing as I do, I don't think mathjax-newcm would have been chosen as the new default font by MathJax.
  2. The fact that MathJax describes its mathjax-newcm as "slightly lighter, so will not seem so bold and will fit in better on Windows machines, without losing too much on linux, Mac OS, and iOS displays" and that I happend to be on a linux machine leads to me to believe that their might indeed bit a difference in weight / sharpness between various OS's.

That second point matters for the classification. For instance, in the example below I would classify the new rendering as illegible:

Also, with the new font/rendering, many small symbols (e.g, most superscript and subscript) look fuzzy and therefore require me to squint. So, although there are not illegible, they are harder to read.

It is still unclear to me how much this varies from one platform to the next, and how much of it will (would?) be fixed by going back to using mathjax-tex.

@Malparti, thanks for the thoughtful response.

I guess I could be more explicit, but when I said I would be following MathFormattingBugs, I also meant any discussion on the talk page. Does that improve the answer? My preference is for a single place so as not to lose track.

It is still unclear to me how much this varies from one platform to the next, and how much of it will (would?) be fixed by going back to using mathjax-tex.

I believe the discussion of this bug occurred in T439459: Super-superscripts and nested script levels are illegibly small in client-side SVG mode, and the work on mathjax-tex should be discussed in T440336: Change font to mathjax-tex. Regarding the variation from one platform to the next, do you mean different browsers? If so, this is one of the reasons we are using the MathJax client-side rendering approach instead of relying on native browser render of MathML, to reduce the variations between different platforms.

MSantos:

Can we have some time (like, at least weeks) after the proposed version is considered ready enough by WMF / Mediawiki developers between before deployment as the default rendering mode, to give time for additional bug surfacing, testing, checking pages, discussion, etc.? And ideally, some concrete discussion about what kind of bugs remain, how feasible they are to fix and how much effort that will take, etc.? Ideally there would be some kind of process for community sign off before any deployment decisions/schedules are made.

Can we also please have a promise that the "server-side SVG" mode continue to work for some time (at least a few months) after the "client-side SVG" mode is rolled out as the default, whenever that is, so that Wikipedians can continue to see, when opted in either on a whole page or for a particular expression, what the old version looked like? If the old version is immediately removed from the project, it will suddenly become impossible to compare. If, after deployment, someone finds a math expression with broken rendering, it needs to continue to be possible to determine whether the problem lies with the new math renderer or with the math markup.

transition to client-side rendering has been a technical/platform discussion for some years now here in phabricator

The problem is that the discussion has been limited to Mediawiki developers / Wikimedia Foundation staff, discussing and planning among themselves, without input or discussion from Wikipedians. Decisions are made completely independently of Wikipedians and not communicated clearly. From Wikipedians perspective, there was a broken feature with uncertain future being worked on as a hobby project somewhere out of sight for a few years, until, without warning, an urgent threat to break stuff ASAP dropped out of the sky, without any apparent effort to make the process collaborative.

If this has been a problem for "some years", the appropriate time to start explicitly gathering feedback from stakeholders like English Wikipedia authors is some years ago, and the hard software development requirements have to be communicated to Wikipedians with enough time allowed to actually fix the problems that come up. Waiting until just before deployment to set a very short deadline makes it fundamentally impossible to actually find and fix critical bugs in time, and forces the entire process into operating as a hair-on-fire emergency for no good reason.

I also meant any discussion on the talk page

https://en.wikipedia.org/wiki/Wikipedia_talk:WikiProject_Mathematics/MathFormattingBugs doesn't exist. So which discussion do you mean?

do you mean different browsers?

There are also differences in font and vector graphics rendering (how antialiasing works, etc.) between platforms and devices. For example, someone with a 200 DPI display may have an easier time seeing small symbols than someone with a 100 DPI display. Someone whose Mac is set to a resolution that is exact to their screen resolution may see clearer symbols than someone whose Mac is set to a resolution that doesn't quite match their display resolution, which involves automatic bitmap rescaling of all content between the software rendering size and the actual hardware output. Etc.

Malparti wrote

personally do not care about the new behavior of \overline

Which "new behavior" do you mean, Malparti? If you mean the way that an overlined expression has all of the horizontal whitespace gobbled up: In my opinion this is a serious bug which affects any pages using overlines over expressions, e.g. for complex conjugates, which must be fixed with very high priority.

Or do you mean the way single overlined letters have the overline horizontally misaligned and the wrong width? This is also a very annoying bug which makes some pages look bad (everything just looks kind of janky), but is not as bad as the other one.

@Jacobolus Re. overline: I was referring to the second thing you mentioned, namely the way overline behaves on single letters, that is,

In my opinion, the standard implementation of overline has a major problem: namely, the line it produces is horizontally aligned "in terms of boxes" (sensu LaTeX). But, because most letters on which it is used are slanted, they are not visually aligned. I guess you know what I mean, but in case I'm not being very clear, a picture is worth a thousand words
(forgive my Paint skills, this is a just a rough sketch to show what I mean):

{F111191881}

This is something that has always bothered me with LaTeX, to the point that I actually used a customized \overline.

I have not looked into the technical details of this, but at least in the examples I've seen, on single letters I think the new version of overline looks better than the previous one. It's just a matter of taste, though. But that also means I'd personally be in favor of keeping the new behavior (unless it has other drawbacks that I'm not aware of).

I agree this single-character overline bug is not the most serious or urgent. I wouldn't demand blocking deployment conditional on fixing this, though I would also like to see it fixed relatively promptly.

I think the overlines should match whatever LaTeX does, even if that behavior is not ideal. If we want a better appearing single character overline, then it should be defined as a new command and something that is easily replicable in ordinary LaTeX

Overall I expect many letters' overlines end up being somewhat bad; the overline above alpha above is clearly too far to the right and too close to the letter. But these two letters are just examples. Someone needs to go through and check every symbol and look to see what the behavior is like.

@MSantos, Re:

Regarding the variation from one platform to the next, do you mean different browsers?

I mostly means in terms of OS and screen, as Jacobolus explained.

The appropriate place to have a discussion on the weight and legibility of the new font is indeed T440336. But the reason I was mentioning this here is that this example seems to contradict claims that have been made earlier in this thread that there is no need for cross-platform/browser testing because "it's the same SVG so it will look the same everywhere".

jacobolus pointed out to me that other users may not see the magnificient drawing I made in Paint to explain what I meant by "aligned in terms of boxes" vs "visually aligned", because I've added it after editing my comment. So here it is:

Here are a bunch of the remaining bugs all in one place:

Current version ("server-side SVG"):

New version ("client-side SVG"):

Overall the new one just looks off all over the place, like a drunk typesetter decided to perturb each symbol by a small amount in a random direction.

@Jacobolus I still think that the new placement of the overline tends to look better — doesn't mean it's perfect, but I could live with it ;)

Jokes aside, everything else does indeed look very... Well, "non-standard" is a polite and somewhat objective way of describing it; but "terrible" is how I would describe it. To me the following issues stand out the most:

• The horizontal alignment in align (and related environments);
• The spacing in whatever is under overline
• The spacing in the client-side rendering of

<math>\overline\varphi = \tfrac12\bigl(1 - \sqrt5\;\!\bigr) = {}</math><math>\textstyle -\varphi^{-1} = {}</math>{{nobr|<math>1 - \varphi</math>}}

The oversized parentheses in ℚ(√5) due to the way √5 is rendered also look bad, but to be fair (1) √5 doesn't look that bad and its own and (2) I haven't looked at the way {{Q(√5)}} is implemented, but in case it is using \left( and \right) then I think that's what should be fixed (that's a common problem in regular LaTeX: sometimes you put such parentheses around two very similar looking symbols, but because one is actually slightly taller than the other you get parentheses of different sizes. So I think a good fix here would be to hardcode the parenthesis sizes in {{Q(√5)}}.

{{Q(√5)}} expands to {{tmath|\Q\bigl(\sqrt5\;\!\bigr)}}, with 2 math units space added after the radical sign because otherwise it nearly collides with the closing paren. Formerly this was using ~\! which added only 1 math unit of space, but ~ doesn't work the same in client-side SVG mode.

The possibilities (the one above is #2) in "client-side SVG" mode include the following, none of which looks very good in my opinion:

Change #1311060 merged by jenkins-bot:

[operations/mediawiki-config@master] MathML+MathJax rollout to phase 5 (Wikipedia small/medium/canary)

https://gerrit.wikimedia.org/r/1311060

Mentioned in SAL (#wikimedia-operations) [2026-10-29T16:07:16Z] <krinkle@deploy1003> Started scap sync-world: Backport for [[gerrit:1311060|MathML+MathJax rollout to phase 5 (Wikipedia small/medium/canary) (T271001)]]

Mentioned in SAL (#wikimedia-operations) [2026-10-29T16:11:37Z] <krinkle@deploy1003> krinkle: Backport for [[gerrit:1311060|MathML+MathJax rollout to phase 5 (Wikipedia small/medium/canary) (T271001)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2026-10-29T16:20:54Z] <krinkle@deploy1003> Finished scap sync-world: Backport for [[gerrit:1311060|MathML+MathJax rollout to phase 5 (Wikipedia small/medium/canary) (T271001)]] (duration: 13m 38s)

Here, concretely, is a partial list of bugs which in my opinion must all be fixed before deployment is reasonable to even consider.

I'm not sure if they all have tickets. For those with tickets, some kind of link would be appreciated, if someone has one handy.

1. Horizontal spacing in align environments is broken
2. Manually adjusted vertical spacing in align environments is broken (needs to match existing behavior). Most notably the "mu" unit is not implemented in client-side SVG mode, but is used extensively in English wikipedia. But various other units also don't match existing behavior.
3. Horizontal whitespace is incorrectly removed in various kinds of nesting contexts (I don't have a full list of where this occurs; needs to be extensively investigated/tested by the software developers). This one is brutally bad, with current results completely unacceptable.
4. {} is ignored by client-side SVG mode. Instead, it needs to act as an empty placeholder for the purpose of calculating layout
5. Various symbols are still incorrect – much of this can probably be fixed by changing the font(s)
6. Diacritical marks over letters, such as tildes and checks, are very wonky
7. Vertical spacing of continued fractions is incredibly bad

@Jacobolus, @Malparti, thanks for the follow-ups since T271001#12484145. I'm answering the open questions in one place and restating the decision so it's clear.

Decision
We're going ahead with client-side SVG as the default on the remaining Wikipedias, including English Wikipedia, on Nov 2nd. We still get ~30 days before cache expires and pages start using the new renderer. The reasoning shared at T271001#12484145 is what supports this decision.

The regressions listed are not de-prioritised or dropped but they move to the post-rollout fixes.

Regarding a testing window before the switch (@Jacobolus)
We won't add a separate multi-week hold. The new mode has been selectable on enwiki since August, and forcemathmode=mathjax has worked per formula since T434686. The switch itself is also gradual: pages pick up the new rendering as their cached copy expires, over roughly 30 days, so reports made during that window can still be fixed before most readers see them. If something broken or misleading with wide reach turns up in that window, it will be treated with urgency. Extensive visual diffing has been done to reduce the burden of manual verification and increase the confidence of the roll-out.

Regarding keeping server-side SVG for comparison (@Jacobolus)
The server-side SVG renderer can't stay for months, because it runs on RESTBase, which is being retired over the course of the next month. I’ll see with @Physikerwelt and @Krinkle what can be done to save the SVGs on existing bug reports for future comparison.

Regarding where Wikipedians can discuss priorities (@Malparti, @Jacobolus)
You’re right that the MathFormattingBugs talk page didn't exist yet. I've started a thread there. That is the place to say a row should move up, for example a degraded issue that appears in thousands of articles, like the &= spacing in align. I’m also leaving a note on VPT pointing to the talk page.

After the switch, fixes are ordered by level first, then by reach (articles and pageviews, as in the table in T271001#12484145). Every row will get a Phabricator task with its level, and the task number will be added back to the page, so nobody needs a Phabricator account to follow along. That includes the comparison @Jacobolus posted today.

Regarding the platform differences (@Malparti, @Jacobolus)
What I meant was that how SVGs draw differently on platforms is equally true with today's server-side SVG, which the browser also rasterizes. What changed is the font: mathjax-newcm is lighter than the TeX fonts used server-side, so small glyphs lose more legibility on some setups.

The font weight question (mathjax-newcm vs mathjax-tex) is tracked in T440336. It isn't a gate for this switch: changing the font interacts with the LaTeX→MathML conversion and could bring back bugs that are already fixed, so it needs its own testing.

The criticism that this was discussed mainly on Phabricator is fair. From now on, updates will go to both this task and the talk page.

Can you see how "we're shipping this in 4 days irrespective of any complaints or objections, after substantially ignoring many concrete criticisms over the past few months" does not really seem like a good faith collaborative effort? Especially since it comes after a string of similar short-deadline ultimatums that never involved any kind of apology, reset, or promise to do better. Basically, you have pre-decided to steamroll us, with indifference to severe quality problems and to Wikipedia authors and readers. For a volunteer project, it feels profoundly disrespectful.

There is still no explanation why RESTBase, which has been in use for at least a decade, must urgently be scrapped ASAP with no possibility for any delay. Whatever reasoning was used to arrive at that conclusion was never shared with anyone outside the WMF, and frankly makes no sense given what has been articulated to date.

And there's still not really a good explanation for how or why the current technical approach was chosen. It doesn't seem like any alternatives were even seriously considered. It doesn't make logical sense from a software system perspective. My overall impression is that a series of ill-advised and poorly motivated technical decisions were made a long time ago, and are now being forced to continue based on a sunk cost fallacy / to help people who made poor decisions and communicated them poorly save face instead of admitting failure.

The new mode has been selectable on enwiki since August

Yes, but you keep making continuous changes, some earlier this week, which nobody has yet had any time to actually investigate the ramifications of or check up on. Some of the changes are likely to surface yet new bugs.

In a project as long term as this, there's no good reason why we can't wait until after there is a stable version free of known bad bugs *before* trying to even set a schedule. That gives everyone time to do patient and careful checking, surface additional bugs, have back-and-forth technical discussions about how to fix issues, and so on.

Change #1311061 merged by jenkins-bot:

[operations/mediawiki-config@master] MathML+MathJax rollout to phase 6 (remaining large Wikipedias)

https://gerrit.wikimedia.org/r/1311061

Mentioned in SAL (#wikimedia-operations) [2026-11-03T04:16:14Z] <krinkle@deploy2003> Started scap sync-world: Backport for [[gerrit:1311061|MathML+MathJax rollout to phase 6 (remaining large Wikipedias) (T271001)]]

Mentioned in SAL (#wikimedia-operations) [2026-11-03T04:24:21Z] <krinkle@deploy2003> krinkle: Backport for [[gerrit:1311061|MathML+MathJax rollout to phase 6 (remaining large Wikipedias) (T271001)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2026-11-03T04:40:48Z] <krinkle@deploy2003> Finished scap sync-world: Backport for [[gerrit:1311061|MathML+MathJax rollout to phase 6 (remaining large Wikipedias) (T271001)]] (duration: 24m 34s)

Change #1361722 had a related patch set uploaded (by Krinkle; author: Krinkle):

[operations/mediawiki-config@master] Purge mathoid embeds via RejectParserCacheValue hook

https://gerrit.wikimedia.org/r/1361722

Can you please either revert this deployment or fix (1) the horizontal whitespace gobbling bug and (2) the broken align whitespace bug(s) and (3) the ignored {} bug, ASAP? These bugs are critically bad.

Many (most?) of our technical Wikipedia articles now look broken and incompetent.

Also can we see what all the various symbols look like with the previous Mathjax font, ASAP?

Many of the reported bugs with the new rendering mode have still not even been triaged. The process here continues to be unacceptably broken.

Change #1311062 merged by jenkins-bot:

[operations/mediawiki-config@master] Remove Mathoid SVG option from wgMathValidModes

https://gerrit.wikimedia.org/r/1311062

Mentioned in SAL (#wikimedia-operations) [2026-11-04T17:58:22Z] <krinkle@deploy2003> Started scap sync-world: Backport for [[gerrit:1311062|Remove Mathoid SVG option from wgMathValidModes (T271001)]]

Mentioned in SAL (#wikimedia-operations) [2026-11-04T18:01:18Z] <krinkle@deploy2003> krinkle: Backport for [[gerrit:1311062|Remove Mathoid SVG option from wgMathValidModes (T271001)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2026-11-04T18:12:06Z] <krinkle@deploy2003> Finished scap sync-world: Backport for [[gerrit:1311062|Remove Mathoid SVG option from wgMathValidModes (T271001)]] (duration: 13m 43s)

By the way, the "mathmode=mathjax" and "mathmode=mathml" URL options seem to be broken, which is preventing Wikipedians from assessing the new rendering mode.

This rollout is totally and utterly fucked. It is impossible to overstate how incompetently this is being done.

The Wikipedia MathFormattingBugs page is now completely broken. The previous rendering mode cannot be viewed in any way.

The previous rendering mode MUST CONTINUE TO WORK as an option:

• It must work on any single particular math tag with "forcemathmode=mathml" specified
• It must work for all (unspecified) math tags on a page when "?mathmode=mathml" is added to the URL
• It must continue to work an opt-in preference for rendering on all English Wikipedia pages

Until such a time as all of the bugs have been fixed, of which there are still many.

Otherwise this is not a "transition" at all. We're just dropping the encyclopedia off a fucking cliff.

Wikipedia MathFormattingBugs page is now completely broken

This can be migrated to a Cloud-hosted MediaWiki instance with a Mathoid installation.

Or, much more reasonably, it could easily be kept working in English Wikipedia for the next several months.

In T271001#12511676, @Jacobolus wrote:

Can you please either revert this deployment or fix (1) the horizontal whitespace gobbling bug and (2) the broken align whitespace bug(s) and (3) the ignored {} bug, ASAP? These bugs are critically bad.

The deployment won't be reverted, this is part of an important and critical infrastructure change.

In regards to the issues you suggested, I'll ensure these are treated with importance and fixed asap. Below I'm listing the main tickets in the priority queue, please let me know if these are not represented there.

Many (most?) of our technical Wikipedia articles now look broken and incompetent.

As I mentioned before, we do not intend to stop the work and move on after the roll-out. We will continue working on fixing the remaining issues so this is just a transition period.

Also can we see what all the various symbols look like with the previous Mathjax font, ASAP?

I just added this at T440336#12515595

Many of the reported bugs with the new rendering mode have still not even been triaged. The process here continues to be unacceptably broken.

The following bugs are in the next round of fixes:

• T443593: align and alignat use the MathML default column spacing, not the amsmath spacing
• T438945: Native MathML and clientside SVG can overlap images.
• T443592: Spacing is lost inside a group that has a script or an over/under mark

In regards to the process, I am working on improving the proposed table at MathFormattingBugs with links to all phab tickets asap, so it's clear what's tackled next.

In T271001#12518557, @Jacobolus wrote:

By the way, the "mathmode=mathjax" and "mathmode=mathml" URL options seem to be broken, which is preventing Wikipedians from assessing the new rendering mode.

We have looked into the situation, and the server-side SVG renderer not being available is a side-effect of the RESTBase sunset process. Unfortunately, it cannot be re-enabled.

However, since full parity/pixel perfect was never possible I wonder if we can just change the focus of the MathFormattingBugs page from now on to point to what needs to be improved on the current renderer instead of focusing on previous behaviour.

I've put up this page which should work for a few weeks. It uses the Beta Cluster's RESTBase+Mathoid instance, which are identical to production.

https://krinklebot.toolforge.org/mathoid.php

@Krinkle Your page shows an empty image. When I click it, the URL is

https://en.wikipedia.beta.wmcloud.org/api/rest_v1/media/math/render/svg/4c0004393a88f350a93bcef62106d556c7fc827b

"Error: Requests from your IP have been blocked, please see https://wikitech.wikimedia.org/wiki/Beta/Blocked for more information."

But even if it did work, this is not good enough. We need to be able to see the entire rendered content of any Wikipedia article using the old renderer.

@Krinkle Can you please ASAP give us a way to (1) see a particular expression as it renders in "server-side SVG" mode, and (2) give us a way to see an entire English Wikipedia article rendered using the "server-side SVG" mode?

The current situation is completely unreasonable, and is totally preventing us from determining bug status and comparing behavior between versions.

In T271001#12531203, @Jacobolus wrote:

@Krinkle Can you please ASAP give us a way to (1) see a particular expression as it renders in "server-side SVG" mode, and (2) give us a way to see an entire English Wikipedia article rendered using the "server-side SVG" mode?

The current situation is completely unreasonable, and is totally preventing us from determining bug status and comparing behavior between versions.

(1) Download MediaWiki 1.46 and Math 1.46 (via https://www.mediawiki.org/wiki/Special:ExtensionDistributor/Math) and install
(2) Download Mathoid (see https://www.mediawiki.org/wiki/Manual:Mathoid)
(3) Config Math to use Mathoid CLI (https://www.mediawiki.org/wiki/Extension:Math#Mathoid's_CLI_interface)
(4) Get expanded code of an article via Special:ExpandTemplate and put it to the new wiki

That is a completely ridiculous thing to expect every Wikipedia author who wants to see how the old rendering mode worked to do. Like: is this supposed to be self parody?

You should please set that up for us on some WMF-hosted server, ASAP (like, last week), in an accessible way such that it takes no more than a few seconds to see the full rendered content of any Wikipedia article without a requirement to run anything on a personal machine. And without any "Requests from your IP have been blocked" errors. A plausible UI could be: give us a text box into which anyone can paste a Wikipedia article URL, and this server can render the page using the current article markup and all templates, etc., but using the old math rendering mode.

Or: much more simply and reasonably, just turn back on the old rendering mode as an option on English Wikipedia per se, so that it can continue to be used for the essential purpose of fixing the still-broken new rendering mode, until such a time as the new rendering mode is not broken anymore, however long that takes to achieve. (I speculate it will take at least months, but who knows.)

A newly found very serious issue reported by Wikipedians: mathematical notation contained in footnotes is sometimes not appearing at all in the mouse-hover popup footnote boxes (though it does appear in the footnote as rendered at the bottom of the page).

While we're at it, can you folks try to fix the somewhat similar longstanding issue where mathematical notation does not appear in image captions when an image is clicked to bring up the full-screen image viewer? (bug T263572)

@Jacobolus Timo's sandbox is working for me with one example from the MathFormattingBugs page

Can you share a screenshot of your error?