Template talk:Reflist

  1. Home
  2. Wiki

Excess styles

[edit]

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 multiplied by 0.9, 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 /> without changing display of manually-specified widths.
  • 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. Rjjiii (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:
  1. 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.
  2. 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.
  3. I approve of moving on Template:Reflist/styles.css#L-8, if you've done the work to test things.
  4. 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:
  1. 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.
  2. 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.
  3. Tests are in Template:Reflist/testcases, as already noted. Feel free to add more if you have any.
  4. 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]
  1. 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.
  2. 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]
  1. 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).
  2. 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]
  1. 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.
  2. 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:
  1. 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.
  2. 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]
  1. "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:
  1. Synchronize how column sizes are handled. I've already agreed to this as an objective (at least).
  2. 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.)
  3. 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.
  4. 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:
  1. 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.
  2. 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.
  3. 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.
  4. 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]

Comments after the revised version

[edit]

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. Rjjiii (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) Rjjiii (talk) 20:28, 13 December 2025 (UTC)[reply]
@Anomie: I use Vector legacy (2010) skin, a 15" laptop, display resolution 1920x1080, 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]

Font size

[edit]

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 by using parameters? I also tried Reflist|27em, but it wasn't working. Camilasdandelions (talk!) 07:18, 15 December 2025 (UTC)[reply]

You can't change the font size using parameters, and you never could. The arguments you're attempting are for selecting column width. Recent edits did not change the font size, outside of fixing a bug in mobile views. Have you tried the suggestion under Template:Reflist#Customizing the view? Anomie⚔ 13:08, 15 December 2025 (UTC)[reply]
Recent edits did not change the font size, ...: In mobile views, the texts in Reflist became bigger than previous version. Thus I thought the last edit changed the size of the fonts. Camilasdandelions (talk!) 13:18, 15 December 2025 (UTC)[reply]
You cut off the rest of the sentence: ... outside of fixing a bug in mobile views. Anomie⚔ 17:16, 15 December 2025 (UTC)[reply]

reflist template is being systematically removed

[edit]

The bot User:DreamRimmer bot II is doing a mass removal of this template from articles. Is there some discussion/approval for that indicating broad consensus among Wikipedia editors? If not, I would recommend the bot's recent edits be mass reverted pending a wider discussion. The current bot behavior is not explicitly justified anywhere I can see, and seems disruptive. –jacobolus (t) 11:28, 16 December 2025 (UTC)[reply]

The relevant BRFA seems to be Wikipedia:Bots/Requests for approval/DreamRimmer bot II 6, unless you're seeing it remove reflist where it's not using LDR. Mike Christie (talk - contribs - library) 12:15, 16 December 2025 (UTC)[reply]
Replacement of {{reflist|refs=...}} with <references>...</references> is following an RFC at Wikipedia:Village pump (proposals)/Archive 223#Bot to make list-defined references editable with the VisualEditor. See also Wikipedia:Bot requests#c-Anomie-20250903154600-Alenoach-20250903152500, where I predicted exactly this sort of complaint. Anomie⚔ 13:32, 16 December 2025 (UTC)[reply]
The bot just started making mass change, with the edit summary "Standardise list-defined references format" and no link anywhere in sight to a discussion.
The proposal was frankly poorly thought through, poorly written, incompletely discussed, and is being poorly implemented. In particular there is a lack of communication about what is being done and why, and none of the changes is reflected in the 4+ relevant documentation pages across the site.
If you predicted this, it would have been nice if more careful and considered action was taken up front to make less of a mess. –jacobolus (t) 13:50, 16 December 2025 (UTC)[reply]
If that's the edit summary the bot is using, a polite request to the bot op would likely get results without all the melodrama. Regarding the documentation, {{sofixit}}. Anomie⚔ 14:07, 16 December 2025 (UTC)[reply]
I believe I have done my best to explain the task. It felt like comments were being added without fully reading my replies. I was working on something else, but when I received an email about your ping on the bot talk page, I opened my system to respond. I stopped the bot twice and clearly explained the situation each time. If you still feel that I missed something, I apologise. You are welcome to suggest any changes to the process if you feel it is being poorly implemented. – DreamRimmer ■ 15:06, 16 December 2025 (UTC)[reply]
Maybe it would help for the edit summary to link to the RFC?
Anyway, fwiw: this replacement is intended to make little or no visible change to articles but to work around a never-going-to-be-fixed visual editor bug that makes it difficult to edit templates nested inside other templates. List-defined reference citation templates inside the references tag can be edited by VE. List-defined reference citation templates inside a reflist cannot. And they come out looking the same. So we should use the more flexible option. —David Eppstein (talk) 18:49, 16 December 2025 (UTC)[reply]
This question has been resolved, and the bot has resumed this task with a better edit summary.
There is now a follow-on discussion about what our documentation should recommend (<references /> vs. {{reflist}}) outside of the case of list-defined references. See Help talk:Footnotes § Tag or template preference if interested. -- Beland (talk) 05:30, 18 December 2025 (UTC)[reply]

Did the recent change somehow break VE?

[edit]

Using VE, it is no longer possible to click on references in the reflist to edit them (it just brings up the template dialog). I had assumed this was a VE bug, but I've checked other wikis on the same MW version as enwiki (specifically itwiki and eswiki) and they worked fine. I have no idea how it could have broken this, but I figured I'd ask here anyway. And no, this does not have to do with list-defined references, it's for every article using "normal" references with the reflist template, which used to work; just look at Seattle for one example among many. Pinging @Anomie, who made the change. Jay8g [V•T•E] 07:47, 17 December 2025 (UTC)[reply]

WTF VE? Apparently it chokes when {{#tag:references}} isn't wrapped in a div? ... Also, VE seems to get ridiculously confused by Template:Reflist/testcases. Anyway, as far as I can tell Special:Diff/1328019882 fixed it. Anomie⚔ 13:09, 17 December 2025 (UTC)[reply]

Remaining LDR compatibility fixes

[edit]

Since we've been talking about cases of incompatibility between list-defined references and Visual Editor that the bot can't handle, I checked the 2025-12-01 database dump to see how many of these there are.

-- Beland (talk) 18:42, 18 December 2025 (UTC)[reply]

I have fixed some in the list above, which I have struck through. -- Beland (talk) 18:48, 18 December 2025 (UTC)[reply]
What do you consider "empty parameters or malformed syntax"? I see only four pages in Category:Pages using reflist with unknown parameters. – Jonesey95 (talk) 19:49, 18 December 2025 (UTC)[reply]
I see a lot of pages with "refs" but no "=" (this seems to work), "||" or "| |" instead of "|", a few invalid values for "colwidth" (like "2" and "35"), and a handful of invalid unnamed parameter values like "columns", "!", "35", "em30", and "em". -- Beland (talk) 20:25, 18 December 2025 (UTC)[reply]
If anyone wants to help! A lot of the individually-listed articles above just have crazy referencing where the multiple lists can be consolidated into a single normal list. A common problem is that copyright references are separated out from other references to avoid repeating the collection name, but repeating the collection name in each individual reference is the right thing to do for downstream ingestion and reader convenience. -- Beland (talk) 09:35, 19 December 2025 (UTC)[reply]
6,324 cases where the number of columns is being specified. This no longer works, Like {{reflist|2}}? Specifying 2, when the article has >10 refs, is the same as the default behavior (except probably in Minerva, which uses 25em by default but |2 will use 30em). When the article has 10 or fewer, |2 will still do columns where <references /> won't. Specifying 1 is equivalent to <references responsive=0 />. Specifying any other number uses 25em or 22.5em depending on the skin. Anomie⚔ 20:02, 18 December 2025 (UTC)[reply]
Right, there are some effects, I just mean this no longer actually results in the specified number of columns being rendered. So these should probably be replaced regardless of VE compatibility issues, to avoid confusion. I would assume replacing {{reflist|2}} with the default <references /> is OK because having columns when there are fewer than 10 items will look bad on wide screens. -- Beland (talk) 20:29, 18 December 2025 (UTC)[reply]
I'd agree, but some people might complain that they really really want the columns anyway. 😅 Anomie⚔ 20:57, 18 December 2025 (UTC)[reply]
Heh, I mean some people complain if you give them free money. Not a reason not to proceed unless there's a good articulated reason. 8) -- Beland (talk) 23:36, 18 December 2025 (UTC)[reply]
The only complication would be if there are multiple instances on the same page. I don't know if VE would be happy with it, but a {{refwidth-wrap}} template could probably handle that. Also, did you check for articles with {{notelist}} or variants? Anomie⚔ 20:02, 18 December 2025 (UTC)[reply]
I'm not sure what you're proposing for {{refwidth wrap}}? VE cannot adequately handle situations where lists of references are inside of a template.
After I started manually fixing pages, yeah, I realized that we need to fix both instances of {{notelist}} using LDRs on its own, and deal with instances of notelist + reflist on the same page. I did a database grep and will report back after enjoying a bit of time in the great outdoors. -- Beland (talk) 20:19, 18 December 2025 (UTC)[reply]
I should have said {{refwidth begin}}. Sorry. 🙁 The idea being that {{refwidth begin}} would output an unclosed <div class="refwidth-short"> or the like, and the styles would target .refwidth-short .mw-references-columns, so as to keep the different <references /> separate. Anomie⚔ 20:27, 18 December 2025 (UTC)[reply]
I believe that would work if paired with a {{refwidth end}}, though given all the moving parts I'm not 100% certain until seeing a working implementation. 8) -- Beland (talk) 20:31, 18 December 2025 (UTC)[reply]
On the VisualEditor though? {{Refbegin}} and {{refend}} don't work well on VisualEditor. They have the same problems that {{reflist|refs=}} has. Rjjiii (talk) 22:53, 18 December 2025 (UTC)[reply]
Best way to find out is to try it. -- Beland (talk) 00:02, 19 December 2025 (UTC)[reply]
I checked this just using the {{refbegin}} and {{refend}} tags. Those 2 opening and closing templates obscure the references. I also tried just wrapping the references section in arbitrary <div>...</div> tags. The html tags did not obscure the references. It's something about the div coming from the templates. I don't know a way around it, but there are loads of folks here more knowledgeable than I am. Also, if anybody want to see what I am talking about try editing the references section in the two links below using the Visual Editor to see the difference:
Rjjiii (talk) 05:39, 19 December 2025 (UTC)[reply]
These may be overcounts if "refs=" appears with no value but the close braces are not on the same line. When I say {{notelist}} below, I'm including all the notelist-XXX variants.
  • I find 166 articles that use {{notelist}} more than once, with at least one having LDRs. This happens a lot for notes at the bottom of a table. (This seems like a place where having multiple columns is not a good idea.)
  • I find 542 articles that use both {{notelist}} and {{reflist}} with LDRs for at least one instance of each template.
  • This is out of at most 4,049 articles that use {{notelist}} with LDRs and 144,552 articles that use {{reflist}} with LDRs.
-- Beland (talk) 04:50, 19 December 2025 (UTC)[reply]