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)[reply]

@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)[reply]

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

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)[reply]

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)[reply]

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)[reply]

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.

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)[reply]

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)[reply]

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)[reply]

{{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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

We already have some references/cite-specific CSS rules, so I don't see an issue with adding a few more. Ideally it should all be in the extension but if that's not feasible for any reason, well, that is why MediaWiki:Common.css exists. 277k is a significant number of pages. – SD0001 (talk) 08:19, 2 January 2026 (UTC)[reply]

It's one of those things that's feasible in theory, but needs someone to design and submit the code change for the Cite extension and then another developer to review and merge it. On the plus side, at least Parsoid doesn't have its own separate Cite implementation anymore. Anomie⚔ 14:57, 2 January 2026 (UTC)[reply]

Yes, but it seems silly for an extension to style things based on a user-controlled data attribute. phab:T196942 is probably a more sensible approach. – SD0001 (talk) 16:22, 2 January 2026 (UTC)[reply]

That seems far less reasonable to me. Why should we have to do like <references group="lower-alpha" counter-style="lower-alpha" /> to match <ref group="lower-alpha">? What would make sense to me as a quick fix, if people really don't want to use common.css for this, would be to have a message like MediaWiki:Cite references.css that would be included in the page when <references /> is present and we could put the relevant CSS there.

OTOH, glancing at tasks like phab:T378570 and phab:T383969, it seems like the developers working on Cite want to output like <li style="--footnote-number:'a'"> (with the 'a' derived from e.g. MediaWiki:Cite link label group-lower-alpha, same as it is to produce the ^[a]) and have CSS like li::marker { content: var( --footnote-number ) ' '; } to completely override the browser-based numbering. That would be even more of an improvement, as we wouldn't be restricted to what can be done with list-style-type, but who knows whether it'll happen any time soon. Anomie⚔ 17:09, 2 January 2026 (UTC)[reply]

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)[reply]

@ChrisToddAngle:  Not done for now: please establish a consensus for this alteration before creating an edit request. You are free to add it to User:ChrisToddAngle/common.css if you so wish. Alternatively, if you specify the exact page name of this custom hover‑image template, we can look at possibly including it into the TemplateStyles for that template. But no way are we putting it into the sitewide CSS without a proper use case, nor even a means to examine present behaviour. --Redrose64 🦌 (talk) 11:23, 31 December 2025 (UTC)[reply]

A simple search reveals that the class hoverimagebox is in fact not used or mentioned anywhere on Wikipedia except on this page. Mr. Starfleet Command (talk) 18:32, 31 December 2025 (UTC)[reply]

In fact this is the only mention on any WMF wiki.

@ChrisToddAngle, I suspect you have ended up on the wrong wiki. On whichever wiki you are requesting this for, I would instead very strongly recommend employing mw:Extension:TemplateStyles, which is deployed on both Fandom and Miraheze, among several others. Further assistance for use should be directed to their support staff pages. Izno (talk) 22:15, 31 December 2025 (UTC)[reply]

I’d very strongly recommend not to do this change, either via Common.css or via TemplateStyles. The :focus and :active styles serve an accessibility purpose: for example, people using a keyboard have otherwise no idea what the currently selected element is and thus what will happen if they press the Enter key. —Tacsipacsi (talk) 22:39, 31 December 2025 (UTC)[reply]

/* Remove bullets when there are multiple edit page warnings */
ul.permissions-errors {
	margin: 0;
}

ul.permissions-errors > li {
	list-style: none;
}

These rules look unnecessary. permissions-errors is used on the edit page if you don't have permission to edit. It's a div if there's a single error, and a ul if there are multiple. Most of the time, there's only one error. I'm not sure what scenario would cause multiple permission errors. But even if such a scenario exists, why would we want to suppress the list presentation? – SD0001 (talk) 08:33, 2 January 2026 (UTC)[reply]

I'm sure there was a good reason for it, but i also don't remember. We can always remove and find out :) —TheDJ (talk • contribs) 08:40, 2 January 2026 (UTC)[reply]

I'm not sure what scenario would cause multiple permission errors. if a page is protected and also the user is blocked or their IP range is blocked. Even Special:Edit/MediaWiki:Common.css has two list items in its list for my account: MediaWiki:Protectedinterface and MediaWiki:Sitecssprotected, but the list item for MediaWiki:Protectedinterface ends up empty because of its internal logic.

But even if such a scenario exists, why would we want to suppress the list presentation? because banners with list decorations tacked on their side don't look good, especially when the list item ends up empty, like the aforementioned example. The "permission errors" banners include {{skinfile}}, {{protected interface}}, {{Blocked proxy}} {{Blocked text}}, Template:Editnotices/Namespace/MediaWiki, etc. —⁠andrybak (talk) 09:55, 2 January 2026 (UTC)[reply]

That makes sense. So we would need to add some TemplateStyles in the interface messages to remove it from Common.css. – SD0001 (talk) 10:13, 2 January 2026 (UTC)[reply]

I have strictly attempted to avoid introducing TemplateStyles after the element of interest is provided so as to do my best to avoid FOUCs. The elements targeted here are also not something under our control, so arbitrary templates may not catch the styles that are necessary to hide the list bullets. I have left these two in Common.css as such. Izno (talk) 16:49, 2 January 2026 (UTC)[reply]

These lists are not descendants of .mw-parser-output, so it’s simply impossible to style them using TemplateStyles. —Tacsipacsi (talk) 20:43, 2 January 2026 (UTC)[reply]

That is also true, and I swear I checked. Must have gotten mixed up. Izno (talk) 20:55, 2 January 2026 (UTC)[reply]

Yeah, I was going to write that if you put the templatestyles as the first thing in MediaWiki:permissionserrorstext and MediaWiki:permissionserrorstext-withaction, it'll always appear before the element of interest.
But the trouble is that these are lego messages. The software just concatenates the list of reasons with the above message, instead of passing it to it as a parameter, which would have allowed us to wrap the whole thing in .mw-parser-output. Seems more trouble than worth it to fix it in MediaWiki. – SD0001 (talk) 04:52, 3 January 2026 (UTC)[reply]

A couple other solutions:

1. Probably we could add it as part of a default style gadget for actions=edit. I would have no general grief with that.
2. Adjust MediaWiki to add it to the same resource file as action=edit. This probably doesn't work given we're kind of abusing the messages for what I expect was intended to be inline HTML rather than block HTML and so other wikis might not appreciate it as much as we would. But it should be a technically simple change comparatively.

Izno (talk) 05:07, 3 January 2026 (UTC)[reply]

Which maybe wouldn't be super unwelcome, about 15% of the fleet has this CSS. Izno (talk) 05:13, 3 January 2026 (UTC)[reply]

The MediaWiki default messages are simple text; the list decoration is necessary for them. – SD0001 (talk) 13:07, 3 January 2026 (UTC)[reply]

There are many lists throughout the interface that have no list decoration. Vector 22 sidebars, {{sidebar}}s, and so on. Just noting it as an option. Izno (talk) 16:26, 3 January 2026 (UTC)[reply]

Those are more like menus than real lists. I wouldn’t appreciate bullet-less lists with the default unformatted content, so I don’t think MediaWiki should default to this CSS. (However, I wouldn’t appreciate the enwiki boxes with bullet points either.)

For the 15%: probably many wikis are simply blindly copying CSS from enwiki (or other wikis), whether they need it or not, so it’s probably a large overestimation; I’d guess as many as 100-120 of those 150 results are unnecessary. —Tacsipacsi (talk) 00:36, 4 January 2026 (UTC)[reply]

Probably true, but it's there nonetheless for external wikis.

I don't particularly disagree with the first paragraph, just musing. Izno (talk) 21:21, 4 January 2026 (UTC)[reply]

[I]t's there nonetheless for external wikis – could you elaborate more on this? What is “it”, and for which external wikis? —Tacsipacsi (talk) 22:16, 4 January 2026 (UTC)[reply]

For the 15%. Izno (talk) 22:42, 4 January 2026 (UTC)[reply]

• Hmm, I thought these were useless but saw that User:Codename Noreste just decided to IMPORT this in to another project. Codename Noreste, what actual problem is this solving? — xaosflux ^Talk 00:13, 5 January 2026 (UTC)[reply]

  • Open in a private window.
  • Find the relevant lines in console
  • Turn them off
  • Look in the general edit notices area

  Observe the bullets. Izno (talk) 00:22, 5 January 2026 (UTC)[reply]

  I imported that code to English Wikibooks and Meta-Wiki to remove the bullet lines when a user views the source code of a protected page they cannot edit. Codename Noreste (chat) 20:35, 7 January 2026 (UTC)[reply]

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)[reply]

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)[reply]

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.

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

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)[reply]

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

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