MediaWiki talk:Common.css

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

Discussion at Wikipedia:Village pump (proposals) § Change editnotice appearance for mobile contributors

 You are invited to join the discussion at Wikipedia:Village pump (proposals) § Change editnotice appearance for mobile contributors. waddie96 ★ (talk) 17:39, 8 September 2025 (UTC)

cmbox migration

A change to how {{cmbox}} is implemented to support mobile resolutions better is occurring soon. It may cause some temporary display weirdness. Further information is available at Module talk:Message box § cmbox migration. Izno (talk) 21:41, 1 October 2025 (UTC)

infobox width 22em

Hi there. Following the discussion at Wikipedia talk:Image use policy#Image size in the lead updates, it looks like we might need to amend the default infobox style to not be 22em, but something slightly larger that would accommodate the slightly larger image.

It looks like this setting was added with this 2021 edit by @Izno saying add classes from module sandbox. I'm not sure what that specifically refers to, could you please explain? I checked the talk archive for 2021 at MediaWiki talk:Common.css/Archive 19 but didn't seem to find any mention of this.

Anyway. Template:Infobox settlement/styles.css already uses 23em, since the original revision in 2021. Can we just follow suit?

Or, maybe, can we just ignore this setting, leaving image-less infoboxes as they are anyway? :) --Joy (talk) 13:56, 20 October 2025 (UTC)

@Joy, 22em has been the width in {{infobox}} if not the class itself since April 2008. (It was 25em before.) Based on the edit summary then, I'd guess the relevant discussion was Font-size discrepancies between browsers, which does not illuminate on the width change. (Settlement's width is coincidentally older, I stopped looking through diffs after I got to late 2006 which is quite nearly the beginning of templates.)

Either way, that age is sufficiently old that there is WP:SILENCE for its current size.

My change to Common.css you are querying now was to move that width to the class itself from Module:Infobox, since at the time there were only some 5,000 pages which used a manual infobox (clearly meaning people have settled on the template, as I think a good practice anyway - both my change and the use of a core template is incidentally required to support moving the CSS to TemplateStyles).

Given how widely this class is used (4.26 million articles at minimum, though I'm sure some have a modified width), I would expect an RFC for a change here. My sense of all the image discussion is predominantly aesthetic - people don't like the whitespace left and right with the larger default images, and not that this actually causes inconsistent sizing of the box containing the image (as the template is presently implemented as an HTML table, its default display implementation stretches to accommodate its content regardless of any width one sets in CSS, so in that sense it's more of a minimum width than an enforced width).

Additionally, we can specify image widths in whatever value but ultimately it's a question of pixels in images (regardless of using any so-called upright parameter) versus the ems used in infobox, which means it is non-0 math to take an image width and compare it to the width produced by an infobox, since an infobox's width respects several other factors e.g. skin font size and browser zoom size. These are some things for whomever wants to start a consensus discussion on changing the size here. I'd suggest optimizing for what can be assumed to be the 'default' width of things in the default skins, so Minerva on specifically mobile (which makes the infobox 100% wide at mobile resolutions, so perhaps a non-issue in any meaningful sense), Minerva at tablet resolutions on mobile (which does not), Vector 2022 with standard width and text size options at low-mobile to high-tablet size on desktop (because half windows), and Vector 2022 with standard width and text size options on desktop at full resolution. I'd also recommend testing Vector 2022 in other text and width options as those are available to readers as well as editors.

(On a personal aesthetic point I am distinctly unbothered by how large images are in relation to the current infobox width, and generally prefer additional text to left to enlarging the infobox. You're going to have a hard sell on the point I think, but guessing at consensus is just guessing. You'll want some {{lorem ipsum}} on a sandbox page to compare things.)

Or, maybe, can we just ignore this setting, leaving image-less infoboxes as they are anyway?: I don't understand this question. Izno (talk) 17:11, 20 October 2025 (UTC)

The consensus in Wikipedia:Village pump (proposals)/Archive 210#Increase default thumbnail size from 220px to 250px is far more clear than any of this weak silent consensus through past implementation edits not being contested. In the examples considered there, that image size left a bit of space between the sides of the infobox. I'm just looking for a way to make sure that is reproduced as faithfully as possible, without breaking anything else. At the same time, it's a detail that I'm definitely not going to start a new RFC over. The software change to 250px stemming from the same discussion was already done earlier this year. Likewise for the change in Module:InfoboxImage a couple of days ago. The five million article contingent is already affected, the only question is whether more tweaking is needed to match the consensus decision. --Joy (talk) 18:09, 20 October 2025 (UTC)

That RFC barely considers this aspect of the question. A total of two !votes mention the word infobox, there are only some 11 mentions total of the word infobox, and the summary does not mention infoboxes.

I have little heartburn over changing the size, but it's not something to do SILENTly now. Do the homework I suggested and start a new RFC based on that review. Izno (talk) 18:30, 20 October 2025 (UTC)

The RFC literally has pictures of the Earth article infobox at different image sizes. Did you not see them? --Joy (talk) 18:34, 20 October 2025 (UTC)

@Ganesha811 do you agree with Izno's interpretation above that File:Compare different image widths, English Wikipedia.png and the idea of infobox image sizes wasn't a substantial element of the discussion linked above? --Joy (talk) 18:36, 20 October 2025 (UTC)

I don't want to wade too far into this, as I'm not at all familiar with the technical issues at hand or the history of how infoboxes are handled, but I'd say that the discussion I closed did not include much conversation about infoboxes. However, "absence of evidence is not evidence of absence", meaning that it's possible that other editors intended or understood their comments to encompass infoboxes but did not say so explicitly. The discussion focused explicitly on thumbnails. —Ganesha811 (talk) 18:52, 20 October 2025 (UTC)

Are there specific articles in which the current infobox width is causing problems? Linking to a few might be enlightening. – Jonesey95 (talk) 18:55, 20 October 2025 (UTC)

Practically, editors have been adding wider top images into a variety infoboxes for a long while now, and I don't think we've cared much, generally speaking. It's only really a problem if we try to enforce the aforementioned section of the image use policy. --Joy (talk) 20:00, 20 October 2025 (UTC)

<references /> groups

Ref tags using certain groups use customized labels via MediaWiki:Cite link label group-lower-alpha, MediaWiki:Cite link label group-lower-roman, MediaWiki:Cite link label group-lower-greek, MediaWiki:Cite link label group-upper-alpha, and MediaWiki:Cite link label group-upper-roman. {{reflist}} applies CSS to cause the references list to match these labels, but bare <references /> does not.

Examples

{{reflist}}	<references />

Thanks to gerrit:991614 we can now fix that by adding a small bit of sitewide CSS. It does not seem possible (without changes in mw:Extension:Cite) to have the <references /> tag itself add the styles. What do you think? Anomie⚔ 23:59, 22 November 2025 (UTC)

See also Template talk:Reflist#Excess styles, where adjusting {{reflist}} itself to use CSS like this is under discussion. Anomie⚔ 23:59, 22 November 2025 (UTC)

I don't really want to add them here since they are a pretty limited set of use (most of {{notelist}} and that's it - 270k is sizable but not in comparison to the number of articles we have) and because I think it's better to have support for validation, which can't be done in the core styles. Izno (talk) 03:27, 23 November 2025 (UTC)

{{notelist}} isn't the only way these may be used, although it is probably a major one at the moment. On the other hand, having this working would help with implementing Wikipedia:Village pump (proposals)/Archive 223#Bot to make list-defined references editable with the VisualEditor. As for validation, what kind of validation are you referring to? Anomie⚔ 03:39, 23 November 2025 (UTC)

Reflist could surface (it doesn't currently because groups can be named with anything e.g. "note" is common) that the user has input a group that has no effect on the display.

If people want custom styles, I think it's fair to say "use the template", especially when the styles are so limited. {{notelist}} being the primary benefactor of that makes it irrelevant whether VE can do things, since you're supposed to use {{efn}} with it anyway. I would also prefer not to expose the machinery to end users since they frequently get things wrong (and then I am one of the folks who has to clean things up).

Groups hooking into the special styles without notelist is probably few and far between, though I'm sure not totally absent. Izno (talk) 03:47, 23 November 2025 (UTC)

Note there's a strong sentiment from some others, as seen in the linked VPR discussion for example, that {{reflist}} was useful in the past but we should be moving more towards using <references /> now that it's near feature parity. The only things really lacking are custom column widths, forcing columns for <=10 refs, and this, while {{reflist}} lacks VE compatibility.

Reflist is never going to "surface" that the group isn't one of the special ones, specifically because groups like "note", "nb", and such are perfectly valid. Anomie⚔ 05:10, 23 November 2025 (UTC)

Yes, and I'm one of the ones who would prefer to use the bare references tag in most situations. "I want to do something custom" is feasibly "use a template", especially when that custom thing is already tied to a totally separate template in the vast majority of cases ({{notelist}} and {{efn}}).

"Reflist is never going to surface" is kind of like saying "Wikipedia is never going to use the bare reference tag"... which is something that might have been said in 2010. :^) Izno (talk) 05:15, 23 November 2025 (UTC)

In this case, the only "something custom" that really wants a template is getting the correct list-style-type applied. Otherwise e.g. <ref group=lower-alpha> and <references group=lower-alpha /> easily suffice for many uses. Anomie⚔ 15:19, 23 November 2025 (UTC)

I concur this should be added, and don't find Izno's argument convincing. * Pppery * _{it has begun...} 16:48, 23 November 2025 (UTC)

Minimizing the amount of CSS loaded across WP is a good thing, and as Inzo mentioned, the number of pages using the relevant reference groups is small relative to the overall number of pages we have. So, I agree with Inzo that these styles should be applied through templates, not common.css. It shouldn't be too much of an ask for users to use a template, but in the few cases where users fail to do so, that's not really a big issue either.

That said, I think the ideal solution would be for this to be handled internally by mw:Extension:Cite, which would render this question moot, but I suppose that's a separate issue. Mr. Starfleet Command (talk) 02:41, 26 November 2025 (UTC)

This was another direction that I hadn't gotten around to noting, WMDE intends to have Cite do the work at some point. phab:T369275 and children. They bumped into this question while doing subreferencing but haven't revisited the stuff for a year so I don't know if it will get done. Izno (talk) 02:53, 26 November 2025 (UTC)

Am I confused or is this functionality already working? <references group="lower-alpha" /> and <references group="lower-greek" /> work as expected for me when used with {{efn}} and {{efn-lg}}, respectively. -- Beland (talk) 04:25, 17 December 2025 (UTC)

It's not, although the example above doesn't show it anymore after Special:Diff/1327269900. Compare Special:PermaLink/1328021242 (<references />) with Special:PermaLink/1328021322 ({{reflist}}) instead. Anomie⚔ 13:24, 17 December 2025 (UTC)

Ah, you're right, I was confused!

This is preventing implementation of the standard fix for incompatibility between list-defined references and the Visual Editor on some pages like Ginny Gibson. Can we just put a note on the phab ticket to drop the overrides in this file if the fix ever gets implemented at a different level? Otherwise, I think the workaround would be to create a template like {{fix ref list style}} that adds Template:Reflist/styles.css to individual pages that can't be fixed in any other way. -- Beland (talk) 11:12, 22 December 2025 (UTC)

I do see that there are other blocks in Common.css that are marked as should-be-removed when a specific phab bug is fixed.

Note to self: when we get a working method, the instructions at Help:Footnotes § Template use by reference group type need to be updated. -- Beland (talk) 11:18, 22 December 2025 (UTC)

Interface-protected edit request on 31 December 2025

Please add the following CSS to `MediaWiki:Common.css` to remove an unwanted blue focus outline that appears around my custom hover‑image template.

This rule is scoped only to the `.hoverimagebox` class and will not affect any other images or editors. It is a small visual fix and does not change site‑wide behavior.

CSS to add:

.hoverimagebox *:focus,
.hoverimagebox *:active {
  outline: none !important;
  box-shadow: none !important;
}

This will remove the unintended blue highlight box that appears around the template’s floated image container. Thank you. ChrisToddAngle (talk) 08:51, 31 December 2025 (UTC)