@Krinkle I don't really see anything in the checklist about communicating to the actual end users the mathematical (and chemical) editing community on our main wiki's, rather than a bunch of mailing lists they don't read.

Should there be any sort of User Acceptance Test to ensure the product has an acceptable level of quality, before this is made default. Lets just say some editors are not happy with its current state

RESTbase will be switched off regardless – the alternative is simply not acceptable at the moment, so basically you are continuing to threaten to overnight make all of technical Wikipedia look ugly, illegible, and amateur, without any backup plan.

https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:WikiProject_Mathematics&diff=prev&oldid=1249548295

And there are a whole host of issues raised, only a few of these have made it into bug reports yet. https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:WikiProject_Mathematics&diff=prev&oldid=1246817156

On the Final pre-release QA round by Web Team item, how versed are the QA Web Team, on the fine details of mathematical typography? Is there a way we can supply them with information on what we feel is important?

Just to clarify, the Deploy opt-in user preference for MathJax mode. option is the client side renderer. There are a number of issues with that T375238, a few are blockers, but hopefully these are fixed.

In T271001#10142977, @Quiddity wrote:

For the first Tech News checkbox in Phase2a, please let me know approximately when this will be ready for announcement, and what details need to be included […]

We're currently waiting for the final QA round, and we have a number of early bug reports above to work through. Right now we're not yet pressed for time with inviting more users or entire pilot wikis. We can start drafting a message though. The main take-aways would be:

• invite users to preview native MathML at https://www.mediawiki.org/wiki/Extension:Math/Native_MathML_rollout_(2024), or by opt-ing in via the MathML user preference under Appearance > Math, and report bugs to Phabricator.
• if the exact interaction and styling of the current rendering is preferred, enabling the "MathJax client-side" preference. This will stay long-term.
• The "SVG" option, powered by Mathoid with server-side MathJax, is planned to be removed in the future.

In T271001#10212972, @SalixAlba wrote:

@Krinkle I don't really see anything in the checklist about communicating to the actual end users the mathematical (and chemical) editing community on our main wiki's, rather than a bunch of mailing lists they don't read.

As an active editor and volunteer for over ten years myself, I prefer it when the Foundation does software development in public. As such, the draft is available for everyone to see. The user preference has been live since July 2024. There are known issues being worked through every week since then. I made the call to not announce it widely until we're more confident in it ourselves. There is no set deadline for Mathoid yet, and it's not enabled anywhere by default (beyond beta cluster and group0 testing). As you can see above, there is no shortage of feedback at the moment so we're not in a rush to get wider feedback or enablement yet. It would just waste people's time reporting duplicate/known bugs, and make it less likely for them to try again later to find other issues.

Tech News has been around since 2013, and is sent both on-wiki and via mailing lists to self-appointed embassadors in the community. Indeed, most end-users are not directly subscribed to that. Short of requiring that all users are developers, or that only users are developers, this is inevitable I think. Instead, we rely on the indirection of Tech News to connect these dots. For example, I'm a volunteer on Commons and nlwiki. When I read this in Tech News or on Wikitech-ambassadors, I would bring this to the relevant math/chemistry project page there. Likewise, yourself and others active here in Phabricator can take this to places like WikiProject Mathematics on enwiki. I see you've done that already, which is great.

We generally encourage community members that are tech-savvy to do this outreach directly, exaclty as you did, and liason bug reports back to here. I don't mind doing further outreach myself as well on a handful of suggested talk pages. I speak Dutch, English, and a bit of German :)

Should there be any sort of User Acceptance Test to ensure the product has an acceptable level of quality, before this is made default.

Sure. Acceptence is based on known test cases passing without glitches, and bug reports like those above. I'd consider the following kind of bugs as blockers:

• glitches where symbols appear that shouldn't.
• glitches where symbols don't appear that should.
• glitches where symbols appear in an obviousy incorrect place.

The goal is not pixel identical rendering to MathJax, so the exact font size and spacing may vary. This is in part a feature in that these aspects can now be customised with CSS via user styles, and are decided by individual web browsers. We do have some connections at browser vendors (Mozilla/Google/Apple) so if there are bugs caused by the HTML>screen rendering in browsers, rather than the LaTeX>MathML HTML rendering in MediaWiki, we can help escalate upstream bug reports as well. Free freel to share links to https://bugs.webkit.org/, https://bugzilla.mozilla.org/ or Chromium's issue tracker.

While I've written or edited an odd formula here and there myself, my editing activities are mostly in other subjects. When in doubt, I trust @Physikerwelt assesment of bug reports and community feedback over my own judgement.

On the Final pre-release QA round by Web Team item, how versed are the QA Web Team, on the fine details of mathematical typography? Is there a way we can supply them with information on what we feel is important?

I don't know what criteria or process the Web Team prefer to use for their QA round. If you have a few cases in mind, feel free to suggest them here, that can't hurt. Note though that the QA round informs when we can add the next pilot wikis. It is not directly tied to becoming the default everywhere, and thus is not a substitute for bug reports and the community assessment described above.

Thanks, @Krinkle most helpful.

The above is what the MathML rollout page looks like in my browser. Leaving aside the math font being significantly too large in the top "SVG" example, as you can see, in the MathML version:

• there are many subtle spacing flaws (for example the vertical spacing is wrong in the fraction x/2)
• the superscript 2 uses the wrong font (it uses a scaled-down 2 from a font intended for regular size instead of a properly optically scaled 2 intended for superscript size)
• the two lines at the bottom have been smushed together
• the strikethroughs of the 'y' letters are much too small (and in this font, y is not a legible character to cross out because the strikethrough overlaps the leg of the y)
• the renderer does not understand the explicit alignment directions of the source markup (which asked for left-aligned, center-aligned, and right-aligned) – though this is a poor example because people should be using LaTeX \align instead of \array for this specific thing.

Any page which is intended to be convincing would be much better if it drew a substantial number of complicated examples directly from technical English Wikipedia pages, instead of making up a few contrived and unrepresentative examples.

The goal is not pixel identical rendering to MathJax, so the exact font size and spacing may vary. This is in part a feature in that these aspects can now be customised with CSS via user styles, and are decided by individual web browsers.

This is a terrible idea. There are plenty of manual tweaks required to get math rendering looking good in edge cases or gaps in the default rendering, but which tweak is required differs depending on which font is used. Additionally many fonts just have bad built-in metrics, not to mention poorly distinguished symbols, etc. This entire endeavor is not going to work unless you pick a single specific set of math fonts and ship it down to every reader, so that authors are assured that readers are seeing a nearly identical result. The plan of giving every reader and every device different fonts is not an acceptable way forward for math rendering in English Wikipedia.

In response to the "plan" at the top of this page:

Enable native mathml by default, gradually on all wikis in production (Oct-Nov-Dec 2024).

This is completely non-viable on this timeline. It's nowhere close to ready in its current state, and making it the default on English Wikipedia within the next 2 months would be tremendously harmful and disruptive. It's frankly not clear that MathML would ever be a viable default. (Edit: I took a look at https://en.wikipedia.beta.wmflabs.org/wiki/Help:MathTestNative and quickly lost count of how many layout bugs there are, as my browser renders this page. Literally dozens of distinct problems.)

Client-side MathJax is a more plausible default, but it needs (a) consistent math fonts shipped down to readers, and (b) significantly more testing and feedback to be ready.

The current "SVG" (i.e. server-side MathJax rendering SVGs) is the only option that is currently ready for production use on English Wikipedia.

Thanks @SalixAlba for creating https://www.mediawiki.org/wiki/Extension:Math/Native_MathML/Reported_Cases

I've made a few updates there, reporting here for awareness:

• It now includes both MW MathML (new) and MathJax MathML (normally hidden). This'll make it easier to narrow down whether differences are due to what MathML/HTML we produce (in PHP) vs something that affects both and maybe something we can improve in upstream browsers or via CSS tweaks.
• Both MathML versions now get the same preferred larger font-size as set by enwiki/Common.css

Before	After

Since last week, several bugs have been fixed by @Physikerwelt, @Andreg-p and others.

I'll mention two examples from prod vs current master in Beta Cluster:

https://en.wikipedia.beta.wmflabs.org/wiki/Extension:Math/Native_MathML/Reported_Cases

Task	Before	After
T375907
T375317

In every browser on my computer, looking at https://en.wikipedia.beta.wmflabs.org/wiki/Extension:Math/Native_MathML/Reported_Cases the MathML examples are entirely unacceptable. The MathJax SVG has some issues but mostly looks okay. It's plausible that the problems with the MathML rendering is just down to using bad/broken fonts with insufficient character support, bad glyph shapes, poor metrics/kerning, etc. It's never ever going to work to expect every Wikipedia reader to bring their own math font.

It would be good to meet again to discuss the state of affairs and communicate a plan for WMF and 3rd parties.

In T271001#10364821, @Physikerwelt wrote:

It would be good to meet again to discuss the state of affairs and communicate a plan for WMF and 3rd parties.

@Physikerwelt do you believe we should meet once again to move forward?

Yes

@Physikerwelt should we review "Phase 2A - Production"? My thoughts on the remaining tasks:

• Communication to wikitech-l about plan.
  • I can draft something right away and send in an e-mail for review

• Final pre-release QA round by Web Team
  • We already had a lot of QA rounds by the Web Team so just sharing a reasonable timeline should be sufficient

• Communication to tech news inviting people to try the user preference and/or to sign up as pilot wiki.
  • Have we done this? Should we propose this to the next Tech News?

• Enable native mathml by default, gradually on all wikis in production (Oct-Nov-Dec 2024).
  • Change to (Jun-Jul-Aug 2025)

• Communication to tech news when it's the default everywhere, and upcoming removal of mathoid option, highlighting the MathJax user preference for those who prefer the old look.
  • Nothing to add

• Remove the mathoid option from production (when?).
  • Nothing to add

No you should most certainly not follow any plan like this. The native mathml mode remains completely unready for wide-scale production use, and switching to it as a default for any of the large language Wikipedias any time in 2025 is going to be a huge mess with lots of angry push-back from Wikipedians and Wikipedia readers. Many readers' browsers will render formulas in various broken ways, and most of the rest will have unacceptably ugly spacing and layout problems on many pages.

Instead, the plan should be (and should always have been) to engage directly with the math wikiproject, physics wikiproject (etc.) seeking feedback about what technical wikipedia authors need to support technical encyclopedia articles. Ideally it would have been better to focus on serving those needs rather than charging ahead with projects no one is asking for, but since we're here now, it would be good to get continuing feedback about which currently possible renderers give the best results with each combination of operating system / device / browser / installed fonts.

One of the most important technical pre-requisites is font consistency:

For any client-side renderer, it is strictly necessary to pick a default font for rendered mathematics and ship it down to every reader, rather than relying on already-reader-installed fonts. Mathematical expressions routinely need manual spacing tweaks to look good and remain legible, but the spacing of different fonts differs substantially, making those tweaks impossible if the font is not known in advance.

Another good idea would be to set up a few dozen test devices with different operating systems, browsers, browser versions going back say 10 years, display sizes, etc., and render a large number of example formulas, then get a technical expert to evaluate them. Until all of these look acceptable, a renderer switch is unlikely to be successful.

Edit to add: my guess is that the native MathML renderer will not be acceptable any time in the next 5+ years due to inherent inconsistencies between the wide range of existing browsers being used by readers. If it is decided that rendering must be done client side, I would strongly urge a focus on an SVG renderer as the main priority, as it seems much more likely to succeed. The SVG renderer still will require the adoption of a consistent set of fonts which must be served to every reader on every browser.

Hello,

Like @Jacobubus , I also see the issue with the default font as critical. Chrome's default font for mathematical formulas is far too small and therefore unusable for Wikipedia. If mathematical formulas with this font were set as the default for all users, many readers and authors would be very annoyed.

I would also like to point out that I created in January and February 2025 a total of almost 10 bugs that affect native rendering with MathMl. Most of these have not yet been solved. If you want to make this feature productive by default for everyone, then you will also need human resources who can solve such bugs in the short term.

Thanks for the input @Jacobubus and @Christian1985, this is super helpful feedback.

Just to clarify, we are not intending to cause disruptions. I had the assumption that we were in a good place to proceed, but it seems I was wrong.

It would be super helpful if you can help us creating a more detailed documentation of success criteria. The list of bugs is a great start, but it's scattered and it would be good to have a centralized place to make sure requirements are well structured and aligned with community perspective.

Tend to agree with Jacobolus that its not ready for prime time yet. There has been good work fixing the worse bugs but the rendering is still substandard.

For example, there is not enough space between a function name and the following identifier

See T395488 still quite a few problems in https://en.wikipedia.beta.wmflabs.org/wiki/Extension:Math/Native_MathML/Reported_Cases
and
https://en.wikipedia.beta.wmflabs.org/wiki/Help:MathTestNative

Hallo @MSantos

From my point of view, the most important points for improving native MathMl are, in order of priority:

• Implement a default font for MathMl that is delivered from the server to the client and used to display MathMl.
• Correct spacing in formulas, e.g.: T382680, T382642, T395582, T395488
• Correct the position of indices, powers and primes for large and small operators and characters, e.g. T385948, T382796, T382813, T382669
• Alignment of formulas in blocks, e.g: T375295
• Overline and others over characters, e.g: T352609, T382674, T352698
• Size of brackets: T352946, T388304

In my opinion the #1 requirement for any such potentially disruptive change is to set up a test environment with at least several dozen devices of various display size, operating system, browser, browser version (representing versions back maybe 10 years), and make a test page with a wide range of mathematical expressions drawn from wikipedia articles and shown with sufficient context so that they appear as they would in-article, and then get the rendering across devices evaluated by experts, with release blocked until there has been a sign off that rendering has consistently high quality. This would probably be easiest if a way were figured out to get screenshots of these automatically produced so they could be easily inspected remotely, rather than needing to bring someone to a physical place where the devices sit.

The reason this is important is because there is significant variation in implementation between browsers and significant change from version to version – MathML is not yet a mature stable technology – but any adoption by Wikipedia needs to look professional across a pretty long tail of different setups used by readers. We want to make sure we support people with old devices running older software versions, minority operating systems, etc.; Wikipedia doesn't have the luxury that some sites have of telling everyone to buy a new machine and just install the latest version of Chrome or whatever. The rendering doesn't need to be pixel identical, but it needs to be quite close; it's not acceptable if some readers end up with overlapping letters or ugly wide spacing. It's not acceptable if some readers see particular symbols that are significantly larger than others, compared to the primary font size. It's not acceptable if some readers don't see correctly sized brackets or integral signs. It's not acceptable if some readers don't see equations properly aligned. And so on.

To make a project like this successful, I think it is fairly strict requirement in practice to ship a consistent font or fonts to every reader; this might require cooperation from the wikis. Otherwise, if the font is just a recommended list in CSS left for readers' browsers to figure out, there will be significant additional variation depending on which fonts happen to be installed, etc., making it much harder to test the full range of possibilities.

I think a client-side SVG renderer has a much higher chance of success than a MathML renderer any time in the next several years (until the browsers from a few years ago, whose MathML implementations were inconsistent with current implementations, have aged out of any appreciable browser share). SVG is a fairly mature technology with consistent rendering for a long time now if you stick to core SVG features. Along with a provided font, client-side MathJax-rendered SVG is fairly consistent from one device/browser combination to another, and is used successfully in practice by many technical websites. (This claim of mine is also worth subjecting to a more extensive test though.)

We do have some test pages, one with the standard set of formula from Help:Formula

https://en.wikipedia.beta.wmflabs.org/wiki/Help:MathTestNative

Another has most of the problematics cases listed as sub tasks here,

https://en.wikipedia.beta.wmflabs.org/wiki/Extension:Math/Native_MathML/Reported_Cases

This should allow us to do regression testing.

There is a bunch of testing in code base, but not so visible for non developers.

The page https://en.wikipedia.beta.wmflabs.org/wiki/Extension:Math/Native_MathML/Reported_Cases has completely broken layout so that's not too encouraging. Also this just shows random snippets of formulas out of context, which is okay for testing certain specific features but doesn't do a good job of showing how mathematics appear in context in articles.

(Aside: there's a line with \overset{\underset{\mathrm{def}}{}}{=} to make a decorated = sign there. That won't necessarily have correct spacing; it needs to be wrapped in \mathrel{}, i.e. something like \mathrel{\overset{\underset\mathrm{def}{}}=}. But I tried editing to make that change, and it seems like the math implementation on that page doesn't support mathrel – I'm surprised because English Wikipedia math mode supports it. As an aside to the aside, this overset-underset trick here is a somewhat questionable workaround to make the text smaller since Wikipedia math mode doesn't support manual size commands; if slightly larger text is okay then \mathrel{\overset\mathrm{def}=} would be clearer. In theory \stackrel\mathrm{def}= should be more idiomatic, but that one doesn't seem to get properly spaced in our existing implementation.)

The most important part though is setting up the large number of test devices / environments and then getting a human, ideally someone with expertise in mathematical typography per se, to check them. It's enough work that it would probably be best to hire someone and pay them for it.

Since it's been mentioned, MediaWiki has established compatibility standards and I would encourage that they be read. "10 years and a dozen devices" is not how MediaWiki and by extension its ecosystem is supported.

You'll note particularly that Grade C is a functional experience, not an ideal one.

As far as I can tell all of the browsers in "Grade C" and most of the browsers in "Grade X" currently receive the same high quality math typography from Wikipedia that the "Grade A" browsers get. So if you are suggesting that it's completely fine if every reader who doesn't have "Grade A" browsers or current hardware should receive ugly or even illegible mathematical notation, that would be a huge downgrade/regression compared to current support.

But while we're on the topic, the listed minimal "Grade A" version of Safari has significantly different MathML support than 2025 browsers, and the current MathML renderer is nowhere close to providing "highest level of support" for that browser.

So to amend my recommendation above: every combination of popular device and browser in the "Grade A" category (which apparently includes the past 7 years of Mac/iOS devices, the past 10 years of popular Android devices, and a variety of older and newer Windows and Linux hardware running up-to-3-year-old versions of Chrome, Firefox, and Edge – in all, this will need to involve several dozen configurations) should have some kind of explicit test machine set up with rendering manually checked by an expert, so that we can be sure we are giving these devices the "highest level of support". As far as I can tell there is currently no such testing being done of the MathML renderer, except acceptance of ad-hoc bug reports from a few scattered volunteers sporadically testing things on their own miscellaneous devices.

I think it would be possible, to define native Mathml as the standard only for newer browser. Other could use SVG server rendering as default.

Change #1175174 had a related patch set uploaded (by Physikerwelt; author: Physikerwelt):

[mediawiki/extensions/Math@master] Switch the default tex checker to local

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

Change #1175174 merged by jenkins-bot:

[mediawiki/extensions/Math@master] Switch the default tex checker to local

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

Why isn´t this the default yet?

@Dengamlapotatisen: Because some items in the task description have not been done yet. Time is not unlimited.

@Aklapper Understandable, some concrete issue I could help out with?

@Dengamlapotatisen I am currently discussing a plan with @Krinkle and @MSantos so that this activity aligns well with other WMF goals.

Spec-wise, we are nearing the end. One last thing (relevant to the Wikimedia math code) is the handling of links. This will potentially change every single math equation if we swap from mrow to a elements.

@Dengamlapotatisen, it would be very valuable to have people using the new rendering mode in their user settings and reporting any bugs they encounter. I personally think the MathJax rendering mode looks quite reasonable, and since we use MathJax version 4, it's a bit faster. However, I often see new bugs myself, so I think it could really benefit from more extensive testing. See T375238 for the currently known MathJax bugs.

@Physikerwelt , so would you prefer me to test with MathJax rather than MathMl? MathMl is currently my default setting.

@Christian1985 either is fine. I personally find MathJax more similar to Overleaf which I am using frequently.

New plan for the remaining work (from Dec 2025, per @MSantos, @Physikerwelt and myself).

• Performance review for the new new MathJax client-side mode. @Krinkle — There has been a major upgrade since last time, and the standard is now for all users rather than opt-in.
• Change wmf-config for Math extension from Mathoid to MathML+MatJax on all wikis that have Parsoid and no known <math> usage. @Physikerwelt to provide list of wikis by number of formulas on those wikis. Those with 0 we can switch.
• Implement feature flag in Math extension that switches default to the new mode whenever Parsoid is on. It should not override any logged-in "math" user preference.
• Add pages that use math to the Parsoid visual-diff infra (either a sample of existing pages, plus the local help page, plus maybe a user subpage with a list of cases from mediawiki.org?)
• Figure out a temporary visual-diff run that compares the existing Parsoid-readview wikis with old/new math mode, so that we can catch up and switch those wikis from Mathoid to MathML. Consider switching by user preference generically in visual-diff rather than something specific to the Math extension.

The main difference is that we now aim to enable the MathJax client-side enhancement by default on top of the native MathML <math> mode, as implemented in MediaWiki PHP. This means we retain the benefit of the HTML being portable and functional by default. But, in supporting browsers, when browsing content online on Wikipedia.org, we will also employ MathJax to improve the experience there. In particular, as described in our frontend engineering principles this means Wikipedia mobile apps, Kiwix offline, and HTML dumps (where we don't run on-site JavaScript) work fine. As well Wikipedia.org itself, when the JavaScript payload fails or is too slow (in modern browsers) or is unsupported (in older browsers).

This is motivated by several realizations:

1. The new native MathML parser is now deployed everywhere in validation mode, and is believed to be mature and good enough to serve as input to MathJax (instead of relying on Mathoid for the LaTeX>MathML conversion, and/or doing that part client-side).
2. MathJax has gotten significantly smaller and faster in recent releases, making widescale deployment on Wikipedia likely feasible.
3. There remain rendering differences and readability issues for which the engineering effort and upstream vendor cost cannot (yet) be justified or would not happen fast enough in the short-term to unblock sunsetting RESTBase/Mathoid. Specifically, we believe this is limited to layout rendering, not parsing semantics, which means it can be addressed with progressive enhancement where MathJax improves rendering of the MathML mode, rather than inserting it from scratch and/or depending on Mathoid server-side for that conversion. Over time, as browsers improve further, we may revisit this.
4. Reviewing and assessing progress and deployment confidence by hand is hard to scale across the team without much familiarity with how math formulas are read and expected. We can leverage the existing Parsoid confidence framework and visual-diff infrastructure. However, for that to be feasible, we'd need to set a much higher bar in terms of pixel perfection. It is easier to automate this higher bar, and we can actually achieve that by using MathJax, as the server-side and client-side renderings of those should be the same. In a later effort, outside the critical patah for RESTBase/Mathoid sunseting, we can look at removing dependence on MathJax and improving the MathML rendering itself through CSS and/or upstream browser improvements.

Previous plan (from Aug 2024), preserved here for visibility:

• Phase 1:
  • Develop native mathml support in the Math extension for MediaWiki
  • Deploy opt-in user preference for native mathml mode in production: T370507.
  • Enable native mathml by default on the Beta Cluster: T370507.
  • Develop MathJax mode in the Math extension, for users who prefer the old look […]
  • MathJax mode performance review.
  • Deploy opt-in user preference for MathJax mode.
• Phase 2A: Production
  • Communication to wikitech-l about plan.
  • Enable native mathml by default on group0 and test wikis in production (August 2024).
  • Final pre-release QA round by Web Team
  • Communication to tech news inviting people to try the user preference and/or to sign up as pilot wiki.
  • Enable native mathml by default, gradually on all wikis in production (Oct-Nov-Dec 2024).
  • Communication to tech news when it's the default everywhere, and upcoming removal of mathoid option, highlighting the MathJax user preference for those who prefer the old look.
  • Remove the mathoid option from production (when?).
• Phase 2B: MediaWiki 1.43 Release
  • Enable native mathml by default in Math extension for MediaWiki 1.43 release, and disable mathoid support by default so that new/upgraded installs use the native mathml exclusively, unless a sysadmin specifically adds it back in their $wgMathValidMode configuration (deadline: Nov 2024)

@Krinkle, thank you. This looks very good. A few things, we should clarify.

Reviewing and assessing progress and deployment confidence by hand is hard to scale across the team without much familiarity with how math formulas are read and expected. We can leverage the existing Parsoid confidence framework and visual-diff infrastructure. However, for that to be feasible, we'd need to set a much higher bar in terms of pixel perfection. It is easier to automate this higher bar, and we can actually achieve that by using MathJax, as the server-side and client-side renderings of those should be the same. In a later effort, outside the critical patah for RESTBase/Mathoid sunseting, we can look at removing dependence on MathJax and improving the MathML rendering itself through CSS and/or upstream browser improvements.

I think that, as long as MathJax is maintained by the AMS, we should keep it as an option. If the added benefits are marginal at some point, I would suggest making it not the default.

MediaWiki release:

• Make MathML+MathJax the default in the Math extension (for MediaWiki 1.46).
• Backport latest MathML+MathJax implementation to MediaWiki 1.43/1.44/1.45 branches.
• Backport enabling of native MathML+MathJax by default to MediaWiki 1.43/1.44/1.45 branches, and disable Mathoid support by default so that new/upgraded installs never use Mathoid (deadline: Nov 2024)

Setting-wise, we have already removed mathoid and made native (MathML) rendering the default for 1.43 (as it's LTS). We still might want to backport fixes (as always).

Most wikis use only very simple Math, so I think I would stay with the default native mode here. Admins of wikis that use advanced math can still easily change it. However, MathJax introduces additional complexity, making it much harder to understand what goes wrong in that particular setup. I would suggest removing this from this ticket, as it's more or less unrelated.

One important point: after Mathoid is disabled in Wikimedia wikis, we need to retire the RestBase Mathoid endpoint (https://wikimedia.org/api/rest_); and we also need to retire the Mathoid MathML endpoint (https://mathoid-beta.wmflabs.org). Retiring these two endpoints will have an impact on 3rd party users using older MediaWiki versions, so we need to announce in advance.

1. People testing the client-side MathJax mode on English Wikipedia still are making routine bug reports about pages that look fine with the previous default rendering but broken with the experimental rendering modes. All of those should be ironed out before anything like this can be made default.

2. A much clearer and better visual test page needs to be set up so that interested editors can carefully examine the slight details of the various rendering modes side by side. The existing page of this type is a mess and makes critical examination too difficult.

3. There needs to be significant testing across platforms, browsers, and browser versions, which I haven't yet seen any evidence of. Wikipedia has a standard of supporting a wide range of reader devices with high quality output, and it is unacceptable to ship anything which breaks rendering for officially supported devices.

4. Before a client-side rendering can be used, it is absolutely essential that Wikipedia can ship a consistent math font to every reader, with consistent font metrics. Is that happening now / planned? Nobody will give me a straight answer on this point after repeated requests for clarification. For least disruption I would recommend just shipping some Computer Modern variant, since Wikipedia has been using it in math tags for two decades by now.,

(If we are shipping a consistent math font, we should provide it to readers irrespective of rendering mode, and we should also use the same font from HTML for English Wikipedia's "math" templates.)

made native (MathML) rendering the default

5. From what I have seen the MathML mode is still unacceptably buggy for Wikipedia, and due to inherent limitations of MathML differences between platforms and browsers is unlikely to be acceptable as a default within the next 5 years. Nothing should be made default on English Wikipedia without solid consensus of Wikipedia editors working on technical pages.

In T271001#11500931, @Jacobolus wrote:

1. People testing the client-side MathJax mode on English Wikipedia still are making routine bug reports about pages that look fine with the previous default rendering but broken with the experimental rendering modes. All of those should be ironed out before anything like this can be made default.

You mean it should not be ignored? The MathJax problems are tracked here T375238.

2. A much clearer and better visual test page needs to be set up so that interested editors can carefully examine the slight details of the various rendering modes side by side. The existing page of this type is a mess and makes critical examination too difficult.

That would simplify my life significantly. Any help would be highly appreciated. I am using https://github.com/wikimedia/mediawiki-extensions-Math/blob/master/doc/main.pdf as a reference on how things are supposed to look. But it misses more complex examples. In https://phabricator.wikimedia.org/T412658 I am trying to find a way to show the rendering in different modes. A lot of code is already in place, but the examples need to be organized more effectively.

3. There needs to be significant testing across platforms, browsers, and browser versions, which I haven't yet seen any evidence of. Wikipedia has a standard of supporting a wide range of reader devices with high quality output, and it is unacceptable to ship anything which breaks rendering for officially supported devices.

MathJax is not a new tool; many sites have been using it for years. So I don't expect big surprises here. Even for browsers without JS, one is still able to read the MathML (with suboptimal spacing).

4. Before a client-side rendering can be used, it is absolutely essential that Wikipedia can ship a consistent math font to every reader, with consistent font metrics. Is that happening now / planned? Nobody will give me a straight answer on this point after repeated requests for clarification. For least disruption I would recommend just shipping some Computer Modern variant, since Wikipedia has been using it in math tags for two decades by now.,

(If we are shipping a consistent math font, we should provide it to readers irrespective of rendering mode, and we should also use the same font from HTML for English Wikipedia's "math" templates.)

That should also be a problem for the current SVG rendering. Certain symbols are just embedded into the SVG image, thus the rendering depends on browser fonts. https://mathfonts.github.io/ provides a current overview. Is that something that should be decided for all languages, or is that something you would see in the hands of the individual wiki admins?
Mathjax uses Computer Modern as default https://docs.mathjax.org/en/v4.0/output/fonts.html, so all is fine?

made native (MathML) rendering the default

5. From what I have seen the MathML mode is still unacceptably buggy for Wikipedia, and due to inherent limitations of MathML differences between platforms and browsers is unlikely to be acceptable as a default within the next 5 years. Nothing should be made default on English Wikipedia without solid consensus of Wikipedia editors working on technical pages.

Rendering can be configured per wiki. For the global default https://meta.wikimedia.org/wiki/Wikimedia_Community_User_Group_Math is the place for community consensus.

The meta talk page Talk:Wikimedia Community User Group Math is completely worthless. There is zero meaningful discussion and mountains of off-topic Wikimedia organization spam. You should probably start at somewhere like the math wikiproject and maybe physics wikiproject on English Wikipedia. (I am not familiar with other language Wikipedias).

English Wikipedia makes even less sense as that would exclude every other project out there. That is exactly what Meta is meant for.

In practice, nobody ever discusses anything at Talk:Wikimedia Community User Group Math (perhaps because it is full of spam), and if you put a question there nobody will read it and it will serve no useful purpose.

I don't know which of the "every other project out there" write a lot of complicated mathematical notation, but feel free to reach out to them and to other-language Wikipedias. I would strongly recommend against going ahead with any plan that you can't get some kind of consensus support for from the relevant projects of English Wikipedia. Doing so is basically betraying the primary purpose of mediawiki.