WMF/Mediawiki developers intend to force a new math rendering pipeline within the month

See https://phabricator.wikimedia.org/T271001

You can test the client-side MathJax rendering option, which is going to be made a site-wide default soon, by going to the "Appearance" preferences section and choosing "Client side MathJax rendering".

In my opinion the current preference-gated version of this shipping in English Wikipedia is unacceptably bad. I notice dozens of significant alignment and rendering problems when I go to Help:Displaying a formula, as an example. (Ping User:Krinkle.) It's not clear to me if there's a newer version which fixes some of these problems, but I'm guessing not.

I'd urge mathematics or other technical editors to take a look for yourselves and see what you think. In my opinion deploying this in its current state would be a typographical disaster.

In my opinion the WMF people / Mediawiki developers involved haven't really tried to engage with the Wikipedia editing community, and haven't done a good job of communicating their plans or process. I don't know what the best way is to give them feedback – cluttering their ticket tracker with complaints might be more annoying than helpful. There was a discussion on this talk page months (years?) ago, but I don't think all of the bugs that were reported at that time were actually fixed, and some of the developers involved didn't really seem to be listening to the feedback which was given at that time. –jacobolus (t) 00:17, 6 August 2026 (UTC)

If it were actually client-side MathJax (as the default) it would not be so bad. Client-side MathJax is used all over the web for professional mathematics and works well. But no, it is MathML processed via server-side MathJax. So your instructions need correction: to see a sample of this, change your preferences to MathML. I continue to stand behind what I wrote about MathML over ten years ago .

The phab site you link is tagged as "community consensus needed". Does this actually mean anything? —David Eppstein (talk) 01:53, 6 August 2026 (UTC)

Whether "community consensus needed" tag means anything can depend on who added it and why. If devs are making concrete plans (as they seem to be here) I would lean towards things are moving forward regardless. However the devs involved are known for being reasonable, I'd suggest just making sure your concerns are known to them. Bawolff (talk) 02:22, 6 August 2026 (UTC)

I feel like concerns have been aired repeatedly, and the response feels dismissive. To paraphrase: "we're going to get rid of the previous rendering pipeline ASAP whether or not the new one is ready, because it's annoying to keep maintaining the old one." –jacobolus (t) 03:04, 6 August 2026 (UTC)

To be clear: there are 3 different rendering pipelines, and none of them is the usual idea of client-side MathJax (have raw LaTeX markup in the served page and use a client-side library to turn it into a rendered result).

1. (Current method) Render LaTeX to SVG on the server, and send the SVG to the browser
2. (Proposed new default) Render LaTeX markup to some intermediate MathML format on the server, and convert that to SVG on the client side using MathJax
3. (Intended long-term solution that is even buggier) Render LaTeX markup to MathML on the server, and let browsers deal with rendering it

Method #2 is what the preferences calls "client side MathJax". In my opinion this is still dramatically broken and unacceptable to ship as a site-wide Wikipedia default. But it seems plausible that this could be made to work.

I think method #3 is years away from being viable, because recent (and maybe current) mainstream browsers have wide variability in their MathML rendering, in ways that can't be obviously worked around. –jacobolus (t) 03:02, 6 August 2026 (UTC)

I didn't realize their definition of "client side MathJax" was so broken. Ugh. I have struck my comment about how to preview whatever witches brew of formats they are churning up because it was based on a good-faith but incorrect assumption that client side MathJax was actually client side MathJax. —David Eppstein (talk) 05:51, 6 August 2026 (UTC)

Caveat: I haven't looked at the code. The above is just my understanding based on descriptions in that bug tracker issue. –jacobolus (t) 06:03, 6 August 2026 (UTC)

I keep track of the bugs discussed back then in my user page: User:Tercer/math. All of the client-side MathJax ones have been fixed, but three MathML bugs remain. Tercer (talk) 14:27, 6 August 2026 (UTC)

That just means nobody has gone looking for bugs. If I go to Help:Displaying a formula I see a wide range of broken examples. If you want I can list a few. –jacobolus (t) 16:07, 6 August 2026 (UTC)

Here are the first few issues I see in my browser:

• <math display=block> centers output instead of the long-standing Wikipedia style (left alignment with an indent)
• "\Omega" (⁠${\displaystyle \Omega }$⁠) uses the wrong symbol – shouldn't be italicized
• "\pm" has the wrong vertical position (the minus part is below the baseline) – perhaps uses the wrong font
• "\backslash" is the wrong shape and size, doesn't match "/" – again, perhaps the wrong font
• prime is too far from the letter in ⁠${\displaystyle x'}$⁠.
• derivative dots in ⁠${\displaystyle {\ddot {x}}}$⁠ are too small, hard to read
• spacing around + signs with an overbrace is completely wrong, in ⁠${\displaystyle \overbrace {1+2+\cdots +100} ^{5050}}$⁠
• Sum in a fraction uses the wrong format (should be inline style), in $${\displaystyle {\frac {\sum _{k=1}^{N}k^{2}}{a}}}$$
• Lower limits of integrals are universally too far from the integral sign
• Text style binomial coefficient is the wrong size ⁠${\displaystyle {\tbinom {n}{k}}}$⁠
• all types of ellipsis use the wrong font, messing up an example like $${\displaystyle {\begin{bmatrix}0&\cdots &0\\\vdots &\ddots &\vdots \\0&\cdots &0\end{bmatrix}}}$$
• There's not enough horizontal whitespace space between the contents of a matrix and the brackets surrounding it, e.g. in $${\displaystyle {\begin{pmatrix}x&y\\z&v\end{pmatrix}}}$$
• There's not enough horizontal whitespace after the brace in the 'cases' environment
• The "align" environment has moderately broken whitespace, and "alignat" is completely broken.
• There's not enough space after the equals sign in ${\displaystyle f(x)={}}$ which means that a long inline equation broken up into multiple math tags to allow line breaks will have incorrect space between parts
• Lines between cells in the 'array' environment are not rendered at all
• Text-style fractions (⁠${\displaystyle {\tfrac {1}{2}}}$⁠) have substantially incorrect vertical spacing

That's errors I see at a glance in the first third or so of Help:Displaying a formula. If developers are serious though, they need to collect a range of examples, set up some kind of test infrastructure where they are rendered on a wide range of output devices and browser versions (a representative sample of "Grade A" browsers listed at mw:Compatibility) with the screenshots of those saved somewhere that someone can inspect them and make sure that they render correctly.

The default rendering doesn't necessarily need to be pixel-precisely the same as the previous rendering, but anything made default needs to be nearly identical across devices and browsers so that editors can predictably target it. That means that the fonts used for all math symbols have to be the same (provided by Wikipedia, not just using whatever is installed locally), because it's sometimes necessary to use spacing workarounds to handle tricky examples where LaTeX messes up, and if the fonts are inconsistent things will break. –jacobolus (t) 17:01, 6 August 2026 (UTC)

Several of these rendering errors, with the markup given above, are equally visible to me (Vector2022, Client-side MathJax, OS X, Firefox). In particular this is true for the display-block centering (a showstopper by itself as this is used in approximately 7000 English Wikipedia articles, often mixed with block-indented formulas when math and non-math appear on the same displayed line), Omega (also likely in thousands of articles), addition under overbrace, sum in fraction, text-style binomial coefficient (hundreds of articles), formula ending in an equal sign, and text-style fractions (thousands of articles). If I didn't mention others it is only because the effects are more subtle or I didn't have an example visible in this very thread. —David Eppstein (talk) 18:21, 6 August 2026 (UTC)

The text-style binomial coefficient rendering alone, with small parameters set inside huge parentheses with wide spacing within the parentheses, is so horrific that, after seeing its effect on Sperner's theorem, I am going back to the SVG preference setting. I can't stand it. The old Wikipedia mathematics rendering is bad but this is worse. It is far from ready for prime time and, if user community consensus is indeed required for deployment, I strongly oppose any such consensus here. —David Eppstein (talk) 20:39, 6 August 2026 (UTC)

NB. I can confirm that Sperner's theorem still has obvious rendering issues under the "Client side MathJax rendering (for browsers with limited MathML support)" setting, and is even worse under "MathML (experimental; no images)" (though I don't think that's the one they're proposing to roll out).

I was under the impression they were going to take @Jacobolus's advice seriously, as a representative of the enwiki math community; if not, what other user acceptance testing have they been doing? Preimage (talk) 10:56, 9 August 2026 (UTC)

I poked around to learn more but I have to say I mostly failed. However, if this Extension:Math page is correct, then it seems like it would be possible to create a set of side by side (or over/under) comparisons between the default rendering technology (whatever that is) and proposed replacements, eg default

$${\displaystyle \Omega \pm x'={\tbinom {n}{k}}}$$

vs forcemathmode=native

Text accompanying the examples could explain what is objectionable. The lot could be input to bug reports.

Unfortunately I can't figure out which forcemathmode corresponds to the proposed rollout. Johnjbarton (talk) 21:48, 6 August 2026 (UTC)

I think that would be forcemathmode=mathjax, but I'm not entirely sure. –jacobolus (t) 20:16, 8 August 2026 (UTC)

Please do not use forcemathmode=mathjax in main space articles, that options is added for developers who want to test different formats. It would stop users from being able to set use their preferences. It would cause a bad clash of styles in a single page unless every math tag in the page also had forcemathmode. --Salix alba (talk): 16:57, 9 August 2026 (UTC)

Nobody is going to add forcemathmode to articles. The question is what to add to test pages so we can compare the two renderings. –jacobolus (t) 17:16, 9 August 2026 (UTC)

To explain the reasoning behind this, the current system uses an image caching system, so the images are not recalculated every time you edit a page. This system uses something called RestBASE, a ten year old system that is very flaky. Personally I have spent a lot of time correcting cases when the caching failed, at one point I was having to do several null-edits per day to force re-rendering of main space articles. There is a whole category Category:Articles with math render errors with 350 non main space pages with caching errors. The WMF have been wanting to get rid of (sunset) RestBASE for a long time, and I think it is now only the maths engine that uses it. RestBASE also make it very hard for other sites to install MediaWiki with mathematics support. So there are a lot of good software engineering why we need to move to a new system.

The other reason is that browsers have moved on a lot since this system was introduced over ten years ago. At that time MathML support was virtually non-existent, now all the major browsers have good MathML support. Part of this change has been because the MathJax team have been lobbying for improved MathML support. MathJax itself was only introduced as a stop-gap for lack of decent in-browser maths support, and their eventual aim is to go to a pure Latex to MathML system.

We have been working for two or three years on implementing this change. I've probably submitted 30+ bug reports to fix errors in the rendering, see for example T375318 • TNative MathML mode formatting bugs and T375238 • TClient-side MathJax rendering problems. The state of the system is very much better than is was a couple of years ago. To my mind there is only one bug T382267 I would consider a blocker. This is about how the <math> works with {{blockquote}}, which require a fix to MediaWiki code, and is not something those working on the Math extension can fix.

So what is going to happen? There will be four options, see T433891

• LaTeX source (for text browsers)
• MathML only
• MathML with SVG image (client side MathJax rendering)
• MathML with SVG image (server side MathJax rendering)

I think the default will be the last one. Eventually, the last option will be removed, but that won't be for a good while yet. (@Krinkle: am I correct here?).

If you think there is a bug, I'm happy to file a report for this. --Salix alba (talk): 16:40, 9 August 2026 (UTC)

What does the updated pipeline use for caching, if not RestBASE? Presumably whatever rendering work is happening on the server side still needs to be cached. There's no inherent reason why the previous rendering method must use RestBASE as a component. It was a choice made by Mediawiki developers to transition to an entirely new rendering pipeline instead of trying to adapt the previous one to a different infrastructure component, but they made that choice without consulting or even informing the community of Wikipedia authors.

My understanding is that the 4th of your bullet options is intended to describe the current default, and the 3rd of your bullet options is the proposed new default. The change-over is proposed to happen within 2 weeks.

As a separate topic, here's what the MathJax site says about MathML:

While MathJax version 2 included a NativeMML output jax for producing MathML output in the web page, support for MathmL in browsers was spotty, and the results varied across browsers and operating systems, sometimes requiring additional fonts or plugins to be used. This meant that the quality of the output could not be assured, and for these reasons, the MathML output renderer was removed in version 3.

Today, most modern browsers include support for MathML-Core, which is a limited subset of the full MathML specification. While this is an improvement over the past, MathML-Core does not include some important features that are needed by MathJax (the <mlabeledtr> element needed for numbered equations, and most of the table attributes needed for [alignment environments], for example), so a native MathML output format is still not included in version 4. [...]

[...] So while it is possible to produce MathML output, the browser’s native MathML rendering may not be up to the task for displaying it as well as MathJax would.

Some current browsers' MathML rendering is not ready for Wikipedia to directly use MathML output. Any particular browser version will still be in use in several years after its release. The way this kind of browser feature works, for a site like Wikipedia we have to basically wait every current browser to have solid support for a feature, and then after that we have to additionally wait for every browser older than that to fall out of use. For example, a Safari version from 2019 is still listed among those requiring "Grade A" support at mw:Compatibility. So being able to use MathML output as a Wikipedia default is optimistically at least a decade away. –jacobolus (t) 17:41, 9 August 2026 (UTC)

To my mind there is only one bug I would consider a blocker.

The broken alignment environments are a catastrophic show-stopping regression. Several of the other rendering problems are in my opinion also serious and must be fixed. Some are about broken alignment/layout, and others are about choosing the wrong fonts for various symbols. All of these seem fixable in principle, but I would be very surprised if it were done within a few weeks. –jacobolus (t) 21:08, 9 August 2026 (UTC)

@Salix alba Please report a bug for me: there is no end-user, jargon-free way for editors to test the proposed new math change. If the new math is largely satisfactory, then there is no harm in letting editors take it for a spin. When they see it is ok, the rollout will be fine. If the change is deployed and the results are terrible, a lot of people will waste a lot of time raising hue and cry, followed by rollback, and further angst. To be clear, don't tell me about MathJaxServerSideSVGMLImagesRendering1902. Just explain what setting will trigger the to-be-rolled out math view without guessing. Johnjbarton (talk) 04:04, 10 August 2026 (UTC)

You can trigger the to-be-rolled out math view site-wide by changing your preference setting at Special:Preferences § mw-prefsection-rendering. Scroll down to the "Math" section and choose "Client side MathJax rendering". In theory (as far as I understand) <math forcemathmode=mathjax>...</math> is supposed to force this style of render for a single expression, but in my testing it doesn't actually work as intended, instead causing the same rendering as the (server-side) "SVG" option. –jacobolus (t) 04:50, 10 August 2026 (UTC)

Well that setting makes every single equation wrong, making me thing something can't be right here. Johnjbarton (talk) 05:00, 10 August 2026 (UTC)

Yes, I agree it's currently broken, which is why I've been urging the Mediawiki developers to reconsider deploying this as a default in 2.5 weeks. –jacobolus (t) 05:47, 10 August 2026 (UTC)

I've created Wikipedia:WikiProject Mathematics/MathFormattingBugs You can add a test case to the table there. See my comment below for details. --Salix alba (talk): 13:57, 10 August 2026 (UTC)

@Salix alba Again, this does not actually use the "client side SVG" mode to render that column. –jacobolus (t) 16:21, 10 August 2026 (UTC)

After reading Salix alba's comments, I realized that RestBASE is in a similar situation to Adobe Flash Player. It seems we need to discuss this with MediaWiki developers, but WP:WPM doesn't appear to have any explanations about Wikimedia Community User Group Math or Phabricator.--SilverMatsu (talk) 00:42, 10 August 2026 (UTC)

meta:talk:Wikimedia Community User Group Math is completely useless. It's just a place where various bots park spam messages about once a month, and humans never interact. –jacobolus (t) 04:53, 10 August 2026 (UTC)

Thank you for the link, it certainly looks like that talk page isn't working. It would be better to archive unnecessary threads. Also, just like Wikipedia:WikiProject Deletion sorting/Mathematics lists multiple AfD discussions, wouldn't it be possible to display the discussions from this thread on Talk:Wikimedia Community User Group Math?--SilverMatsu (talk) 11:41, 10 August 2026 (UTC)

It seems to me that what is proposed is not a rollout of MathML, but rather of client-side MathJax. I looked at Sperner's theorem, for example, and does not look broken with this setting enabled in Special:Preferences. The MathML setting is clearly broken, but I don't think that is what is being rolled out. Maybe I am missing something. Someone should make a more comprehensive test page for the issues. Sławomir Biały (talk) 07:50, 10 August 2026 (UTC)

Sperner's theorem has a number of issues with the client-side SVG mode. Here are the ones that are most noticeable to me: First, all of the text-style binomial coefficients have their parentheses bumped up two sizes but still have the same font size for symbols inside. These look really awkward both inline in the text and in fractions in display equations. (Aside: I wish we had an easy way of picking a specific font size from Wikipedia math tags. The usual LaTeX font size commands are not implemented.) Second, all of the display math is centered instead of indented. Third, toward the bottom a matrix with square brackets is used for q-binomial coefficients. These all have the brackets crowded very tight around their content. Fourth, all of the ellipses use the wrong font, with dots tightly space, and e.g. are not vertically centered in ${\displaystyle S_{0}\subset S_{1}\subset \dots \subset S_{r}}$. –jacobolus (t) 18:14, 10 August 2026 (UTC)

Some of the ellipses are centered and others are not. The issue with the ones in the formula with subsets that you show appears that they are coded with \dots (which should choose automatically between \ldots and \cdots) but that the new code is not smart enough to pick \cdots for subset relations. —David Eppstein (talk) 19:33, 10 August 2026 (UTC)

Yes indeed. If you hand LaTeX markup to MathJax it handles this correctly, so I'n not sure exactly what's going on. This kind of edge case is why it would be better to use either already working code or something external that is well-tested, instead of having Mediawiki roll its own custom math rendering pipeline. –jacobolus (t) 20:12, 10 August 2026 (UTC)

Can everyone please take at least a few minutes and browse around a handful of technical articles with the math preference setting set to "client-side SVG" and compare to the way it looks with "server-side SVG", and report any inconsistencies or issues you find? The WMF / Mediawiki developer folks are still planning to roll this out ASAP (their current English Wikipedia deployment date is 3 September), and they have removed "Community consensus needed" as a pre-requisite, while still doing no direct outreach here or at other wikiprojects (if anyone is active on e.g. Wikiproject Chemistry or Wikiproject Physics, consider starting a discussion there too). If there are any extant bugs that you consider essential to fix, the sooner those get reported the less likely we are to have dramatic breakage across large numbers of articles. –jacobolus (t) 20:21, 21 August 2026 (UTC)

I have been browsing with client-side SVG for a long time, and I have seen only minor issues. I'm glad they're doing the switch sooner rather than later, Wikipedia has been stuck in the stone age of math rendering for way too long. Tercer (talk) 20:50, 21 August 2026 (UTC)

After this switch Wikipedia/Mediawiki will still have a bespoke math rendering pipeline with its own LaTeX dialect, which will then be based around combining a brand new PHP program for converting LaTeX markup to MathML (used by no one else) with a non-standard use of MathJax for converting that MathML to SVG. The whole thing will primarily be maintained by one unpaid volunteer with (limited?) support from paid WMF staffers.

I'm not sure what would make this more or less "stone age", but at least so far there aren't any new features coming, just some change of infrastructure code and various backwards incompatibilities in rendering. –jacobolus (t) 22:56, 21 August 2026 (UTC)

I've looked at a few articles on my watchlist. On my setup (Firefox 140.10.1esr), the main problem is by far the fact that uppercase Greek letters are italicized most of the time -- but not all the time. For instance, see the sentence starting with "The following table shows" in Normal distribution (or compare the section "As a compound distribution" to the infobox in Beta-binomial distribution). Not only is this non-standard, this also leads to incoherent notation within some articles.

Besides that, I noticed that the sizing of "widehat" does not seem very coherent -- see for example section "Method of moments" in Beta-binomial distribution. More generally, the decreased font weight makes formulas a bit less readable for me (and of course the centering is a nightmare). Malparti (talk) 23:20, 21 August 2026 (UTC)

Oneofthebiggestissuesforme isthatformulasarecrammedtogether withoutanyspacing, for instance in squared triangular number, when they occur within \left \right fences or overbraces. Another is the centering of displayed block formulas inconsistent with the way we often format display math in situations where it cannot be rendered as a single displayed block (the same article also has :-indented math that should probably be fixed, as well as a :-indented display that is rendered as text not math for the OEIS sequence, in part because the OEIS link at the end of that line cannot be part of a formula). The crammed together formatting is listed at Wikipedia:WikiProject Mathematics/MathFormattingBugs but without any tracking phab number. The centering of formulas was discussed above and I thought it was supposed to be fixed but I'm still seeing it.

Another bug is visible in the same article in its first reference, and I'm not sure it matches any in MathFormattingBugs. The previous bug where inline-text binomial coefficients produced excessively large parentheses and excessive spacing around the parentheses appears to be fixed, in the case that those binomial coefficients are coded using tbinom. But the bad parentheses and bad spacing is still evident using the (obsolete but not incorrect) mathematics coding \textstyle{n+1\choose 2} which is or was present in that reference: ${\displaystyle \textstyle {n+1 \choose 2}}$.

User:Tercer, if you don't see these very obvious issues in squared triangular number then I suspect we are using different formatting preferences. That's part of the issue here: there are many choices and it's difficult to guess exactly which combination of settings is the default or is likely to become the default. I'm seeing these with "MathML with SVG image (client-side)" and with parsoid set "According to wiki configuration (default)", if that matters. —David Eppstein (talk) 23:49, 21 August 2026 (UTC)

Looking at that article, I assume the "crammed together" issue you mention is mostly the one to do with what happens inside overbraces/underbraces?) I don't think there's an issue yet in the tracker for that one, but there should be. It seems to affect a variety of contexts, e.g. also under "overline", and within "\left \right fences" when there's an exponent (are there others?), and where it appears is a pretty serious problem.

I wonder what the best way is to generate examples with every combination multiple levels deep of various nested grouping methods (square roots, overbars, fractions, exponents, etc.), so we can make sure any edge-case bugs in the combinations are handled properly. –jacobolus (t) 01:21, 22 August 2026 (UTC)

I don't understand anything about any of this, but as requested, here are some bugs in the visual appearance of "server-side SVG" compared with what I usually use (apparently "client-side SVG"), from Affine symmetric group:

• There's the thing with displayed equations being centered that I think is amply discussed above.
• In the equation ${\displaystyle s_{i}s_{j}=s_{j}s_{i}}$, on both sides of the equation, the first subscript is closer to the second s than to the first s.
• The sometimes-italicization of capital Greek letters is awful.
• Something about ${\displaystyle \overbrace {s_{0}s_{1}\cdots s_{0}s_{1}} ^{2k{\text{ factors}}}=[1+2k,2-2k]}$ looks bad but I'm not sure exactly what. (Actually it looks even worse inline because it's not vertically in the right place, but even displayed something is wrong with the left side -- maybe just not enough spacing?)

This does not include things that are different from before but not obviously/necessarily bugs, like the fact that mathcal produces a different font. --JBL (talk) 18:13, 22 August 2026 (UTC)

I think the "not sure exactly what" may be mostly down to the dots in the ellipsis being spaced too close together and not enough horizontal space before/after it. But also the overbrace seems too close. –jacobolus (t) 19:59, 22 August 2026 (UTC)

One particularly ugly example from the bottom of that article does a nice job showing one of the serious space-eating bugs:

${\displaystyle \left[{\frac {x\cdot {\frac {\partial }{\partial {x}}}\log(\exp(x;q))}{1-t\exp(x;q)}}\right]_{x\mapsto x{\frac {1-t}{1-q}}}}$ (current math rendering) vs.

(proposed new rendering)

–jacobolus (t) 06:07, 23 August 2026 (UTC)

My eyesight is not as sharp as it used to be, and on reading the second example I wodered for a few seconds what "texp" was. I then looked at the first example and realised that the "t" was italicised and should be read separately from "exp". Maybe at my age I should stop trying to do mathematics because my brain is certainly not as sharp as it used to be. Phil Bridger (talk) 08:14, 23 August 2026 (UTC)

Sorry if this has already been mentioned (it probably has, but the thread is getting a bit long and hard to follows), but on my set up I've just other major bugs:

1. inline equations sometimes get displayed on their own lines. I'm not sure exactly where and why this happens, as this seems to happen in a variety of situations. But it's actually not that rare; for me, it happens, e.g, at the end of Asymmetric_Laplace_distribution#Alternative_parametrization ("For small ${\displaystyle \beta }$ [...]") and in Cantor_set#Mandelbrot's_construction_by_"curdling" ("imagining the construction of ${\displaystyle {\mathcal {C}}}$");
2. Convergence_of_random_variables#Properties_4 is completely broken: instead of displaying the symbol above the arrow, I get a yellow box with "mover" written in red inside...
3. (a more minor issue: the inconsistent sizing of hat also applies to tilde)
4. (as mentioned several times already, there are serious spacing issues in a variety of contexts...)

Malparti (talk) 20:33, 23 August 2026 (UTC)

mjx-container[display] {
    display: block;
    text-align: left;
    justify-content: center;
    margin: .7em 0;
    padding: .3em 2px;
    margin-left: 3em;
}

mjx-container[display] {  
	text-align: left !important; 
	margin-left: 1.6em !important;
    margin-top: 0.6em;
    margin-bottom: 0.6em;
}
math.mwe-math-element-block {  
	display: flex;
  	align-items: left;
  	justify-content: left;
	margin-left: 1.6em !important;
    margin-top: 0.6em;
    margin-bottom: 0.6em;
}
span.mwe-math-fallback-source-display {  
	margin-left: 1.6em !important;
    margin-top: 0.6em;
    margin-bottom: 0.6em;
}

|-
|| 2 open || {{/RowFormat| 1= x\pm y }} || \pm" has the wrong vertical position (the minus part is below the baseline) – perhaps uses the wrong font

A reliable source

I have found a book Mysteries of the Equilateral Triangle by Brian J. McCartin, published by Hikari LTD. Is this reliable? Here's the link . Dedhert.Jr (talk) 03:30, 7 August 2026 (UTC)

I think we would consider Prof. Brian J. McCartin to be an expert, eg ACM, 2010 Chauvenet Prize and the topic is within his expertise.

• Self-published expert sources may be considered reliable when produced by an established expert on the subject matter, whose work in the relevant field has previously been published by reliable, independent publications.

Note that the book is highly sourced itself, which is both a sign of a reliable source and a source of probably reliable sources. Johnjbarton (talk) 04:40, 7 August 2026 (UTC)

Alexander Soifer is seemingly skeptical of its publisher's reputability and surprised by the book's lack of proofs . But I agree that as a longtime mathematics professor and Chauvenet Prize recipient we can treat McCartin as a recognized expert. —David Eppstein (talk) 05:22, 7 August 2026 (UTC)

Should we propose this to WP:RSN, then? Dedhert.Jr (talk) 13:01, 7 August 2026 (UTC)

Discussions are open at WP:RSN#Mysteries of the Equilateral Triangle by Brian J. McCartin. Dedhert.Jr (talk) 14:07, 7 August 2026 (UTC)

Here's a nicer review from Philip J. Davis in SIAM News. –jacobolus (t) 18:39, 8 August 2026 (UTC)

At a glance the content seems okay – it looks like the author knows a lot about this topic and was trying to be careful. The publisher is very dubious; I would consider this to be self-published and without editorial filter or checking, the book analog of an arXiv preprint. But it's probably among the more comprehensive lists of miscellaneous equilateral triangle trivia you'll find anywhere, so probably worth linking from the external links section even if we didn't cite it for anything. Since the author cites plenty of other sources, it may be possible to (also, or instead) look through to his source for any claim we want to include in the article. –jacobolus (t) 17:00, 8 August 2026 (UTC)

All I could say from my perspective is that if this book is a sourcable for citing applications of an equilateral triangle, I prefer to cite additional sources. For example, I like how the book explain more applications, such as the usage of equilateral triangles in satellite geodesy, but for the origin source, I could not find it. Somewhat off-topic, but I can't find it anyway.

• Cole, George M. (2010). The Beginnings of Satellite Geodesy. Professional Surveyor Magazine.

Dedhert.Jr (talk) 16:11, 9 August 2026 (UTC)

@Dedhert.Jr: Part 1 (Jan 2010), Part 2 (Mar 2010). –jacobolus (t) 18:52, 9 August 2026 (UTC)

@Snowman304 (who just removed this and some other sources) You might want to engage here, or on the article talk page. –jacobolus (t) 16:49, 8 August 2026 (UTC)

Hi jacobolus. I use User:Headbomb/unreliable, and it showed up as deprecated/predatory, so I assumed it was safe to remove. Sorry! Snowman304|talk 17:10, 8 August 2026 (UTC)

No worries. I agree that essentially self published sources are sketchy and we should be careful about them. Then again, these days some books published by e.g. Springer have no apparent editing, editorial filter, or publisher support, and might as well be self published. –jacobolus (t) 17:47, 8 August 2026 (UTC)

Hikari is absolutely a shit/predatory publisher. But the book being (positively) cited by others is what makes it legit. It can definitely be used under WP:EXPERTSPS. Possibly with a comment in the edit window to prevent drive-by removals. Headbomb {t · c · p · b} 16:06, 9 August 2026 (UTC)

Sometimes previously reliable people become less so. That is, they become senile or sell-out their principles. JRSpriggs (talk) 20:22, 9 August 2026 (UTC)

That doesn't seem to be what happened here. As far as I can tell this professor wrote a very niche monograph as a labor of love, couldn't find (or couldn't be bothered to find) a well-established publisher, and instead went with the self-publishing site who would put it online as an open-access PDF. The publisher's stated fee is €25 per page, and it's not clear if there was ever a paper print run of the book. It's e.g. not on Amazon. –jacobolus (t) 20:29, 9 August 2026 (UTC)

The publisher's reputation is worth noting, but I think the author's expertise is the most important consideration. WP:EXPERTSPS allows self-published material from established experts when it concerns their area of expertise. So, given his background in mathematics, I would consider the book usable for attributing McCartin's mathematical claims within his area of expertise. Tioaeu8943 (talk) 00:20, 11 August 2026 (UTC)

Restoring WP:NOTTEXTBOOK as a visible shortcut

I am trying to restore the link WP:NOTTEXTBOOK as a listed shortcut in WP:What Wikipedia is not#Wikipedia is not a manual, guidebook, textbook, or scientific journal, as I think it's am important guideline that we often have to fight for when discussing things with some editors here. If you want to contribute your point of view, see Wikipedia_talk:What Wikipedia is not#WP:NOTTEXTBOOK. PatrickR2 (talk) 22:46, 7 August 2026 (UTC)

Unable to use math templates in citation titles

Since very recently I am unable to use {{math}} and {{mvar}} templates in the titles of {{cite journal}} etc without getting some sort of stripmarker error. Formatting mathematical formulas in titles using instead <math> works, but with this alternative formulas in linked titles stay black instead of turning blue with the rest of the title. Using plain html for formulas is just wrong (bad mathematical typesetting). The only workaround I have found is to format the entire citation manually. I've left more details at Help talk:Citation Style 1 § Stripmarkers in titles with template mathematics; advice there would be welcome. —David Eppstein (talk) 00:36, 10 August 2026 (UTC)

Talagrand's Convexity Conjecture (Solved)

This conjecture was proven and should have its own article, due to its importance in geometry. Kirby123456 (talk) 01:39, 11 August 2026 (UTC)

@Kirby123456:

Are you referring to the following article on arXiv?

Dongming Merrick Hua; Song, Antoine; Tudose, Stefan (2026). "On Talagrand's Convexity Conjecture". arXiv:2605.10908 [math.PR].

--SilverMatsu (talk) 06:17, 11 August 2026 (UTC)

That arXiv link seems to be the original paper, but there is reporting about the recent proof in secondary sources:

• Scientific American
• phys.org
• ENTECH Magazine
• DongA Science

I don't know how significant the theorem is, and have no opinion about whether it warrants a Wikipedia article. CodeTalker (talk) 16:49, 11 August 2026 (UTC)

Input requested at Talk:K-stability

A discussion is open at Talk:K-stability#2026 cscK YTD preprints about whether and how a 2026 arXiv preprint should be summarized in the cscK YTD subsection. Comments from uninvolved editors familiar with K-stability and Wikipedia's sourcing policies would be welcome. I am the author of the preprint and have disclosed this conflict of interest on the article talk page. ~2026-43164-95 (talk) 10:11, 21 August 2026 (UTC)

Can I use comments from "categories.org.au" as references for Wikipedia?

I'm looking for a reference regarding who first introduced the concept of a strict 2-category, and I find the following thread:Re: Who invented n-categories? Can I use this as a reference?--SilverMatsu (talk) 09:28, 23 August 2026 (UTC)

Discussion forums generally fall under WP:USERG and cannot be used. The only exception is when the specific person whose comment you want to use is a recognized expert under WP:SPS. In this case it's Andrée Ehresmann, and she's notable enough as a category theory expert that we have an article on her, so I think she does count as a recognized expert. —David Eppstein (talk) 16:35, 23 August 2026 (UTC)

Thank you for the detailed explanation. I added a link to Andrée Ehresmann in the cite template.--SilverMatsu (talk) 01:47, 24 August 2026 (UTC)

Should the LaTeX space in integrals be changed from '\,' to '\mathop{}\!' site-wide?

Among other various changes, User:Sbb has sometimes (I'm not sure how many pages were affected, I didn't investigate closely) changed all of the instances of \, to \mathop{}\! in integrals on some pages. For example, instead of writing \int e^x\,dx, that would instead be \int e^x\mathop{}\!dx. These two render identically:

$${\displaystyle \int e^{x}\,dx\qquad \int e^{x}\mathop {} \!dx}$$

After reverting one of these changes, I made what I thought to be a polite comment on their talk page asking them to not make the same change to other articles:

[...] using a 2 mu '\,' space before the 'dx' of an integral is the common standard in LaTeX documents used by most mathematical authors (and most Wikipedia pages; we e.g. recommend this in every integral example on Help:Displaying a formula), and we don't need to re-invent the wheel here and we shouldn't make changes across Wikipedia. Your version, '\mathop{}\!', is both significantly harder to read in the source and also renders literally identically, to the pixel. [...] Please don't do this type of replacement. It just adds spam to people's watchlists while also making the article marginally worse.

Sbb does not agree. They explain their reason for this change:

I ignored this for the longest time because it is simply wrong [...] [saying \, is a common standard approach is] categorically false [...] [\mathop{}\!] serves as a semantic identifier or singly identifiable place to eventually search/replace when WP eventually allows editors to extend LaTeX markup with new commands / macros [...]

In my opinion a hope for future macros and a site-wide find/replace is not a reasonable justification for making large-scale changes that add a ton of clutter to article markup, when the hoped-for eventual macro feature might someday give us the capability to.... render exactly the same thing but with a bespoke command name instead of an explicit thin space.

Even if such a macro feature did eventually appear, and there was a consensus decision to adopt a macro for writing the space in integrals, it would be quite trivial to make a bot identify all such spaces using some set of pretty simple heuristics, and with some human spot checks it wouldn't be hard to almost entirely automate the conversion of integral spaces to some desired future format. So the "semantic identifier" argument does not seem very convincing to me.

I believe drive-by changes of '\,' to '\mathop{}\!', especially if undertaken at scale, to be disruptive, and think they should be reverted per WP:STYLEVAR and to avoid pointless watchlist spam and edit warring. (But I have no personal problem if individual article authors want to write new integrals on arbitrary pages using this syntax. I'm generally happy to defer to article authors about such trivialities.)

I'm here for a third opinion, since I don't think I will convince Sbb by myself. –jacobolus (t) 21:27, 23 August 2026 (UTC)

To be clear (and I think jacobolus pejoratively misrepresented my edits as "drive by"), those edits are always a small part of my article-wide edits for maths improvement (such as changing from colon-indent to <math display="block">, applying {{math}}/{{mvar}} consistently if the inline maths are trivial, removing <math>...</math> from captions (per standard because of Phab bug), etc.).  — sbb (talk) 21:54, 23 August 2026 (UTC)

I'm here for a third opinion, since I don't think I will convince Sbb by myself.

The ending subordinate clause is an unnecessary aspersion. Please leave that commentary out, it is unfair, and completely ignores your misrepresenting of the context of your discussion with me.  — sbb (talk) 21:59, 23 August 2026 (UTC)

In many cases even putting a space is wrong if the integrand has an interpretation as a differential form. Being overly opinionated about this is definitely bike shedding. Tazerenix (talk) 22:21, 24 August 2026 (UTC)

By "drive-by changes" I intended to be descriptive, not insulting: someone popping in briefly to make small changes (including things like twiddle with the markup or style of a page) and then moving on to the next page, not making significant substantive content changes or sticking around to work on a particular article extensively. Sorry if I gave offense. I myself make tons of what I would consider "drive-by" edits all the time, and don't consider that category to be inherently bad. But I'm happy to use some alternative name for such edits if there's a better one. –jacobolus (t) 22:17, 23 August 2026 (UTC)

It is completely bogus to call \mathop{}\! semantic markup. It is obfuscation of what should be a thin space, pure and simple. There is no good reason for it. Standard advice from mathematical typesetting books is to use a thin space here, not an invisible operator with negative space . —David Eppstein (talk) 22:21, 23 August 2026 (UTC)

Yeah, I'd also agree that \,dx should not be changed to \mathop{}\!dx. –Deacon Vorbis (carbon • videos) 22:59, 23 August 2026 (UTC)

• "[saying \, is a common standard approach is] categorically false" → What? That's what everybody I know who types LaTeX does (except of course for those people who don't care at all about how their equations are typeset and don't even bother to include a space; and for the two or three people who have defined a custom command for the d that includes the spacing).
• " [\mathop{}\!] serves as a semantic identifier" → What? Semantically, this expression makes no sense whatsoever.

Malparti (talk) 23:15, 23 August 2026 (UTC)

I have read the discussion above and at User talk:Sbb#Please_do_not_replace_'\,'_spaces_with_'\mathop{}\!'_in_integrals, and I agree with the view of most editors here so far. \,dx is a good, ordinary, effective style, which is and should continue to be acceptable throughout Wikipedia. \mathop{}\!dx is overcomplicated and has no upside, and it should not be used. Adumbrativus (talk) 06:18, 24 August 2026 (UTC)

+1. —Kusma (talk) 06:43, 24 August 2026 (UTC)

Use of references as objects of a sentence

I believe I have seen this several times in math articles, and only in math articles. An example would be in Bayesian experimental design:

An example of Bayesian design for linear dynamical model identification are given in ^{[1] [2]}.

References

1. ↑ Bania, P. (2019), "Bayesian Input Design for Linear Dynamical Model Discrimination", Entropy, 21 (4): 351, Bibcode:2019Entrp..21..351B, doi:10.3390/e21040351, PMC 7514835, PMID 33267065
2. ↑ Bania, Piotr; Wojcik, Anna (7 October 2025). "An Approximate Bayesian Approach to Optimal Input Signal Design for System Identification". Entropy. 27 (10): 1041. arXiv:2511.04425. Bibcode:2025Entrp..27.1041B. doi:10.3390/e27101041.

This is a nonstandard usage relative to the rest of Wikipedia, and at first glance it looks like there is merely missing text before the footnotes, which is how I think the casual reader will read this. On a closer inspection, however, the intent appears to be to use the ^{[1] [2]} as the things to which the sentence refers. I'm open to suggestions for remediation of the issue. BD2412 T 21:24, 24 August 2026 (UTC) BD2412 T 21:24, 24 August 2026 (UTC)

I don't think there should be anything specific to mathematics about this bad usage. I would have guessed it to be left over from when we used to use parenthetical (harvard) referencing styles and then that style was deprecated and turned into footnotes without checking that the conversion made sense of the text. But in this case it appears that the actual footnote conversion was done sensibly (Special:Diff/1142652968) and that the removal of the object of the sentence was done as part of refspamming a second citation there (Special:Diff/1329951175). I have removed the offending sentence rather than fixing it, because it appears to be mainly refspam, not important for the paragraph it appears in, and sourced to a dubiously-reliable MDPI journal. —David Eppstein (talk) 21:45, 24 August 2026 (UTC)

It's good to know that this is not an accepted practice. I will fix this sort of thing where I see it in the future. BD2412 T 22:30, 24 August 2026 (UTC)

This is an example of bad writing: footnotes should not be used as a part of a sentence per se. But sometimes it does make sense to refer to a source explicitly, when it is relevant, e.g. in a history section discussing the most important papers about the topic. –jacobolus (t) 22:11, 24 August 2026 (UTC)