Template talk:Reflist: Difference between revisions

Line 140: Line 140:

**Also – and I don’t know if this is because of this change or not – but starting this past month, I’ve noticed that on mobile view, Wikipedia is eeeever so slightly zoomed in a bit when you first load an article, as if there were a too-large image in it somewhere automatically resizing the page to fit it in. I don’t know if this is as a result of the changes to this template or not, but it’s every article I’ve been on so far.—[[User:Ineffablebookkeeper|Ineffablebookkeeper]] ([[User talk:Ineffablebookkeeper|talk]]) ({{[[Template:ping|ping]]}} me!) 11:56, 14 December 2025 (UTC)

**:{{re|Ineffablebookkeeper}} Looks like you’re right, on the actual mobile view (not just <code>useskin=minerva</code>), [[MediaWiki:Common.css]] is not loaded and therefore {{tag|references|s}} doesn’t get the <syntaxhighlight lang=css inline>font-size: 90%</syntaxhighlight> from there. {{tl|reflist}} used to do its own <syntaxhighlight lang=css inline>font-size: 90%</syntaxhighlight>, but no longer does after this change. On the other hand, if [[phab:T375538]] had happened first then mobile would have started loading [[MediaWiki:Common.css]] to get the 90% size, and better synchronizing {{tag|references|s}} versus {{tl|reflist}} was the goal of this change anyway. Converting between {{tag|references|s}} and {{tl|reflist}} should ideally be a [[WP:Cosmetic edit|cosmetic edit]] in most cases, freeing us to do things like converting {{tlx|reflist|refs{{=}}…}} to {{tag|references}} because the former doesn’t work well in VE, or because {{tl|reflist}} behaves more poorly when [[WP:PEIS|PEIS]] is hit.{{pb}}As for your mobile zoom thing, that has nothing to do with this. [[User:Anomie|Anomie]][[User talk:Anomie|⚔]] 14:50, 14 December 2025 (UTC)

== {{Reflist|30em}} ==

Both {{code|Reflist{{!}}30em}} and {{code|Reflist{{!}}2}} are not working for me, like it’s still same with {{code|Reflist}}. How can I change the fonts’ sizes to previous size using parameters? I also tried {{code|Reflist{{!}}27em}}, but it wasn’t working. [[User:Camilasdandelions|”’ ”Camilasdandelions” ”']] ([[User talk:Camilasdandelions|talk!]]) 07:18, 15 December 2025 (UTC)

This page is used for general discussion about Template:Reflist, a Wikipedia references template, which is used on many articles. For help on adding a reference to an article, see Wikipedia:Citing sources, or ask for help on that article’s talk page.

Archives

Index 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
11, 12, 13, 14, 15, 16, 17, 18, 19, 20
21, 22, 23, 24, 25, 26, 27, 28, 29, 30
31, 32, 33, 34

This page has archives. Sections older than 60 days may be auto-archived by Lowercase sigmabot III if there are more than 4.

You are invited to join the discussion at Wikipedia talk:Citing sources § New proposal: deprecate {{reflist|refs= in favor of <references>?. Dan Leonard (talk • contribs) 03:01, 30 April 2025 (UTC)[reply]

Is there a way to identify articles that include {{reflist}} but do not have any actual references? Palagianello railway station is one example. I’m trying to identify and cleanup unreferenced articles. Thanks, Mackensen (talk) 12:04, 15 August 2025 (UTC)[reply]

Here are 2,000 articles that contain {{reflist}}, have no closing </ref> tags, and have “station” in their article name. There may be some false positives if articles use {{sfn}} or similar syntax, but that search should give you plenty to work on. – Jonesey95 (talk) 13:16, 15 August 2025 (UTC)[reply]

Awesome, didn’t even think to try it that way. Thanks! Mackensen (talk) 16:51, 15 August 2025 (UTC)[reply]

-hastemplate:sfn knocks another 400 out. Izno (talk) 23:09, 8 September 2025 (UTC)[reply]

So how does the French Wikipedia do this with their reflists? When I go to French Coco Gauff article and go down to the references, they are in a nice neat scrollbox. Some of our player articles have hundreds of references and this would sure be nice to have. I can’t figure out how to do it. Fyunck(click) (talk) 02:49, 6 September 2025 (UTC)[reply]

See the CSS for how it works. I think we do not use the overflow:auto styling in article space because it interferes with accessibility. See MOS:SCROLL. If you wanted to put it in your own personal CSS, you could probably apply the French styling to .reflist or a similar class. – Jonesey95 (talk) 05:55, 6 September 2025 (UTC)[reply]

That’s too bad since these reference lists at the page bottom can get pretty long. I wonder if it is still an accessibility problem with the latest incarnation of screen readers? We have found that many things written in MOS don’t really apply anymore but MOS hasn’t been updated to reflect this. Maybe this is in that category? Thanks for the answer, but it sure looked nice on the French Wiki. Fyunck(click) (talk) 06:19, 6 September 2025 (UTC)[reply]

@Fyunck(click), French Wikipedia appears to not use the scrolling on mobile. On mobile, it could create a separate accessibility issue for readers with fine motor control deficits trying to scroll either in the references or in the whole page, but getting kind of stuck in the references. (It looks like French Wikipedia editors disabled the style on mobile and print to address this.) Some readers with fine motor control issues may not be using a mouse even on desktop. Trackball and touchscreen pointing would still allow for scrolling, although it would be less convenient on the trackball (you hold a key with the opposite hand to make the trackball work as a giant scroll-wheel). As far as keyboard navigation: the Orca screen reader on Linux Mint treats those references as a standard list, and sighted keyboard navigation allows scrolling after tabbing into the scrollable section (although it is less convenient). One accessibility issue that came up in the French Wikipedia discussion about problems with scrolling references is for sighted users with poor vision. There isn’t a great way to use browser zoom features to better see the references because they are locked into that box. To get MOS:SCROLL changed, I think you’d really need to get a kind of broad survey that includes each of the potential issues and multiple accessibility technologies to test out, and then give advice on how to meet those challenges. Also, outside of accessibility concerns, I see some editors over there calling for that template’s deletion because they view it as a pain and an obstacle. Rjjⁱⁱⁱ (talk) 14:10, 6 September 2025 (UTC)[reply]

Thanks for all that. Being sighted one doesn’t always realize the extra difficulties it could cause. I know the latest screen readers do well in areas they didn’t before so I thought maybe they had overcome this and it was why the French version had changed. Obviously not. Cheers. Fyunck(click) (talk) 17:50, 6 September 2025 (UTC)[reply]

For some articles such as Wikipedia space articles, it may not always be appropriate to have a proper reflist, and it may only appear if some users add such a reference. Would it be possible or worthwhile to add a |sectiontitle= field such that these articles can have a References section that auto-hides if the references are removed? Would it be worthwhile to make a separate template for such a case? guninvalid (talk) 18:06, 18 September 2025 (UTC)[reply]

Reflist already auto-hides (displays nothing, really) if there are no references on a page, as shown below. And references auto-display at the end of the page if references are added, even without a {{reflist}} template. At this point, I think this template is more likely to go away than to have major functionality added. – Jonesey95 (talk) 19:53, 18 September 2025 (UTC)[reply]

While I agree that adding more functionality here doesn’t seem like the direction we want to go these days, you seem to have missed the point of the request. They’re wanting the “References” section header to also disappear if there are no references, instead of there being an empty section on the page. OTOH, I don’t think that’s possible in wikitext or Lua anyway. Anomie ⚔ 21:14, 18 September 2025 (UTC)[reply]

There are a lot of styles in Template:Reflist/styles.css that are redundant to styles produced by mw:Extension:Cite. In some cases we override mw:Extension:Cite to do things in a slightly different way. I propose we clean this up a bit, to bring the rendering with {{reflist}} more in line with <references />: Reflist change Styles change

The main differences are:

Manually-specified column widths are ~~slightly wider~~ , as the width is calculated based on the page’s normal font size rather than the 90% size. This brings {{reflist}} in line with <references /> .
If people have personal CSS overriding some of the styles, those overrides may not work the same.

This follows from some of the discussion at Wikipedia:Village pump (proposals)/Archive 223#Bot to make list-defined references editable with the VisualEditor where people complained about {{reflist}} and <references /> rendering differently in some cases.

I’ve updated Template:Reflist/testcases to better show the differences between live and sandbox versions. Please add any more test cases that may be useful.

Any objections to making this change? Anomie ⚔ 03:02, 20 November 2025 (UTC)[reply]

Support. This template was created when the <references /> tag did not create columns, an article’s page width was equal to the width of a computer monitor, and Wikipedia was still supporting ancient versions of Internet Explorer. There is no longer a reason to have those inconsistencies between the template and the tag. Rjjⁱⁱⁱ (talk) 03:17, 20 November 2025 (UTC)[reply]

Comment: It definitely breaks my custom CSS a little when it comes to making columns, and looking at it while logged out shows similar differences. Logged out example: In the “reflist 30em” section, the live version shows two columns on my computer but the sandbox shows just one column. This change may bother some/many editors. – Jonesey95 (talk) 03:54, 20 November 2025 (UTC)[reply]

Which is why gerrit:1185300 changed the auto-columns from 30em to 27em on Vector 2022. The sandbox version also uses 27em rather than 30em for {{reflist|2}} on that skin. But there’s not much we can do about {{reflist|30em}}, unless maybe we want to make the template do like column-width: calc( 0.9 * {{{colwidth}}} ) across the board I suppose. Anomie ⚔ 04:05, 20 November 2025 (UTC)[reply]

… Actually, that’s probably not that bad of an idea. It would preserve the rendered sizes of invocations passing ems, at the cost of breaking some of the historical correspondences (e.g. {{reflist}} and {{reflist|2}} are historically “30em”, but would now be “33.333em” (except on Vector 2022)). Anomie ⚔ 13:35, 20 November 2025 (UTC)[reply]

It’s not just 30em. There are fewer columns at other column widths as well. It appears to stem from the removal of “font-size: 90%”, so restoring the 90% factor to the column width in some way, as you suggest with some math above, would probably do the trick. – Jonesey95 (talk) 15:33, 20 November 2025 (UTC)[reply]

Some thoughts:

Names with mw- in them can be changed out from under us even without warning. (See mw:Stable interface policy/Frontend.) Hooking into those classes can end in a bad story.
This template is being hooked into by {{notelist}}. These changes don’t consider that template at all. Notably, these changes remove the enclosing div with the reflist class, which takes the opportunity to remove the class that notelist sets. My personal preference on top of that is to retain that div because it makes it obvious in the HTML that a template is involved here.
I approve of moving on Template:Reflist/styles.css#L-8, if you’ve done the work to test things.
NB that reflist has set columns does make it different when there are fewer than 10 references, which is when the class for refs-with-columns kicks in in Cite. This is a rendering difference that simply cannot be accounted for. Whether that’s a valuable difference to preserve is not something I have an opinion on.

Might have others but that’s what I’m thinking about. Izno (talk) 03:41, 23 November 2025 (UTC)[reply]

Replies:

The other alternative would be to copy the current styling Cite applies via its wrapper to our own classes (i.e. these), which seems less likely to be stable than these two classes that have existed since 2015. Particularly since changing the classes would mean reparsing every page with references to update the HTML while changes to the CSS can just roll out. But if people really would rather risk the CSS getting out of sync than HTML classes that haven’t changed in 10 years, we could bring back those lines (and re-sync them with Cite) and the corresponding classes easily enough. 🤷 P.S. And all of this only applies when |1= or |colwidth= is used anyway.Also, the language I see in mw:Stable interface policy/Frontend specifically calls for caution when developers are changing mw- classes because people on-wiki tend to rely on them, even though they bend over backwards to suggest they aren’t really stable. Particular care MUST be taken when: […] changing any element using a class or ID prefixed with mw- as traditionally the prefix has been associated by some as a stable interface.
I see no “hooking in” by {{notelist}}, it appears to be a very standard wrapper template that does not care in the slightest what the output of {{reflist}} is.
Tests are in Template:Reflist/testcases, as already noted. Feel free to add more if you have any.
The “kicks in” you’re referring to is that Cite doesn’t emit the wrapping <div class="mw-references-wrap mw-references-columns"> until there are more than 10 cites. The CSS itself does not attempt to count how many items are in the list, and it seems vanishingly unlikely it ever will try to do so (e.g. by doing like .mw-references-columns:has(>ol.references>li+li+li+li+li+li+li+li+li+li+li)). As for behavior, both current and sandbox {{reflist}} force columns when |1= or |colwidth= is specified and let Cite handle it otherwise.

Anomie ⚔ 04:56, 23 November 2025 (UTC)[reply]

Our CSS for columns predates the CSS added in Cite (added August 2013 e.g. [1] and others in the few months after) and is actually what inspired the upstream CSS i.e. it’s actually more stable. There is nothing to “sync” or “resync” there and I don’t really see why you’re touching it at all.
Uh, yes, notelist does not. I still prefer to have that class emitted.

No comment on 3/4. Izno (talk) 05:34, 23 November 2025 (UTC)[reply]

Just because ours came first doesn’t mean that Cite isn’t now the standard. I’m touching it to try to reduce the amount of custom CSS we have, because I’m tired of people whining that {{reflist}} and <references /> render differently in various cases so we can’t use the latter even when running into the shortcomings in the former (e.g. lack of VE support, losing the entire list when hitting PEIS).
Do you have any reason for keeping this difference between {{reflist}} and <references /> besides a personal preference?

Anomie ⚔ 15:38, 23 November 2025 (UTC)[reply]

Cite isn’t the standard: This exact same CSS is present in {{div col}}. Yes, I understand why you undertook to start this discussion. That doesn’t say anything about why you removed specifically that line.
People have personal CSS and scripts that use the name, as a primary reason. 400 some odd pages here. There’s another probably dozen or so scripts. Another reason is that mobile still recommends it though I suspect the primary needs for that are gone (reflist is specifically one of the classes that used to be called out in the relevant CSS though I managed to convince Jon that CSS wasn’t necessary so it’s been removed for a few years now). I expect it will be nice for Parsoid to have a root element at some point as well with their whole balanced templates and whatnot initiatives supporting parallel parsing. And overall, you’ve provided 0 reason for removing it. I don’t know why you think it needs to go. Please provide something that actually asserts that it needs removing. “Make template smaller” is a goal in some cases but I don’t find a sufficient need here given how ancient that class name is and how lightweight a single wrapping div is at the end of the day.

Izno (talk) 19:34, 29 November 2025 (UTC)[reply]

@Izno:

Cite is the standard for citations. {{div col}} is something else, with its own CSS that’s not relevant to this template. I’m not clear on what you mean by “that line”. If you’re referring to these 14 lines, between “rely on Cite classes that have been stable for 10 years” and “copy Cite CSS that has changed a bit in that time (e.g. gerrit:353369, gerrit:359493, gerrit:662063, and gerrit:1185300)”, the former seems like the lesser of two evils to me.
Multiple parts to this:
- Checking the first few custom CSS pages at your first link, the first isn’t even CSS, the second will be fine because it also applies to ol.references, and the next several (if they do anything at all) won’t apply to <references /> and so are already broken on various pages. So I’m not terribly convinced that affected users shouldn’t update their CSS if they want things to continue working.
- As for the scripts, many seem to be adding {{reflist}} or looking for it in wikitext, not depending on the class in the DOM at all. Those that do either also handle <references /> or are already broken, so again I’m not terribly concerned about not breaking them further.
- I see no mention of reflist at all at your “mobile still recommends it” link, anywhere in the page.
- Parsoid’s concerns, if I’m not misremembering, have been “templates should produce a complete document fragment” rather than “templates should produce exactly one DOM element”. The sandbox version of the template still does the former. Ignoring the <templatestyles /> tag, it still does the latter too.
- And overall, you’ve provided 0 reason for removing it. I have, although I haven’t stated it this clearly yet: Every difference in output between {{reflist}} and <references /> gives people one more possible thing to whine about if we want to change the former to the latter in some article. Therefore, removing all the differences we can will reduce the number of bogus complaints when we want to do that to avoid shortcomings in {{reflist}} like VE’s lack of support for {{reflist|refs=}} or hitting the PEIS taking out the entire references list.

Anomie ⚔ 20:29, 29 November 2025 (UTC)[reply]

I don’t have enough understanding of most of this to have a useful opinion, but the last of Anomie’s bullet points above makes sense to me, and I’d like to voice support for it. Mike Christie (talk – contribs – library) 21:03, 29 November 2025 (UTC)[reply]

“Cite’s CSS is standard” isn’t true. Our is as “standard” as Cite’s.
- You’re welcome to verify all 400+ won’t show up at VPT then.
- That reflist doesn’t appear there is irrelevant, it’s never appeared there. But as I said, it was in the relevant CSS.
- No, you’re not misremembering.
- None of that require removal of the class and wrapping div.

Look, part of my objection here is that you decided to wrap up a whole bunch of changes that should be reviewed and agreed to individually and didn’t have the courtesy to spell all of them out so we could discuss them individually. From what I can see:

Synchronize how column sizes are handled. I’ve already agreed to this as an objective (at least).
Use the new data-mw-group support to style the lists. I haven’t actively agreed to this but I have no qualms about it. (You’ve added div to these for no reason that I can see and I would remove them. They’re probably microseconds slower from a performance perspective and they don’t ultimately really protect us against anything.)
Remove the container div and class. I object to this and from what I can see you still have provided no good rationale for this. At best your rationale as now-stated is “I want to delete this template entirely”, which doesn’t do you favors and which I’ve objected to elsewhere.
Inserted references to class names that we don’t have control over and which we’ve been told we don’t have control over and which at best you have a “but WMF devs are supposed to” as if that’s ever counted for anything before or after the publication of the relevant guideline. I objected but not particularly strongly to this, and I’m also pretty certain it’s not necessary as there is CSS present that already handles this aspect (the CSS I think you’re calling “standard”).

I’m pretty sure I can sandbox something that moves us forward from current day to the day you like better with bullets 1 and 2 there, since your supposed objective is to remove rendering differences. Items 1 and 2 are necessary for that. Items 3 and 4 are not. Izno (talk) 22:30, 29 November 2025 (UTC)[reply]

@Izno:

Most MediaWiki wikis that have any sort of citations or footnotes at all will have the Cite extension. Do you really think all of them will copy our {{reflist}} too?
- Or, instead of wasting time doing that, I can watch VPT and respond if any actually do. 🙄 I note that, out of the 363 editors in the CSS search results, 201 haven’t edited in the past five years. It’s possible they’re still readers, but I really doubt you’d actually want to waste your time responding to the 400 {{edit interface-protected}} requests you’re asking me to create here any more than I want to waste time making them.
- Why did you link the page, claiming if it’s relevant, if it never appeared there? Claiming that some “relevant CSS”, which is not linked, is relevant isn’t all that convincing either.
- Ok. I’m glad we could dispense with that irrelevant argument so easily.
- It does though, and so obviously so that I can’t understand why you claim it doesn’t. If people are using the reflist class instead of classes that are present with both {{reflist}} and <references />, they may complain if a {{reflist}} is changed to <references /> because it breaks their customizations.

So far, it’s only you complaining that I’m planning on making one change to a template used on 6.5 million pages instead of making several changes, as recommended by the {{high-use}} template on this template’s documentation. Others have supported the changes.

The div is for the styles supporting the |liststyle= parameter, which overrides the data-mw-group-derived styles. The div is included to make sure those selectors have higher specificity than the data-mw-group-based selectors. Otherwise the specificity would be equal, and if the data-mw-group-derived styles do ever get moved to MediaWiki:Common.css or to some new MediaWiki-namespace stylesheet from T369275 or a similar task then load order might become significant. Probably the load order would still be ok (to not be, I think either a T369275-type solution would have to add inline styles rather than using ResourceLoader, or ResourceLoader would have to start adding some styles at the end of the page), and if you really want to remove the divs there to micro-optimize the selector performance then I’ll go along with it.
I don’t care about deleting this template entirely. I do want to, as much as possible, make it a plain wrapper for <references /> so we can do things like replacing {{reflist|refs=}} (which there’s already consensus for) without people complaining that the rendering somehow changes.
If more people than just you really want to duplicate the styles for the case when |1= or |colwidth= are used instead of using the same classes Cite uses, then I’d go along with that. But so far it’s just you, and I’m still not convinced that the risk they might suddenly, after 10 years and despite the developer-warnings to be particularly careful about that, decide to change the classes is more worrying than the risk they might change the CSS as they have in fact done a few times over the past decade.

Anomie ⚔ 00:33, 30 November 2025 (UTC)[reply]

Following the discussion above, column widths were changed to be multiplied by 0.9 (see the del/ins text in Anomie’s original post). For me, the testcases page now looks the same in the live and sandbox versions when I am logged out. When I am logged in, my custom CSS still shows differences, but that is purely my problem. That said, if this is to go forward, we’ll probably want to advertise it at VPT now that we have the initial bug(s) worked out. There may be other edge-case issues. – Jonesey95 (talk) 22:19, 20 November 2025 (UTC)[reply]

I note that wasn’t really a bug. We just changed which trade-off was being made to resolve a historical inconsistency between {{reflist}} and <references />, to one that seems less likely to have people complain “oh noes something changed”. Anyway, advertised there as you requested. Anomie ⚔ 13:51, 22 November 2025 (UTC)[reply]

Is there reason for the difference in non-V2022 automatic column test? — LCU ActivelyDisinterested «@» °∆t° 23:04, 23 November 2025 (UTC)[reply]

That’s the major rendering difference this change is trying to fix. Cite sets the 30em column width on the wrapper div and the 90% font size on the wrapped <ol>, while current {{reflist}} sets both on the wrapper. This means that {{reflist}} effectively uses 27em (90% of 30em) as the column width. That test puts things into a container div at a width that shows the difference.What complicates it further is that Cite was recently changed to use 27em for Vector 2022, to make it render as two columns rather than one with the default text size and width of that skin, and so {{reflist}} winds up effectively using 24.3em in that skin. The Vector 2022 test case sets a width appropriate to show that off as well.The sandbox version of {{reflist}} resolves the discrepancy by matching Cite’s behavior for the auto-column feature, so both {{reflist}} and <references /> will render the same. Anomie ⚔ 01:44, 24 November 2025 (UTC)[reply]

@Jonesey95, Izno, and ActivelyDisinterested: As there has not been further discussion and concerns seem generally addressed, I intend to implement this soon. If there are remaining objections or more objections, please raise them. Thanks! Anomie ⚔ 19:21, 29 November 2025 (UTC)[reply]

I’ve replied above. Izno (talk) 19:34, 29 November 2025 (UTC)[reply]

I think that it’s time to move forward with this step, see if edge cases emerge (I suspect that they will), and figure out how to address them. We have fixed the test cases that we know about, as far as I can see. We can always revert if necessary. – Jonesey95 (talk) 01:33, 30 November 2025 (UTC)[reply]

Again there hasn’t been further discussion for 2 weeks. I’m going ahead with this now. Anomie ⚔ 15:43, 13 December 2025 (UTC)[reply]

Just registering my complaint here that I hate the new format change. I cannot get two columns except to reduce the zoom size until I can no longer read the text. I hate single column reference lists. Not sure how any of this serves low-vision readers. ▶ I am Grorp ◀ 18:49, 13 December 2025 (UTC)[reply]

If you’re zoomed in so far that it’s not displaying two columns, then it probably shouldn’t be displaying two columns. But if you can provide details as to your skin, viewport size, effective font size, and so on, I can look into it for you. Anomie ⚔ 19:49, 13 December 2025 (UTC)[reply]

I use “.vector-body {font-size: 115%;}” in my custom CSS for the Vector 2022 skin. With this setting, I have to disable “limited width mode” and expand my viewing window to basically the entire width of my laptop screen (1710 pixels) to get multiple columns. That’s not a huge enough magnification factor for it to reasonably be called “zoomed in so far”. Without the increased font size it does show two columns in the default limited width mode but I don’t like the small font size that produces. I would much rather have settings that allow two columns in the font size I normally use. The example article I was testing this on was prime number. —David Eppstein (talk) 20:42, 13 December 2025 (UTC)[reply]

Thanks and here’s the archived older version for comparison/testing. Rjjⁱⁱⁱ (talk) 21:00, 13 December 2025 (UTC)[reply]

Hmm. Using that archive link and injecting a .vector-body {font-size: 115%;}, I can’t get the “limited width mode” to display two columns. But anyway, you should be able to add something like this in your custom CSS to adjust the columns:

.mw-references-columns { column-width: 24em !important; }

That should override the column width for any <references /> or {{reflist}} that’s using columns at all. You can play with the 24em if you want for best effect. Anomie ⚔ 21:22, 13 December 2025 (UTC)[reply]

That does help; thanks! 24em is good enough; I don’t think I’d want it much narrower than that. Does this also apply to refbegin/refend? Often those specify column widths to try to match the widths in reflist. —David Eppstein (talk) 21:58, 13 December 2025 (UTC)[reply]

No, those are entirely separate. If you want to override them too, you should be able to use similar CSS with .refbegin-columns in place of .mw-references-columns. Also, if people are generally wanting the columns from {{refbegin}} to match {{reflist}}, they’ll probably want to make some updates now. Anomie ⚔ 23:30, 13 December 2025 (UTC)[reply]

Also, any specific articles? (to use to replicate issues) Rjjⁱⁱⁱ (talk) 20:28, 13 December 2025 (UTC)[reply]

@Anomie: I use Vector legacy (2010) skin, a 15″ laptop, display resolution 1920×1080, and system setting “size of text, apps, and other items” at 150% (just one selection above the system’s ‘recommended’ 125% option). Browser zoom is at 100%. Yesterday I was viewing 2 columns for most articles, now everything is single column unless I change browser zoom to 90% (uncomfortably small). One example article is Scientology; at 507 citations, I surely don’t want to see that in single column. On articles with super long citation sections, double columns affords me the ability to see by the very first line that there are hundreds of citations. In this case 1 in the left column, 294 in the right column, means I have to scroll down to around 290 to find the end of the section—easy peasy. Without such an indicator, I have no idea how long the section is, I scroll and scroll and scroll, go cross-eyed, and if scrolling too fast I easily overshoot the next section header. ▶ I am Grorp ◀ 21:19, 13 December 2025 (UTC)[reply]

You might try adding something like this to your User:Grorp/common.css:

.mw-references-columns { column-width: 27em !important; }

If that doesn’t work, try decreasing the 27 to 26 or 25. That should give you two columns in any <references /> or {{reflist}} that’s doing columns at all. Anomie ⚔ 21:31, 13 December 2025 (UTC)[reply]

OMG that works! Thank you! ▶ I am Grorp ◀ 22:27, 13 December 2025 (UTC)[reply]

I’m a bit late to the party with this, but can I say that previously, it was easier to tell if an article was using <references> because the reference text size was large? It doesn’t seem like there’s a difference in text size now between {{reflist}} and <references>, so it’s a little harder to seek out and convert the latter to the former now. I’m not imagining that {{reflist}} has bigger text now, am I?—
Ineffablebookkeeper (talk) ({{ping}} me!) 11:47, 14 December 2025 (UTC)[reply]
- Also – and I don’t know if this is because of this change or not – but starting this past month, I’ve noticed that on mobile view, Wikipedia is eeeever so slightly zoomed in a bit when you first load an article, as if there were a too-large image in it somewhere automatically resizing the page to fit it in. I don’t know if this is as a result of the changes to this template or not, but it’s every article I’ve been on so far.—Ineffablebookkeeper (talk) ({{ping}} me!) 11:56, 14 December 2025 (UTC)[reply]
 
 @Ineffablebookkeeper: Looks like you’re right, on the actual mobile view (not just useskin=minerva), MediaWiki:Common.css is not loaded and therefore <references /> doesn’t get the font-size: 90% from there. {{reflist}} used to do its own font-size: 90%, but no longer does after this change. On the other hand, if phab:T375538 had happened first then mobile would have started loading MediaWiki:Common.css to get the 90% size, and better synchronizing <references /> versus {{reflist}} was the goal of this change anyway. Converting between <references /> and {{reflist}} should ideally be a cosmetic edit in most cases, freeing us to do things like converting {{reflist|refs=...}} to <references>...</references> because the former doesn’t work well in VE, or because {{reflist}} behaves more poorly when PEIS is hit.As for your mobile zoom thing, that has nothing to do with this. Anomie ⚔ 14:50, 14 December 2025 (UTC)[reply]

Both Reflist|30em and Reflist|2 are not working for me, like it’s still same with Reflist. How can I change the fonts’ sizes to previous size using parameters? I also tried Reflist|27em, but it wasn’t working. Camilasdandelions (talk!) 07:18, 15 December 2025 (UTC)[reply]

Must Read

Leave a Comment Cancel Reply