MediaWiki talk:Common.css

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

Uncollapse collapsed elements doesn't work on printable version

Due to phab:T327893, the .mw-collapsed {display: none;} was replaced by .mw-collapsed[hidden="until-found"]. So uncollapse collapsed elements doesn't work on printable version now. See Help:Collapse, collapsed tables will not expanded automatically on printable version. Dabao qian (talk) 08:48, 8 January 2026 (UTC)

I had left phab:T327893#11225815 before. We can file a task about it at least for print mode. Izno (talk) 00:39, 9 January 2026 (UTC)

Proposal to change the border color of mw-contributions-blocked-notice-partial

I would like to propose changing the border color of the partial block message box (e.g. when a user is partially blocked), because the proposed change would make the partial block message box appear like the default MediaWiki warning message box (without the fmbox color styling) on CSS.

−

/* default colors for partial block message */ /* gotta get over the hump introduced by the triple class above */ .mw-contributions-blocked-notice-partial .mw-warning-with-logexcerpt.mw-warning-with-logexcerpt { border-color: #fc3; background-color: var(--background-color-warning-subtle, #fef6e7); }

+

/* default colors for partial block message */ /* gotta get over the hump introduced by the triple class above */ .mw-contributions-blocked-notice-partial .mw-warning-with-logexcerpt.mw-warning-with-logexcerpt { border-color: var(--border-color-warning, #ab7f2a); background-color: var(--background-color-warning-subtle, #fef6e7); }

What do you think? Codename Noreste (talk • contribs) 02:53, 19 January 2026 (UTC)

We should use the design token instead of hardcoding it, i.e. var(--border-color-warning, #ab7f2a). – SD0001 (talk) 11:56, 19 January 2026 (UTC)

I implemented your suggestion to my proposal accordingly. Codename Noreste (talk • contribs) 14:03, 19 January 2026 (UTC)

 Done – SD0001 (talk) 15:30, 19 January 2026 (UTC)

max-width vs min-width

There are a few (max-width: 640px) conditions in MediaWiki:Common.css. Since then, core has switched to using (max-width: calc(640px - 1px)). This is to avoid overlap with min-width:640px. I suggest we align with that convention. —TheDJ (talk • contribs) 12:31, 16 February 2026 (UTC)

Based on what both of the max-width blocks are doing, I don't think the extra bit of computation is needed. Izno (talk) 17:39, 16 February 2026 (UTC)

And to expand on that, the infobox block is actually appropriately implemented, since it covers the subpixel width between 639 and 640 with 100% and then a later appropriate default width (that goes along with the margin and float definition).

While the other (flag) block is removing the max-width that would have come with a shrinking resolution, so the difference between max-width and none at 640 versus 639px is effectively nil probably.

The best solution of course is wide support for range syntax in width queries. (Plus container queries so that we can stop having to account for the width of the sidebars.) Izno (talk) 18:52, 16 February 2026 (UTC)

Interface-protected edit request on 8 March 2026

I suggest we create MediaWiki:Group-bureaucrat.css with:

/* Show hidden items that have class="bureaucrat-show". */
div.bureaucrat-show,
p.bureaucrat-show {
  display: block !important;
}
span.bureaucrat-show,
small.bureaucrat-show {
  display: inline !important;
}
table.bureaucrat-show {
  display: table !important;
}
li.bureaucrat-show {
  display: list-item !important;
}

And then add .bureaucrat-show, to the /* Hide stuff meant for accounts with special permissions. */ section on MediaWiki:Common.css. 2600 etc (talk) 20:33, 8 March 2026 (UTC)

Two questions: (a) which pages or templates would this affect? (b) why do you feel it to be necessary? You don't appear to be a bureaucrat. --Redrose64 🌹 (talk) 22:41, 8 March 2026 (UTC)

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

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)