MediaWiki talk:Common.css

• MediaWiki
• Meta
• Commons
• Wikibooks
• Wikiquote
• Wikisource
• Wiktionary
• de
• fr
• pl
• ja
• jbo
• it
• nl
• es

Time to hide the inconsistent CSS space that appears after some namespaces in some cases?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Please see this discussion and T315893, which has been stalled at partial deployment for over three years. Now that the new discussion tools features have become the default, the inconsistent space that appears after only some namespaces, and not in all views, has become visible to all editors. It looks unprofessional and half-baked. I believe that we can easily disable this space, without prejudice to reintroducing it if the WMF developers complete the phab task to fully deploy it, by applying

.ext-discussiontools-visualenhancements-enabled .mw-page-title-separator::after {content: '';}

sitewide. – Jonesey95 (talk) 05:49, 15 July 2026 (UTC)

Support. There are a few questionable changes described in WP:VPT#Discussion Tools usability improvements becoming default, such as !important in CSS rules for h2 headings. The extra space in the page title seems like the easiest of these issues to work around locally, if work upstream has stalled for some reason. —⁠andrybak (talk) 10:19, 15 July 2026 (UTC)

By all means. The onus should be on those trying to introduce this change to demonstrate it's an improvement. The proposed edit merely reverts the unsolicited change imposed on us by devs. Nardog (talk) 14:48, 15 July 2026 (UTC)

Support – I'm amazed that there was so much well-reasoned pushback on that phabricator issue and this change somehow still made it through to production. –jacobolus (t) 16:18, 15 July 2026 (UTC)

Of all pages in prefixed namespaces at least 76% are talk namespaces, so the vast majority are currently seeing the space after the :.

Also, before this week's deployment, nearly 100,000 users had the feature already enabled via the beta feature too so many have been seeing it for years. I would also like us to prioritise finishing the work for the remaining 24% of pages, but I think reverting the fix would be disruptive. I appreciate too that some users here don't agree with the idea of the space, or think it will cause problems (although I think we have years of evidence now that it isn't the case), but I think instead it should be disabled on a per user basis, via user CSS or preference. ESanders (WMF) (talk) 16:24, 15 July 2026 (UTC)

Nope nope nope. Copying a modified version of my comment from the phab ticket:

• Wikipedia talk:Requests for comment (normal page view; spacing is present)
• Wikipedia_talk:Requests for comment (section edit view; spacing is present)
• Wikipedia_talk:Requests for comment (history view; spacing is not present, but there is a real space after the colon before "Revision history")
• Wikipedia_talk:Requests for comment (diff view; spacing is not present, but there is a real space before "Difference ...")
• Wikipedia_talk:Arbitration Committee (normal page view; spacing is present)
• Wikipedia_talk:Arbitration Committee page information (spacing is not present)
• Wikipedia_talk:Arbitration Committee What links here (spacing is not present)
• User:ClueBot (normal page view; spacing is NOT present)
• User:ClueBot/FalsePositives (normal page view; spacing is present, even though it is a subpage of the above page)

This is a mess. The developers have left it half-done at best, not 76% done. It's just like the Vector 2022 sticky toolbar appearing on some page views but not others: half-done and abandoned, requiring .css hacks to make it consistent (see T329673 and T350091). This is why I recommend turning off the space until the task is complete. – Jonesey95 (talk) 20:11, 15 July 2026 (UTC)

Off-topic: It's just like the Vector 2022 sticky toolbar appearing on some page views but not others: half-done and abandoned – ohhhh, so that's what it is. I recently got frustrated with some menus not doing what I expected and I couldn't pin it down because I wanted to move on with what I was doing at the time. Thank you for mentioning it. —⁠andrybak (talk) 09:07, 16 July 2026 (UTC)

It would be nice to also fix titles that mention other tiles (e.g. "Pages that link to 'X:Y'") , although in terms of page views it's an insignificant percentage compared to the 76% mentioned. ESanders (WMF) (talk) 09:17, 16 July 2026 (UTC)

This is the sort of thing that makes one go, why bother. It is incredibly difficult and arduous for volunteers to effect any change to how wikis work, but devs can skip all that process and then even push back on the pushback. Maybe the foundation should write content as well. Nardog (talk) 09:59, 16 July 2026 (UTC)

I think ESanders' point is that a few vocal volunteers aren't representative of the broader audience. It's also incredibly difficult and arduous for WMF devs to effect significant user-facing changes. When a change has come as far as this one with minimal pushback, it's a huge waste of time and effort to roll it back. What process do you think is skipped here? The feature has been under testing under beta and wiki config flag for years. – SD0001 (talk) 12:17, 16 July 2026 (UTC)

The missing part is where many editors took the trouble to log in to Phabricator and provide detailed feedback and links that explained the remaining work needed to be done to complete the (still open) task, and that information was not converted into development work to complete the task. – Jonesey95 (talk) 13:37, 16 July 2026 (UTC)

I definitely share your frustration. DiscussionTools has a backlog of hundreds of tasks, many of which would be meaningful improvements. The Editing team spent several years on the project but eventually we were reaching diminishing returns and had other projects we had to focus on.

That said I think there's an opportunity with T315893 (and thanks for your work documenting issues there) to make the experience more consistent. ESanders (WMF) (talk) 16:55, 16 July 2026 (UTC)

The discussion on the ticket largely stalled out on internationalization questions (ironically leaving it in a state that's less-correct for other languages than it could have been if we just went ahead with an interim thing from 2023). If you'd rather finish the feature here on English Wikipedia, where we can rely on English typographical conventions around colons, this is all you'd need:

.mw-page-title-separator::after {content: ' ';}

DLynch (WMF) (talk) 17:20, 15 July 2026 (UTC)

visible to all editors Only if you've not disabled Preferences → Editing → Show discussion activity. --Redrose64 🌹 (talk) 19:27, 15 July 2026 (UTC)

Nope. That doesn't fix the inconsistency with diff pages, history pages, what links here, page information, and other similar pages. The next step in this task, if the developers want to pick it up again, might be to make a list of all of the types of pages where a namespace-plus-colon-containing page title appears at the top of the page, then make the spacing appear in the title in all of those places. Multiple examples of such pages were provided in the phab ticket a long time ago, and there are more above. – Jonesey95 (talk) 20:24, 15 July 2026 (UTC)

Filed as T432324. Note also T26139, a similar existing issue. ESanders (WMF) (talk) 09:23, 16 July 2026 (UTC)

If consistency is what we're after, I'd prefer DLynch's suggestion instead which adds the space everywhere. – SD0001 (talk) 06:23, 16 July 2026 (UTC)

See my "Nope" above explaining that the proposed change is insufficient. – Jonesey95 (talk) 13:37, 16 July 2026 (UTC)

• Strong support for removing the space everywhere, for reasons I've mentioned on Phabricator many times. –Novem Linguae (talk) 06:26, 16 July 2026 (UTC)

  I suggest you go ahead and do it as an intadmin given the lack of clear oppose from any volunteer. It will be just restoring the status quo, which under any normal circumstance is the no-consensus default. Nardog (talk) 07:34, 16 July 2026 (UTC)

  Given the large number of users already using this feature before the deployment I don't think we can call it the status quo any more. ESanders (WMF) (talk) 09:10, 16 July 2026 (UTC)

  WP:FAIT. Nardog (talk) 09:41, 16 July 2026 (UTC)

  Nobody is "using" this feature (of CSS-based spaces after some namespace names in some page views of some pages). We were just putting up with it or working around it while testing the WMF's beta feature, expecting that development based on feedback would continue. We came to Phabricator to explain the next steps, and those steps were not implemented during a three-year period of testing and feedback. – Jonesey95 (talk) 13:37, 16 July 2026 (UTC)

  the large number of users already using this feature Are they using the feature primarily because they like spaces after the colons, or primarily because they want to know the time since last comment / how many comments / people in the discussion? --Redrose64 🌹 (talk) 20:48, 16 July 2026 (UTC)

  I don't think this discussion has died down yet, and I also feel strongly about this topic. In a couple days, maybe throw a {{IAER}} tag on this and get a neutral intadmin in here to evaluate consensus. –Novem Linguae (talk) 10:27, 16 July 2026 (UTC)

• We're proposing to add CSS that 99% of readers will never see anyway but will be loaded everywhere? Over some marginal inconsistency? All this sturm und drang? I would personally prefer to have no space and even for some of the non-looks reasoning already laid out, but really? Izno (talk) 15:29, 16 July 2026 (UTC)

  This. This entire thing seems like an upstream concern that doesn't need a hack pushed to readers. If someone wants to make an opt-in gadget for this, meh I guess. — xaosflux ^Talk 18:15, 22 July 2026 (UTC)

• comment i didn't even remember this was a part of this beta change. I realize several people feel strongly about this. I'm pretty sure I felt similarly at first. But i've changed my mind. I like it and to me, it's not as problematic or confusing as people make it out to be. I also don't think that the inconsistency argument holds much water here. We have inconsistencies in Wikipedia all over the place. In the software, in the gadgets, in infoboxes, in procedures etc. I don't think inconsistencies are as problematic as they are being made out to be. Should it be consolidated eventually ? I guess, but to me there's a lot of things that need to happen all the time. Won't object to removing the space, because like adding the space consistently.. removing it just on English Wikipedia is also not that important —TheDJ (talk • contribs) 15:44, 16 July 2026 (UTC)
• Support making this change (I thought about closing but then realized I had an opinion rather than being a neutral closer). I don't find "but what about the silent people" arguments raised along the lines of SD0001/ESanders (WMF)'s comments convincing; probably the vast majority of people encountering this either don't notice or notice it and think nothing of it, rather than implicitly supporting it. Nor do I find Izno/Xaosflux's technical concerns about adding CSS displayed everywhere meritorious either -- interface admins are servants of the community and need to be willing to assert the community's will when necessary and not refuse to do so on grounds of it being de minimis or a hack; community sovereignty is more important than these technical concerns. And it's quite telling how if you see past these smokescreen arguments there's no person speaking up here in favor of the change on its merits, only relied on one or another of the above arguments to avoid respecting what the community speaking up here appears to want. I don't care about the substance of this change myself since I don't have DiscussionTools turned off entirely due to a personal preference for a simplified interface that eschews most UI enhancements, but it's clear from reading the discussion above that proper process was not followed and it's now time for us to insist on that ... * Pppery * _{in solidarity} 01:46, 24 July 2026 (UTC)

  "The community's will" is currently 5 people. Who are opposed by half a dozen others. And no, we don't need to assert so, whether as interface admins or otherwise; this isn't a conflict that must be won or lost (WP:BATTLEGROUND doesn't stop applying outside of article space) and the interface admins on enwiki are all volunteers.

  As for the technical concerns, they do remain salient and relevant; yesterday I had a separate WMF employee looking at Common.css who identified multiple lines of interest that probably should not also be living here (but instead in gadgets).

  I find the "consistency" argument advanced almost completely mystifying in that there is no reason that non-readviews (editing, history, etc.) must have the offending styling. Consistency has never been the be-all end-all cross-page or cross-view. And so to me it is clearly all personal preference to every one of us involved in this discussion. If people want CSS like this (either to make the space go away or its opposite), they should support or make a gadget to get the behavior they really want (though I still personally disfavor doing anything, at least that way other issues become less relevant, like where stuff is loading [not mainspace]) and it can be turned off or turned on at relative will. I know several of the responders are able to and comfortable in dealing with what they perceive as an issue personally as well.

  (You seem to have missed that I don't even like the behavior of DiscussionTools either, so take my commentary here as an unusually conflicted responder.)

  Overall, the response seems to have been a question of "things are changing" and not anything more motivational. Izno (talk) 07:20, 24 July 2026 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Alignment of <math display=block>

We are about to see a major change in the mathematics render engine, switching the default rendering method to client side. Can we add

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

To the css at about line 216. The first part corrects alignment for the "Client side MathJax rendering for browsers with limited MathML support" mode, the second for "MathML (experimental; no images)" mode, and the last for "LaTeX source (for text browsers)", which might be used if someone decide the want to use the MathJax system via their Common.js. The MathML mode also need to have their font sizes increased to match the sizes in other modes.

I've added a test case using all styles of rendering at User:Salix alba/sandbox. Salix alba (talk): 22:46, 9 August 2026 (UTC)

If you wouldn't mind, can you make this same example page at mw: and then make a TemplateStyles sheet with any and all styles of interest? It will make it easier to verify what is necessary and what is not. Turns out that I can't use safemode to make the same verification since that apparently disables Mathjax. Which that shouldn't (since it's upstream and as such "safe") and so should be registered somewhere as a bug.

I think an additional change that should be made upstream if possible is to remove the need for the !importants. Izno (talk) 23:32, 9 August 2026 (UTC)

I've added a pbab task T434419 and two test cases, using the default styles there, and with the applied styles.

I've managed to remove a couple of the !important tags. --Salix alba (talk): 10:42, 10 August 2026 (UTC)

@Izno: this seems to have stalled, how can we move it forward? The current Common.css has

/* larger inline math */
span.mwe-math-mathml-inline {
	font-size: 118%;
}

/* Make <math display="block"> be left aligned with one space indent for 
 * compatibility with style conventions
 */
.mwe-math-fallback-image-display,
.mwe-math-mathml-display {
	margin-left: 1.6em !important;
	margin-top: 0.6em;
	margin-bottom: 0.6em;
}

.mwe-math-mathml-display math {
	display: inline;
}

which also has the !important override. --Salix alba (talk): 14:03, 5 September 2026 (UTC)

I was mostly waiting for phab:T434686 to resolve and then this got put by the wayside.

I've fiddled with the version on MW wiki to see what I think is the minimum CSS required to do (consistent) left alignment for all versions. I'm going to question a few things since people (you) are looking:

• The existing margins top and bottom on various display math. It doesn't look generally necessary. It could be included for some reason or another but it's not obvious.
• The inclusion of .mwe-math-mathml-display math {display: inline;}. It looks like you explained it in MediaWiki talk:Common.css/Archive 17#Math-tags formatting but removing it now appears not to cause any harm.
• In your version you set the flex to justify left. I don't see a reason for that?

And yes, I didn't expect the !important to go away entirely here since I was aware that it was in the Common.css version.

In general I think upstream needs some more CSS and as I said on the task it would be good to have a MW config option for block math to display left-aligned on a wiki such that we don't need to manage this all locally (and have CSS that applies everywhere when there are only some 10k pages using the math tag). Izno (talk) 21:50, 7 September 2026 (UTC)

Changing the font size for math to be different from the font size for text is a terrible idea. It makes our pages look like a ransom note. –jacobolus (t) 17:48, 9 September 2026 (UTC)

The font size change exists in the current version of Common.css. (I am as happy to review it as the rest.) Izno (talk) 18:36, 9 September 2026 (UTC)

When was that established, and by who, and what was the decisionmaking process? Did anyone talk to editors of technical articles about it?

(I might not have noticed because I use the MonoBook skin and have some additional custom CSS, e.g. setting my preferred font. For me, the math font is close to the same size as the text font. If I write e.g. ⁠$2x$⁠, 2x, 2x, 2x, all four are nearly the same size. Or maybe I'm misunderstanding and this CSS rule was set up as some workaround to make math and text fonts have comparable size.) –jacobolus (t) 18:48, 9 September 2026 (UTC)

December 2015. I assume the 118% was derived from the size established for .texhtml (I suppose it could have been handcrafted), which shows up first in October 2012. Despite the summary, that comes from Monobook where a size difference was instituted in October 2009.

Based on the continued amendment in that half-decade I would gather it was "one editor who decided the pokes were needed" but you are welcome to hunt yourself. Izno (talk) 19:06, 9 September 2026 (UTC)

Aha. I have a rule in my monobook.css:

span.texhtml { font-family: "Charter"; font-size: 100%; }

which I guess I added in 2024 (not sure that the font-family change is actually doing anything there). I hadn't remembered adding it. –jacobolus (t) 19:17, 9 September 2026 (UTC)

The comment on that Decamber 2015 change has edit summary "Match MathML (Firefox) fontsize with running text", so it looks like it's intended to be a workaround to make the text sizes be closer to the same, rather than an effort to make them differ. –jacobolus (t) 19:19, 9 September 2026 (UTC)

In theory, in future (once support is achieved in Grade A browsers), the font-size-adjust property could be used to adjust the size of the math font to better match, say, the ex-height of the text font. In practice, the effectiveness will depend on the accuracy of the embedded font metrics, and as the font for the prose text font isn't known by us (it'll be whatever is configured in the user's browser as the sans serif font), I don't think it's possible to adjust just the math font—both the text font and the math font would have to be adjusted in order to have the two match. Thus unless the adjustment just happens to match the sans serif font's value, the font size would be altered from the configured default. isaacl (talk) 19:44, 9 September 2026 (UTC)

It doesn't need to be entirely perfect, and we don't need to get fancy trying to match every possible reader font, but we should aim for rough size parity. (If one has an average letter size which is 5% larger than the other that's fine, but one should not be 20% larger than the other.) –jacobolus (t) 20:30, 9 September 2026 (UTC)

Sure. My intent was to discuss a property that is there to deal with the problem of matching font metrics across different fonts and why it doesn't seem like a good fit when needing to accommodate a browser/user configured font, as it won't respect the browser/user configured size. The current approach of just using an arbitrary size adjustment on the font used for math formulae is an OK approach, if we assume that the vast majority of readers never change their browser defaults, and so we can look at a small set of base text font and size settings. isaacl (talk) 22:11, 9 September 2026 (UTC)

Okay, I might have misunderstood what the effect/intent of the CSS font size adjustments was.

As a first priority here, we should try to make text sizes match between the "server-side SVG" and "client-side SVG" renderers, so that if this change of math mode is deployed, it makes as little visual change as possible. Whatever CSS changes are made should be checked against the previous rendering in the "server-side SVG" mode to make sure the appearance stays about the same. We should have $\textstyle x^{2}+y^{2}=z^{2}$ be the same size as , and we should have all of these four look the same:

$$\int _{0}^{\pi }\sin {x}\,dx$$

$\int _{0}^{\pi }\sin {x}\,dx$

Each pair of examples above should also have the same vertical margins/padding relative to surrounding text (including both explicit CSS and whatever space is added to the SVG itself). Also when there is a combination of text and a block math included in the same paragraph, or other element, e.g. bullet list item:

• Example list item with "server-side SVG" mode block, $$\int _{0}^{\pi }\sin {x}\,dx$$ and some text after
• Example list item with "client-side SVG" mode block, and some text after

The above pair of examples should appear identical before this math mode change can be deployed.

If we want a visual change, that can be discussed later at leisure, as a separate topic from the rendering mode change. If there is currently a difference in font size between text size and math size, in the longer term I would urge trying to make them close to the same, to avoid distraction. Ideally regular text, {{math}} and {{mvar}} templates, <math> tags, and fixed-width fonts (e.g. made by {{code}} or <syntaxhighlight>) should have roughly the same size, so that mixing them is not distracting. –jacobolus (t) 19:30, 9 September 2026 (UTC)

Indentation was the way this section was started. Current adjustments for locally displaying block math left are being poked at mw:Extension:Math/T434419/left-align but the other suggestions discussed here can be poked as well.

whatever space is added to the SVG itself I am not certain we have control over this aspect. The SVGs however have not included particularly significant whitespace from what I can see.

Each pair of examples above should also have the same vertical margins/padding relative to surrounding text That said, this was the question I posed at The existing margins top and bottom on various display math. It doesn't look generally necessary. It could be included for some reason or another but it's not obvious above. As you can see at /left-align the various display modes are inconsistent between each other. This is controllable, but I am not sure it is worth making everything consistent with each other since only one version will display at any given time for the 99.99999% of readers (including the math ones who like things to be pretty).

But if the different display modes must be consistent, I am slightly partial to minimizing the top margin/padding at least since I would expect block math to want to live closer to its predecessor than its successor (well, I would like to minimize how much CSS we send down the tubes so my current best state is no customization but I also don't feel particularly strongly here either since the margins are old also). The current top and bottom margins were installed in September 2015 an edit after the blocks were set to align left.

I have some ideals though:

1. Top/bottom spacing eventually ends up in the core math service CSS, not local to English Wikipedia.
2. The left aligned math also eventually ends up in the core math service CSS, not local to English Wikipedia. This would likely require some sort of config option for wikis to enable which English Wikipedia would.
3. Would be nice to see the inline font sizing upstreamed as well.

Some of this (all of these three?) is in phab:T434419 but I think it might be desirable to make the one task somewhat more separated so that each can be considered individually. Izno (talk) 22:29, 9 September 2026 (UTC)

"I am not certain we have control over this aspect." – What I mean is, the whitespace added by CSS doesn't have to be the same if it's compensating for a difference in whitespace around the SVGs, but we should try to make the end result visually the same to the extent possible. (And if we decide there should be a change in visual result, that can be discussed separately later.)

"But if the different display modes must be consistent," – I think it's significantly simpler to aim for consistency with the current behavior than to try to figure out what would be optimal. If we decide later that there should be a visual change it can be discussed separately with no particular urgency. Ideally all of these decisions should be made with more editor feedback than they have in the past, e.g. with a few possibilities presented to Wikipedians for discussion instead of having a couple of CSS experts or mediawiki developers make decisions based on their own preferences.

"The left aligned math also eventually ends up in the core math service CSS," – This upstream behavior change makes no sense to me to include as part of this rendering mode change. Mediawiki's math plugins should preserve the prior behavior, with at most an opt-in change other wikis can adopt if they prefer centered equations. Wikipedia shouldn't have to do a cumbersome workaround to achieve the same result we had before. –jacobolus (t) 22:51, 9 September 2026 (UTC)

This upstream behavior change makes no sense to me to include as part of this rendering mode change. Mediawiki's math plugins should preserve the prior behavior, with at most an opt-in change other wikis can adopt if they prefer centered equations. Wikipedia shouldn't have to do a cumbersome workaround to achieve the same result we had before.

The default upstream for display math is centered. Perhaps you didn't know that. We override that locally with the CSS that already exists here. The "new" display modes simply don't have the same local override - and apparently that override needs massage locally, else this discussion wouldn't be open.

The ideal for me is that both left and centered should be something sorted as part of the extension rather than locally and then wikis should decide which they want as part of their wiki's configuration. This has the bonus of reducing CSS load generally on those pages which do not use math. (Which is all 60 million less about 80k; 40k relative to the mainspace 7.2 million.)

Separately, I am not particularly attempting to sync any efforts here with efforts made to the extension, and changes can be made locally without agreement on Phab or elsewhere. I am bringing up the above questions now since people care about it now and not because I feel particularly concerned that we need to get it done on some timeline or another. There is no urgency now either way besides agreement on the best way to align the math that needs it left rather than centered (@Salix alba should get around to looking at my questions above, perhaps they did not see my response).

instead of having a couple of CSS experts or mediawiki developers make decisions based on their own preferences

This is a flawed understanding of how Math extension development generally works. Almost the entirety of the effort upstream has been by volunteers passionate about math (well, chemistry also). In fact, I would rather say that there is a dearth of either CSS or MediaWiki developers else a few of the tasks that have been my own annoyance would have been fixed. Izno (talk) 23:37, 9 September 2026 (UTC)

"The default upstream for display math is centered." – has that always been the case?

"There is no urgency now either way" – The urgency is that mediawiki developers / WMF keep threatening (in their phab tickets) to deploy the new math rendering mode within the next week, whether or not it's ready, and whether or not it has any community support. Thankfully up until now the "next week" keeps slipping one week at a time, but the imminent threat continues to hang over everyone's head, and they won't back off from having a completely unworkable stated schedule.

"volunteers passionate about math" – Any passion for math or mathematical typography isn't really showing through in their communication with Wikipedians. –jacobolus (t) 23:45, 9 September 2026 (UTC)

has that always been the case? Yes. It is the reason math editors here (incorrectly) used :<math> rather than the more appropriate <math display=block>. Someone eventually came along, added support for display math, and then pointed out that we could locally make it align left rather than center.

Any passion for math or mathematical typography isn't really showing through in their communication with Wikipedians. You're currently dealing with a MediaWiki dev. Who is employed by the WMF. And who has requirements attached to their need to deploy which are not "make math beautiful". Ultimately, you just have to deal with it. Math may look less good in some interim but I expect the others who work on the math extension will be (as they have been) accommodating for better display. Izno (talk) 23:52, 9 September 2026 (UTC)

"It is the reason math editors here (incorrectly) used :<math>" – This seems revisionist. My recollection is that in the earliest math rendering from ~2003, i.e. the ones rendering PNG images, there was no such thing as "block" math per se, and Wikipedians developed a convention of using :<math> as a reasonable and effective method of indenting, to solve a practical problem. This is "incorrect" from the perspective of HTML purists, in the sense that it creates a definition list, which isn't really intended for indentation, but, as with the use of colons for threading Wikipedia talk pages, this was an emergent Wikipedian-generated solution to a practical problem, a way of cobbling together a valuable feature not properly considered by the Mediawiki software. If we get down to it, the whole approach of making "math" a pseudo-html tag, and later the extension of that to add "display=block", kind of sucks from an author-centric language-design perspective; it's ugly and awkward syntax that would never be proposed if someone were designing a markup language from scratch. But stuff duct taped together is par for the course in mediawiki-land. Wikipedians make the most of tools that have very poorly designed features baked in to their fundamental design. .... Anyway, back to the point: so <math display=block> has always been centered in Mediawiki? I didn't realize that. That also seems like a poor basic choice considering Wikipedia is by far Mediawiki's most important "customer", and needs to left-align formulas for backwards compatibility if nothing else, but I guess with that history it makes more sense why the math alignment could be now breaking, if the fix for left alignment was always based on a Wikipedia-specific workaround. –jacobolus (t) 01:18, 10 September 2026 (UTC)

Probably what I should have said is that it's the reason the practice continued largely unchallenged until 2015 or thereabouts. Izno (talk) 01:23, 10 September 2026 (UTC)

I personally think there is urgency. When we hit phase 6 of the rollout in T271001, currently scheduled for the 17 Sept, all non logged in users will see their maths rendering suddenly change from the local convention that has been in-place since the foundation of the Wikipedia, although implemented in different ways. When the eventual sunsetting happens this change affects all uses. Logged in or not. At that point you will be able to remove 10 lines of CSS.

The changes here are designed to make the rollout as seamless as possible.

The CSS can be simplified as in most places the same rules is applied to different CSS selectors. If size is an issue then the last clause affecting span.mwe-math-fallback-source-display can be dropped. This only impacts users who want a custom rendering solution. I'm not sure there are any such users, and they can use their own custom.css for that.

For compatibility with this rollout, its only the mjx-container[display] rules that matter. The other rules affect the native MathML generation which is a long term goal, but years away. It does make sense to get all the CSS sorted at the same time. Minimising the visual differences between modes seems good, and helps with bug checking when users are comparing rendering between modes.

I quite get the anger of some other users. The Wiki Media Foundation, has long sidelined the mathematical and scientific community. All the development of the maths engine has been done by a single German volunteer. Until recently, it was hard to even get someone do a code review. Its only now, when the WMF want to deprecate part of the tech stack that we are seeing any resources developed to the maths rendering engine. For many the changes are something done to them with very little control. It would be a shame to see that attitude reflected here. --Salix alba (talk): 05:41, 10 September 2026 (UTC)

@Salix alba, you might have missed the discrete questions I asked at MediaWiki talk:Common.css#c-Izno-20260907215000-Salix alba-20260905140300. I suppose I can interpret Minimising the visual differences between modes seems good to mean something about the top and bottom margins but it would be better to be clear. Izno (talk) 18:36, 10 September 2026 (UTC)

Sorry if I derailed any of the discussion.

The existing margins top and bottom on various display math. It doesn't look generally necessary.

I don't think the top/bottom margins we had previously for <math display=block> were necessarily great. I don't know how those were actually chosen before, and don't remember precisely what they are.

Because I didn't like the defaults, in 2023 I added to my personal global.css: .mwe-math-fallback-image-display, .mwe-math-mathml-display { margin-top: .2em; margin-bottom: .2em; }

We could plausibly change the defaults to something different than the current ones, but that should probably be discussed with Wikipedians. I think the easiest immediate goal is to make the "client-side SVG" and "server-side SVG" rendering modes as close to the same appearance as possible. –jacobolus (t) 19:09, 10 September 2026 (UTC)

I've now started a discussion at Wikipedia:Village pump (proposals)#Placement of display math and chem formula, so we can gauge consensus on how we would like display equations to be treated. --Salix alba (talk): 00:13, 11 September 2026 (UTC)

I don't see why you did that? There is agreement that it needs to be left aligned. The other questions you asked there are not sufficiently specific. Izno (talk) 00:15, 11 September 2026 (UTC)

So can we get this bit

mjx-container[display] {  
	margin-left: 1.6em !important;
	text-align: left !important;
}

added here? That is the most pressing change.

Do you have a modified version of the CSS for the math.mwe-math-element-block selector?

For the use of display:flex, I did try some alternatives, but they all broke. I've a slight preference for flex, as it is more modern css with better control. Happy to go with an alternative.

For top and bottom margins, they don't seem necessary for mjx-container, and I've just used the same rules as for the existing .mwe-math-mathml-display selector.

Happy to drop the span.mwe-math-fallback-source-display rule completely, just a nice to have. --Salix alba (talk): 00:45, 11 September 2026 (UTC)

I said above that I had modified the TemplateStyles sheet over at MWW to indicate what I think is the minimum set, ignoring top/bottom margins. Did you look at that?

The question I was asking was not whether we should have display flex (I have no issue with it) but that we need a non-default justify-content. My testing there did not indicate it as necessary. I used the page you set up to test the various display modes for me, but I did it in Firefox on Linux so I wonder if you added it because you were seeing bad behavior in other browsers. Izno (talk) 01:00, 11 September 2026 (UTC)

The indentation looks fine at https://www.mediawiki.org/wiki/Extension:Math/T434419/left-align. However, if I use that CSS in my User:Salix alba/common.css, set my math rendering preference to client-side svg, and view examples in User:Salix alba/sandbox, then display equations are center-aligned. --Salix alba (talk): 05:14, 11 September 2026 (UTC)

mw:Extension:Math/T434419/left-align has something going very wonky with the font size in <math> tags that don't set display=block. Was something recently changed in the CSS, or has the mediawiki wiki always had wacky font sizes for math?

Concretely, these two should look about the same:

${\tfrac {1}{2}}e^{i}$

$${\tfrac {1}{2}}e^{i}$$

If they have different font sizes, there's something wrong. –jacobolus (t) 05:28, 11 September 2026 (UTC)

I want to say I have always noticed a rendering difference between block and inline. But I've also been using the Mathml implementation since it was first released a decade ago. So it could be something upstream causing it. Izno (talk) 06:24, 11 September 2026 (UTC)

been using the Mathml implementation

I'd highly recommend against this if you want mathematical expressions on Wikipedia to appear as their authors intended; the MathML mode is quite buggy, and tends to make math-heavy pages much uglier than they should be. –jacobolus (t) 07:04, 11 September 2026 (UTC)

I have never had a particularly strong issue with its presentation. I suspect you might find that you are one of very few people who think math must be presented a certain way to be consumable. Izno (talk) 07:19, 11 September 2026 (UTC)

@Salix alba Your rule there

/* larger inline math */
.mwe-math-element-inline,
.mwe-math-mathml-inline {
	font-size: 118%;
}

definitely does not match current English Wikipedia behavior. If I open up Wikipedia as a non-logged-in reader to get the default experience, both inline and block math elements have the relevant HTML elements set to font-size: 16 px. But on your linked page with this "larger inline math" rule, the block element is still as expected but the inline element has been bumped dramatically in size, and it looks really bad. We should definitely not adopt that rule here. –jacobolus (t) 07:16, 11 September 2026 (UTC)

I think it's a specificity issue. I will test at MW wiki. Izno (talk) 06:08, 11 September 2026 (UTC)

Yeah, the JS loads after modifications made in site and user CSS. The styles in site/user CSS have the same specificity, so the JS wins. TemplateStyles obscures this fact because it always carries the extra .mw-parser-output class. I've added a class to the specificity to win. We could use another class like .mw-parser-output (prepended) in case we are concerned that the .MathJax class (or any other selector on that element) could change. Izno (talk) 06:18, 11 September 2026 (UTC)

Yes mjx-container[display].MathJax works for me here. --Salix alba (talk): 05:57, 12 September 2026 (UTC)

On the top/bottom margins, display equations are supposed to standout at bit, so I think there should be some top and bottom spacing. We are getting different results for the reference Server-side SVG mode here and at MediaWiki. Here the current common.css has the rule

.mwe-math-fallback-image-display,
.mwe-math-mathml-display {
	margin-left: 1.6em !important;
	margin-top: 0.6em;
	margin-bottom: 0.6em;
}

which is not present at MediaWiki, so its rendered there with no margins. For the client side svg mode, it looks like the extension provides the rule

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

although I can't seem to find this in the code. This might be something to handle upstream, as the vertical spacing of all three mode should match. --Salix alba (talk): 10:29, 12 September 2026 (UTC)

I've implemented some variant of this per discussion. Izno (talk) 20:30, 13 September 2026 (UTC)

@Izno You broke the size of inline equations from "server-side SVG" mode. Can you immediately revert the size change? If we want to make a change it should be deliberate, after discussion.

These two have always looked the same, and must continue to do so, unless there is editor consensus otherwise:

$\int _{0}^{\pi }\sin {x}\,dx$

$$\int _{0}^{\pi }\sin {x}\,dx$$

–jacobolus (t) 20:39, 13 September 2026 (UTC)

Should resolve itself Soon. I've removed the added line. Izno (talk) 20:54, 13 September 2026 (UTC)

Thanks! –jacobolus (t) 21:10, 13 September 2026 (UTC)

As an aside, the documentation for the {{math}} template explains the size adjustment:

The font and fontsize used for texhtml was determined by comparing common default fonts found on Windows, macOS and Linux and is scaled to 118% to match their x-height. However, not everyone uses the default fonts. If you find that the rendered math is not of the same size as the surrounding text, you can adjust this in your personal CSS. For instance, the DejaVu Sans and DejaVu Serif fonts do not need scaling, in which case .mw-parser-output span.texhtml { font-size: 100%; } will restore proper display.

So this shouldn't apply to client-side SVG mode, and whether it should apply to the native MathML mode depends on which font(s) are expected to be used, but in any case any size adjustment(s) should be applied uniformly to both "block" and "inline" math. The goal was to get the math font to be about the same size as the text font, not to make inline math extra large. (ping @Salix alba) –jacobolus (t) 20:52, 14 September 2026 (UTC)

Common.css/js is now actually common

The WMF (Jon (WMF)) has now flipped the config switch that makes Common.css (and Common.js) actually common, between both desktop and mobile platforms. (It also starts loading MediaWiki:Print.css.)

It comes with the benefit (or cost, depending on who's asking) of also being render-blocking on the mobile platform, which means potentially increased times for someone to go from clicking a link to reading our pages. So it's important that we be sensitive to the addition of new CSS. (This was true before but becomes truer now that this sheet is also loaded for the other 2/3rds of readers.)

On the happy side, I've already removed the duplication that was in MediaWiki:Minerva.css. I know there are other pages that employ withJS (and some with withCSS) that could also benefit from some sprucing as a result. Izno (talk) 22:44, 11 August 2026 (UTC)

Nice, this means withJS-powerd wizards like WP:SUBMIT will finally work on mobile. – SD0001 (talk) 14:14, 26 August 2026 (UTC)

I did a run through of what I could find around the time the switch flipped just working from a search of withJS. I might have missed some things. Izno (talk) 14:42, 26 August 2026 (UTC)

cn important

@TheDJ: looks like we've been carrying this !important hack for almost 10 years. Any idea if it is still needed, or being worked on elsewhere? — xaosflux ^Talk 13:30, 26 August 2026 (UTC)

No idea, but i'd be open to just removing it and seeing who complains. :) —TheDJ (talk • contribs) 14:04, 26 August 2026 (UTC)

The good old "scream test" :) –Novem Linguae (talk) 09:12, 29 August 2026 (UTC)

We should test to see if that class is emitted in the standard centralnotice. I've dismissed all mine. :^) Izno (talk) 14:53, 26 August 2026 (UTC)

Ok, it seems to be a class sometimes added in the notice as-generated onwiki e.g. meta:CentralNotice/Request/WikiEducation college towns 2025/calpoly banner. See To preserve what it intends, I think it is necessary. Izno (talk) 15:02, 26 August 2026 (UTC)

Now, we can also have a discussion about whether what it intends is necessary at all. :^) Izno (talk) 16:08, 29 August 2026 (UTC)

Line breaks between paragraphs missing on noticeboards

To fix phab:T436428, thoughts on changing...

.ns-talk .mw-body-content dd {
	margin-top: 0.4em;
	margin-bottom: 0.4em;
}

... to ...

.ext-discussiontools-replytool-enabled .mw-body-content dd,
.ns-talk .mw-body-content dd {
	margin-top: 0.4em;
	margin-bottom: 0.4em;
}

? –Novem Linguae (talk) 09:10, 29 August 2026 (UTC)

I've added this. Izno (talk) 16:07, 29 August 2026 (UTC)

Thanks! –Novem Linguae (talk) 23:11, 29 August 2026 (UTC)

I was wondering why I didn't see any change and then realized from the class name it seems to require that the reply tool is enabled. Can anyone suggest another class or approach that might be more general?

In my style sheet for discussion threads, User:Isaacl/style/discussion-threads.css, I use dl:has(> dd span[data-mw-comment-start] to detect discussion threads, so I think having this as part of the selector could work with newer browsers. It would not, though, meet mw:Compatibility § Grade A, as Firefox only implemented support in December 2023, and the other major browsers only in 2022. isaacl (talk) 02:03, 5 September 2026 (UTC)

The following works for me with a quick test:

.mw-body-content dl:has(> dd span[data-mw-comment-start]) dd {
	margin-top: 0.4em;
	margin-bottom: 0.4em;
}

isaacl (talk) 23:39, 5 September 2026 (UTC)

:has() remains too new for Common.css unless we accept a difference in renders (it doesn't even meet grade C). Izno (talk) 02:18, 6 September 2026 (UTC)

Well, the Grade C browsers are older than Grade A, so that follows. It's a progressive enhancement, so arguably it's not the end of the world for there to be a difference. I also see that :is() appears in Common.css, and that's not supported by the Grade A Safari browsers. That being said, I appreciate the argument for not using it. Does anyone have another idea? isaacl (talk) 02:36, 6 September 2026 (UTC)

Well, if we were willing to apply the margin to *any* situation with consecutive <dd>s without a <dt>, not just where discussion is involved, this would work:

.mw-body-content dd:first-child,
.mw-body-content :not(dt):first-child ~ dd {
	margin-top: 0.4em;
	margin-bottom: 0.4em;
}

However, I appreciate that this may have unexpected effects on other pages using similar invalid definition-list syntax, where the lack of top/bottom margin may be implicitly relied upon... But I figured I'd share the option nonetheless. :) Mr. Starfleet Command (talk) 02:51, 6 September 2026 (UTC)

We are not so willing. ;) Izno (talk) 02:53, 6 September 2026 (UTC)

:is() appears only in the context of CSS intended to reach Javascript browsers, most or all of which will pass. Izno (talk) 02:52, 6 September 2026 (UTC)

I have no issue with using :is(). But I don't think just because the browser needs to support Javascript means that it will support the :is() selector. (Safari only supported it in 2020; I'm guessing the Javascript in question for collapsing content predates it.) isaacl (talk) 04:21, 6 September 2026 (UTC)

The JS in question for collapsing does predate 2020 but the set of browsers (and more specifically the overall traffic of browsers) we send Javascript to but which don't support :is() is actually very small, due to the compatibility testing we do in startup. Izno (talk) 05:25, 6 September 2026 (UTC)

And, the CSS of interest is indeed also a graceful degradation in this case either way; all it does is remove some jitter on pages with a few rarely-used classes (that honestly we might entertain removing support for anyway...). Izno (talk) 05:28, 6 September 2026 (UTC)

If a browser supports :has() it should also support :is(); similarly, if a browser does not support :has() it should also not support :is(). This is because both of these pseudo-classes will be introduced with Selectors Level 4, presently a W3C Working Draft. --Redrose64 🌹 (talk) 08:15, 6 September 2026 (UTC)

Data from https://caniuse.com/css-has versus https://caniuse.com/css-matches-pseudo disproves the latter part, almost all listed browsers have released versions (often many versions) supporting :is() without :has(). Anomie⚔ 12:04, 6 September 2026 (UTC)

Can "math" templates be made to always suppress line breaks?

In special:diff/1244377287 in September 2024 the suppression of line-breaks from within {{math}} templates was moved. Originally it was set up as

span.texhtml {
    [...] white-space: nowrap; [...]
}

But this line of the CSS was moved, and today it reads

@media (min-width: 640px) {
	span.texhtml {
		white-space: nowrap;
	}
}

I don't know why this change was made, but can it please be reverted? The edit summary links to MediaWiki talk:Common.css/Archive 19 § h-Turning Mobile CSS/JS off permanently and supporting Common CSS/JS on mobile-20240906182100 as a justification, but I don't see anything relevant there.

There is a newbie editor trying to wrap {{math}} templates with {{nowrap}} templates because undesirable line breaks are appearing in his browser.

I reverted his changes since {{math}} is supposed to suppress line breaks inside, but it sounds like he's encountering a real bug, caused by this 2024 CSS change.

Ping @Izno.

–jacobolus (t) 01:56, 15 September 2026 (UTC)

The editor there should be told not to do that. I don't intend to change what's presently in Common.css on the point.

The current CSS is a deliberate decision. The alternative to "texhtml wraps on low resolutions" is "people have a very wide screen because the thing in texhtml would otherwise go off the right edge and so the screen stretches thereby making all text hard to read, on low resolutions", or "people can't access the entirety of the formula because texhtml goes off the right edge, on low resolutions". Both of which are a far worse experience for mobile users than the math wrapping. Izno (talk) 04:13, 15 September 2026 (UTC)

What discussion was your change based on?

Your CSS change breaks the explicit contract that {{math}} template are organized around, and breaks the correct rendering of math templates on any screen narrower than 640 px. Line breaks end up getting added in many places where they are entirely inappropriate.

Math templates should not ever be used for math expressions that are wider than a few words of text would be. They should be used for a few variables, or maybe a short equation. Anything wider (say, some steps of algebraic simplification with several = signs in a row, or a complicated equation with many sub-components) should either (a) use two or more {{math}} templates with an explicit place allowing line breaks in between – this is beneficial on screens of all widths – or (b) should be moved to an indented "block" on a separate line, and possibly written as LaTeX. Mathematical typography has very precise rules about where line breaks can be added in the middle of long expressions. Just adding a line break willy nilly at whatever point happens to fill up the current line of text is never correct.

In my opinion your "fix" here is much worse than any problem caused by not having it. "I don't intend to change" – then there should be a proper discussion with a bigger group of editors familiar with the use of math templates on Wikipedia; there is almost certainly a consensus opposed to your decision here. –jacobolus (t) 05:40, 15 September 2026 (UTC)

should either (a) use two or more math templates with an explicit place allowing line breaks in between – this is beneficial on screens of all widths I can identify at least one counterexample to your world: Elo rating system#Theory is a place which nowraps drastically on my device; testing at 325px causes the final digits in the quotation to fall off the screen, totally inaccessible without changing display mode (though the issue is exhibited all the way to 380px, and even then the browser takes the opportunity to force the punctuation to wrap on many instances of {{math}} on that page for another dozen or two worth of pixels). And I do not see a way to fix that while maintaining CSS which forces a nowrap.

I was able to find this example with this search. There may be others of greater issue elsewhere; Special:Search accepts the wildcard character with count of characters limiters up to 35. One is the misuses I removed in this edit today. (There is someone who really likes Greek letters in the texhtml font selections, I do not know why. I believe there are other such instances out and about but haven't looked for them in citation templates before....)

We can feasibly entertain a different threshold than 640px, but I don't think moving that number to anything less than 400-420px is appropriate. 480px may even be a conservative value. Izno (talk) 06:56, 15 September 2026 (UTC)

Elo rating system has a lot of problems with its mathematical expressions, throughout. It has ugly large fractions used inline in text, LaTeX and plain text in mixed expressions, a random mishmash of <math> tags and {{math}} templates, unusual use of sans serif symbols, and a lot of somewhat unencyclopedic writing/tone.

But by "the quotation" I take it you mean the part introduced by "An example may help to clarify"? With contents including the {{math}} templates (0 + 0.5 + 1 + 1 + 0) = 2.5, (0.51 + 0.69 + 0.79 + 0.54 + 0.35) = 2.88, and [1613 + 32 × (3 − 2.88)] = 1617? I would consider moving these long expressions to their own separate lines. (And the outer parentheses should be removed.) If they are going to stay inline, I would consider marking them up along the lines of first 0 + 0.5 + 1 + 1 + 0 = 2.5, second 0.51 + 0.69 + 0.79 + 0.54 + 0.35 = 2.88 and third 1613 + 32 × (2.5 − 2.88) = 1601, so that line breaks are allowed at appropriate places.

With the current markup, even on wide screens these sometimes look bad because no line break is allowed so there can be a very wide empty space at the end of the previous line.

But with your CSS that allows wrapping anywhere, these long sums keep getting broken before + signs and in the middle of tight parenthetical expressions; this is against the rules of mathematical typography, which demand that a line break should always come after an operation or relation symbol. For example, I can up getting line breaks like:

Lorem ipsum dolor [1613 + 32 × (3
− 2.88)] = 1617 sit amet, or

Lorem ipsum dolor [1613 + 32
× (3 − 2.88)] = 1617 sit amet,

which makes the expression quite hard to read.

The example that the person was trying to add {{nowrap}} tags to earlier today was ∠ ABC, which kept line breaking in their browser after the angle sign, like∠
ABC, which is a big problem. –jacobolus (t) 07:23, 15 September 2026 (UTC)

Yes, I agree that expression is hard to read like that, but below a certain resolution (the numbers above) the alternative is that you can read only half the expression at all and not the whole thing (and that's worse).

As I said, I'm willing to move the threshold down, but not remove it entirely. 420 appears to work for the longest findable expression as below. I'd prefer something a bit further north because I know there will be longer out there by people who aren't you or other math editors with sensible opinions. 420px would improve the display on a 220px regime from today. Izno (talk) 07:32, 15 September 2026 (UTC)

Is there a way to set a CSS rule based on the width of the content of the element? Maybe you can set it to always suppress line breaks on anything where the content is less than, say, 150 pixels wide. –jacobolus (t) 07:35, 15 September 2026 (UTC)

No, not really. The closest thing is CSS container queries but these are far away from use on Wikipedia for several reasons. Even for those I think the answer is no, it wouldn't work for this use case.

Broadly, CSS does not like doing things based on the size computed of some inner content. Standards and web developers have a bad memory of how tables work, and where such things have been tried they have apparently caused issues with browser performance. Size and layout is, in other words, generally computed top-down in the DOM. (Javascript would just count the characters but that is not a good option for this kind of use.) Izno (talk) 07:45, 15 September 2026 (UTC)

The particular threshhold is not the issue. Anywhere that line breaks would be appropriate for narrow displays they should be allowed for all displays, but in many places line breaks should be suppressed irrespective of the display width. Having a template that suppresses line breaks only for some widths of display is really bad, in my opinion. The results are basically bad for everyone. –jacobolus (t) 08:06, 15 September 2026 (UTC)

Another several at Softmax function#Example: (0.024, 0.064, 0.175, 0.475, 0.024, 0.064, 0.175) is 50 characters (I also note poor behavior at Softmax_function#Gradients of inline <math> which also runs off the screen). That is an issue up to about 420px (if we want to catch the full stop also). Izno (talk) 07:05, 15 September 2026 (UTC)

The "Softmax example" is one where we don't really want to suppress wrapping at all (in any size screen); line breaks should be allowed after any of the commas. Arguably the {{math}} template is a bad tool for this. Maybe we should have a template which sets a serif font but doesn't do anything with wrapping.

In the gradients section, I'd recommend putting the elaboration at the end of the very wide math block inline with the following text, changing

$${\frac {\partial }{\partial z_{i}}}\operatorname {LSE} (\mathbf {z} )={\frac {\exp z_{i}}{\sum _{k=1}^{K}\exp z_{k}}}=\sigma (\mathbf {z} )_{i},\quad {\text{ for }}i=1,\dotsc ,K,\quad \mathbf {z} =(z_{1},\,\dotsc ,\,z_{K})\in \mathbb {R} ^{K}.$$

to something like:

$${\frac {\partial }{\partial z_{i}}}\operatorname {LSE} (\mathbf {z} )={\frac {\exp z_{i}}{\sum _{k=1}^{K}\exp z_{k}}}=\sigma (\mathbf {z} )_{i},$$ for ⁠$i=1,\dotsc ,K$⁠ and ⁠$\mathbf {z} =(z_{1},\,\dotsc ,\,z_{K})\in \mathbb {R} ^{K}$⁠.

–jacobolus (t) 07:33, 15 September 2026 (UTC)

I made various changes at Softmax function. Feel free to make further edits if there's something that still has issues. –jacobolus (t) 08:10, 15 September 2026 (UTC)