Template talk:Reflist/Archive 33

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

How is 4,590,000 pages 9% of articles? Surely it should be much more? Eddie891 ^Talk _Work 15:22, 21 August 2019 (UTC)

It actually says "9% of all pages". The number of pages is 60,585,330, while the number of articles is 6,819,538. This template is in use on around 78% of all articles. HTH --RexxS (talk) 16:30, 21 August 2019 (UTC)

RexxS, ah, that makes sense! Sorry to trouble you, and thanks very much. Eddie891 ^Talk _Work 19:04, 21 August 2019 (UTC)

What determines how references are numbered? I'm used to them being numbered in order of when they're cited in the article. But, looking at Electronic cigarette, The first reference is 77, the next is 3, then comes 78, etc. What's the magic here? -- RoySmith (talk) 00:38, 27 September 2019 (UTC)

A bunch of references are in note 1.

—Trappist the monk (talk) 00:46, 27 September 2019 (UTC)

Dooh! Thanks for spotting that. -- RoySmith (talk) 00:52, 27 September 2019 (UTC)

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Please amend the protection of this template so that template editors can edit it (like, e.g. {{infobox}}). ―Justin (koavf)❤T☮C☺M☯ 22:01, 26 October 2019 (UTC)

 Not done: Given it's extremely high usage here (unlike template:infobox) this template shouldn't ever need to be edited, If you've spotted an error let someone know. –Davey2010^Talk 22:57, 26 October 2019 (UTC)

@Koavf: Also, requests for decreases to the page protection level should be directed to the protecting admin or to Wikipedia:Requests for page protection if the protecting admin is not active or has declined the request. --Redrose64 🌹 (talk) 13:58, 27 October 2019 (UTC)

Redrose64, Contacting the protecting admin isn't needed for templates and he hasn't edited here in a year. I've posted to the page you suggested, thanks. ―Justin (koavf)❤T☮C☺M☯ 17:45, 27 October 2019 (UTC)

@Koavf: Although I'd bet that the 90% of template editors are more comfortable editing templates than 90% of admins, there is a principle of "minimum exposure" for editing of very highly used templates. I sympathise, because I've often felt frustrated in the past when the protection level of a template prevented me from editing it (usually I ended up working in the sandbox and requesting the update when finished). Nevertheless, this template hasn't needed to be edited in over two years, so it's unlikely its protection level will be downgraded. Let me make you an offer: if you need to edit this template, just make an edit request – it's on my watchlist – and I'll do my best to fulfil the request for you, if practical. --RexxS (talk) 19:08, 27 October 2019 (UTC)

RexxS, That's very thoughtful of you. Thanks. ―Justin (koavf)❤T☮C☺M☯ 19:10, 27 October 2019 (UTC)

@Koavf: In Wikipedia:Protection policy, I can't find the part that says that contacting the protecting admin isn't needed for templates - please direct me to the relevant section. --Redrose64 🌹 (talk) 21:58, 27 October 2019 (UTC)

Redrose64, In the page you directed me to: Wikipedia:Requests for page protection, you can see: "Requests to downgrade full protection to template protection on templates and modules can be directed straight here; you do not need to ask the protecting admin first." ―Justin (koavf)❤T☮C☺M☯ 22:04, 27 October 2019 (UTC)

An editor has asked for a discussion to address the redirect

Example starts here

This:

Without colon:

Before div
<div style="background-color: #F3FFF9;">
Inside div.<ref group=test>Book</ref>  More inside div.  References coming up.
{{reflist|group=test}}
Still inside div.
</div>
After div.

With colon:

Before div
<div style="background-color: #F3FFF9;">
Inside div.<ref group=test>Book</ref>  More inside div.  References coming up.
:{{reflist|group=test}}
Still inside div.
</div>
After div.

renders as

Without colon:

Before div

After div.

With colon:

Before div

<div style="background-color: #F3FFF9;"><!--Do not fix this stripped-tag/missing end </div> tag error. Key to conversation here.-->
Inside div.<ref group=test>Book</ref>  More inside div.  References coming up.
:{{reflist|group=test}}
Still inside div.
</div>

After div.

Which renders in HTML as

1  <p><br />
2  renders as
3  </p><p><br />
4  Without colon:
5  </p><p>Before div
6  </p>
7  <div style="background-color: #F3FFF9;">
8  <p>Inside div.<sup id="cite_ref-1" class="reference"><a href="#cite_note-1">[test 1]</a></sup>  More inside div.  References coming up.
9  </p>
10 <div class="reflist" style="list-style-type: decimal;">
11 <div class="mw-references-wrap"><ol class="references">
12 <li id="cite_note-1"><span class="mw-cite-backlink"><b><a href="#cite_ref-1">^</a></b></span> <span class="reference-text">Book</span>
13 </li>
14 </ol></div></div>
15 <p>Still inside div.
16 </p>
17 </div>
18 <p>After div.
19 </p><p>With colon:
20 </p><p>Before div
21 </p>
22 <div style="background-color: #F3FFF9;">
23 <p>Inside div.<sup id="cite_ref-2" class="reference"><a href="#cite_note-2">[test 1]</a></sup>  More inside div.  References coming up.
24 </p>
25 <dl><dd><div class="reflist" style="list-style-type: decimal;"></div></dd></dl>
26 <div class="mw-references-wrap"><ol class="references">
27 <li id="cite_note-2"><span class="mw-cite-backlink"><b><a href="#cite_ref-2">^</a></b></span> <span class="reference-text">Book</span>
28 </li>
29 </ol></div></div>
30 <p>Still inside div.
31 </p>
32 
33 <p>After div.
34 </p><p><br />

Lines 1-18 are without a colon, lines 19-34 are with a colon.

Example ends here

Discussion

For the correct, non-indented example, the div in line 7 isn't closed until line 17. Inside is is another div that starts on line 10 and ends at the end of line 14. Inside that is yet another div that starts on line 11 and ends earlier on line 14.

For the indented example, the 'div on line 22 is closed immediately on line 25. It is closed BEFORE the <dl><dd> that encloses the entire line is closed. At the very least this is bad form if not an outright error.

The bug is that he closing /div on line 25 should be moved to line 32.

The workaround is to not indent references in any place where you might be surrounded by a div. davidwr/(talk)/(contribs) 21:34, 27 February 2020 (UTC)

I added a "limitations" section, but its contents should probably be moved to the documentation for <references /> with a link here.

There is a bug (example here) that makes references not work right if they are in lists under certain circumstances. It needed to be documented.

This bug tends to rear its ugly head if a block of WikiCode that contains something like

:<references />

or

:{{reflist talk}}

is later surrounded by {{

This example does NOT use :, *, or #. It is what things should look like:

<div style="background-color: #F3F9FF;">
Discussion with footnote<ref group=test>Doe, John, ''Example book''</ref>
:<references group=test />
More discussion here.
</div>

renders incorrectly as

More discussion here.

but if you remove the colon before <references /> it renders correctly as

davidwr/(talk)/(contribs) 18:13, 27 February 2020 (UTC)

But the bug demonstrably doesn't apply to {{reflist}}:

<div style="background-color: #F3FFF9;">
Discussion with footnote<ref group=test>Doe, John, ''Example book''</ref>
:{{reflist|group=test}}
More discussion here.
</div>

--RexxS (talk) 18:54, 27 February 2020 (UTC)

(edit conflict) It doesn't quite render as intended, just not brokenly. If you use 10 colons and group=lower-alpha, you'd expect the reflist to be indented significantly and using "a" rather than "1" for the ref, but you'd get unindented output with "1". The problem here is that wikitext list markup is line-based (see also phab:T230683), and the line is considered after expanding templates and converting <references/> into a bunch of wikitext. For <references/> it winds up with the "line" being <div class="mw-references-wrap"><ol class="references">, and when the resulting tag soup is fixed the <li>s wind up outside of the <ol> so they wind up being rendered oddly. For {{reflist}} the "line" is just the <div class="reflist" style="list-style-type: decimal;">, which again gets separated from what it's supposed to contain but all that's lost are the styles applied by that div. Anomie⚔ 20:22, 27 February 2020 (UTC)

@Anomie: and @RexxS: - the loss of the styles applied by div is the problem. An example is here which I fixed on the subsequent edit. davidwr/(talk)/(contribs) 20:55, 27 February 2020 (UTC)

@Davidwr: The problem there is actually slightly different, but related. The colon screwing up the <div class="reflist" style="list-style-type: decimal;"> leads to the </div> that was intended to close that div instead closing an enclosing div. Any other template that generates a <div>...</div> with newlines inside would do the same thing in the situation. Anomie⚔ 22:34, 27 February 2020 (UTC)

I'm pretty sure it used to be the case that {{reflist|refs=...}}, when editing and previewing the references section, would format and display the references in the previous window, even though they are unused within that section. In the past few weeks, that has stopped happening, making it difficult to edit references sections formatted in this way. The template itself hasn't changed in years. Anyone have an idea how this might have changed and how to get the preview of references back again? —David Eppstein (talk) 23:15, 16 February 2020 (UTC)

WMDE has been working on Extension:Cite code recently. They may have broken reference previews in a different section functionality. I'd recommend going straight to Phabricator. --Izno (talk) 23:24, 16 February 2020 (UTC)

https://phabricator.wikimedia.org/T245376 —David Eppstein (talk) 23:35, 16 February 2020 (UTC)

Thanks for filing that report, David. I too miss this very useful functionality and was wondering what happened. BTW, I use Vector skin.

--Matthiaspaul (talk) 02:39, 28 March 2020 (UTC)

Until this get's fixed, there's kind of a "workaround" by temporarily removing the first "{" of {{reflist}} in edit preview in order to "disable" the template, so that the embedded list of references will be shown again. You just need to remember to restore the "{" before saving the improved references.

--Matthiaspaul (talk) 03:06, 28 March 2020 (UTC)

David, I meanwhile ran some tests: The normal "Preview of references" in section preview still seems to work fine for all references defined outside of a {{reflist}} template. Even references defined only in preview like

{{If preview|<ref name="Test">Test</ref>}}

are still displayed correctly in preview. As far as I see it, the problem exists "only" for references defined as

{{reflist|refs=<ref name="Test">Test</ref>}}

but not invoked in the previewed section.

Now, knowing that it is possible to define a named reference twice without error message if the contents is exactly the same, I tried to work around the problem by prefixing the code of a sandboxed version of {{reflist}} with

{{If preview|{{{refs|}}}}}

to emulate the invocation of all references defined in {{reflist}}. This will produce anchors like [1]..., but still the definitions won't show. I then tried something like this

{{((}}If preview{{!}}{{{refs|}}}{{))}}

hoping to delay the evaluation of the {{If preview}} template until into the preview of the target article (rather than that of the sandboxed {{reflist}} template), this triggered the references to occur, but left something like this visible on the screen as well:

{{If preview|[1]...}}

So, nothing really new and still no fix, but perhaps this helps someone else to further narrow down the problem.

--Matthiaspaul (talk) 08:12, 10 May 2020 (UTC)

• Shamelessly hijacking this thread for one of my favorite hobbyhorses... when will someone take the bull by the horns and make it so list-defined refs are our put in the order they appear in the list, instead of random order? Being able to control the order (e.g. alpha order) world be such a step forward. EEng 13:51, 10 May 2020 (UTC)

Yes, it could be useful to have these options for selection as {{reflist}} parameter |order=:

• "Author-ascending": Alpha-order of author "last, first" name in ascending order
• "Date-ascending": Numerical order of date (as per "yyyy-mm-dd") in ascending order
• "Date-descending": Numerical order of date (as per "yyyy-mm-dd") in decreasing order
• "Invocation" (default): order of invocation in article
• "User-defined": user-defined ascendng order per special numerical argument of |order= parameter in {{
  refs
  }}, refs without |order= would be appended at the end per "invocation" order.
• "Natural": unsorted as per occurence in {{reflist}}.

--Matthiaspaul (talk) 16:05, 10 May 2020 (UTC)

NO NO NO NO NO NO NO NO NO NO NO. No automatic sorting. Too complicated. Too many design issues and edge cases -- in fact reflist doesn't even understand the text it outputs, which reflist would therefore have to parse somehow in order to do what you're suggesting. Simply make what you're calling "Natural" the default; people can put stuff in the right order themselves. After that if people want to spend years designing and arguing about the rest, that's fine with me. But first just do "natural". And you don't need any syntax change or interface design for that -- since now that output is essentially random, changing it to the most natural (as you call it) order isn't really changing anything.

There is one design question that comes to mind, which is what to do with refs that are defined outside the refs= list i.e. in the article itself. My suggestion would be to have those come out first, in the usual "random" order, followed by the list-defined refs. That way they stick out like a sore thumb. EEng 20:01, 10 May 2020 (UTC)

Some kind of parameter would be needed anyway, as the default ("invocation order") would still be needed - "natural" could result in an undesirable sorting order, if not all reference definitions are located inside {{reflist}}, or if references defined in templates are transcluded into an article thereby disturbing a previously set up natural order.

Either way, before any of this gets addressed, the originally reported problem should be fixed.

--Matthiaspaul (talk) 20:38, 10 May 2020 (UTC)

I already addressed how to handle refs outside the refs= list and no, "natural" cannot result in anything undesirable: since what we have now is an undef:ined order, imposing any particular order can't be "wrong". Refs pulled in via transclusion is, I'll admit, a case I hadn't considered, but I'm skeptical of how often that happens. EEng 20:47, 10 May 2020 (UTC)

Not often, but it happens. Many of the various COVID-19 articles are a recent example of this.

The order at present isn't "undefined", it resembles the order in which the references are invoked in an article (counting those [n] numbers up). In many cases, this order is quite desirable, but sometimes other orders would be more suitable. I think, it really depends on the article.

--Matthiaspaul (talk) 21:08, 10 May 2020 (UTC)

The fact that refs are currently output according to when they're first invoked is well known to experienced editors, but I challenge you...

• ... to find Mediawiki documentation calling that a feature rather than just an accident which has never been changed (because no one knows what to change it to); and
• ... to exhibit an article in which this fragile order is "quite desirable", or somewhat desirable, or even at all desirable.

EEng 21:28, 10 May 2020 (UTC)

It's not a peculiarity of Mediawiki, many journal articles use this order as well. It is a "desirable" default because it ensures that the anchors will[1] be[2] counted[3] up[4]... (at least unless a reference is invoked more[5][1] than[4][1][3] once[2]...)

If you would always enforce the order used in {{reflist}} (say, according to "author name, ascending" in this example), but the article would not discuss the authors in alphabetical order,[4] the[2] anchor numbers[3] could[1] look[5] like this - many users find that undesirable. So, it must be configurable.

--Matthiaspaul (talk) 06:42, 11 May 2020 (UTC)

I didn't say it was peculiar to Mediawiki, I challenged you to show me that it's considered a documented "feature" that needs to be preserved (at least on enwp); anyone familiar with parsers or compilers knows instantly that it is (or at least was at first) a programming accident. Anyway, the analogy to (traditionally) print journals is spurious. In the the kinds of paper which use the number-in-order-of-appearance style, it's very seldom that any one source is used more than once; in our articles, there are usually at least a few sources that are used several to many times, so that the sequence that begins neatly with 1 2 3 soon deteriorates into 13 14 3 15 8 16 17 2 9 3 18 9 5 anyway. There's already no way to control this and I've never seen anyone complain about this in the slightest, and in fact because of the confusion it creates most editors (other than those fairly experienced) don't even realize how the numbers get assigned in the first place -- to the casual eye they appear random. What people do complain about is being unable to control the order in which the cites are listed. EEng 22:41, 11 May 2020 (UTC)

I wonder why you would want to "challenge" me for giving support for your feature request. I'm basically on your side, I just don't agree with that something like this should be enforced without any option to override. Instead, it should be a configurable option, so that the best order can be decided upon on an article-by-article basis. Valid rational reasons can be found for more than one possible order. What should be the default is the matter of a different discussion. To get the highest acceptance of the feature, and thereby of list-defined citations in general, it should be possible to integrate them into the existing ecosystem of how to define references without changes to the output first.

Just for the records, I am quite familiar with parsers and compilers. --Matthiaspaul (talk) 09:58, 12 May 2020 (UTC)

The documentation for this template says that an option to make the list scrollable is a perennial suggestion that seems like it couldn't work for technical reasons that'd make it incompatible with accessibility needs. The links all go to discussions from 2010 or prior, though, and the archives here and at VPT seem to be the same (perhaps the search function is just failing me, but I can't find anything recent). Have there been any advances in MediaWiki or CSS over the past decade that might make this feature more feasible? It'd be really nice to have for articles like COVID-19 pandemic, where the reference list currently takes up nearly half the scroll length of the page, making it seem longer than it actually is (which is discouraging to readers). I also noticed that some other Wikipedias, such as Vietnamese here, have found a way to do this. {{u|Sdkb}} ^talk 08:29, 10 May 2020 (UTC)

No, no changes. COVID-19 has issues that have been discussed elsewhere e.g. WT:Templates. --Izno (talk) 15:13, 10 May 2020 (UTC)

@Sdkb: You mean you want something like:

It's a bit of a pain to manage if you're not using a mouse. Is there any real advantage in doing that (other than fooling readers in thinking the page needs less scrolling than it actually does, of course)? --RexxS (talk) 19:50, 10 May 2020 (UTC)

@RexxS: Yeah, something like that. Since no reader is going to want to "read" through the reference list the same as they would the actual article, I wouldn't see it as "fooling" them so much as helping them. The longer a page looks via the scrollbar, the less likely readers are to actually decide to read it. {{u|Sdkb}} ^talk 03:21, 11 May 2020 (UTC)

"no reader is going to want to 'read' through the reference list" – maybe you don't; I occasionally do. -- Michael Bednarek (talk) 05:47, 11 May 2020 (UTC)

Yes. In fact a quick scan of the reflist is a key to evaluation of an articles quality and dependability. EEng 06:12, 11 May 2020 (UTC)

• Annoying and pointless. First I have to scroll to the scroll box, then I have to scroll within it. Yuk. And I'm highly skeptical of this concept of scrollbar-prompted-article-bailout. EEng 04:29, 11 May 2020 (UTC)

  In isolation on a talk page here, I can see how it comes off that way a bit. Take a look at how it works on the Vietnamese Wikipedia, though; it feels pretty natural there, and doesn't seem to introduce any issues with mobile or the inline citations or anything like that. {{u|Sdkb}} ^talk 08:32, 13 May 2020 (UTC)

  I must admit it looks good -- on my laptop, with a full window. But on mobile, and on my laptop if the window is made vertically smaller, you get the worst of the worst: the scroll box is taller than the window, which (a) looks awful and (b) means I have scroll the window up and down to find the part of the scroll box that has the "thumb" (see Scrollbar#Thumb_dragging) and then grab the thumb and pull it up or down. In doing that you sometimes have to let go of the thumb and scroll the main window up or down more ... oh, it's awful. I actually think the basic idea has merit but not like this. At the very least the scroll box has to adjust itself automatically according to the size of the surrounding window. EEng 01:15, 15 May 2020 (UTC)

  Touch interfaces have problems in particular with nested scrolling in the same direction (so a vertical scroll inside a vertical scroll).

  It is so hard to interpret the user intent here (which surface do you want to scroll?), that initially on Android it wasn't even possible/allowed to have same direction scrolling inside same direction scrolling. Only since 2014 has that been available to the majority of Android users. But still, if the nested scrollarea viewport is more than 80% of the parent area, it is really hard (on all mobile OS'es) to 'select' which surface you want to scroll as there is such limited screen real estate of the parent to grab and initiate the scroll from.

  So yeah it should be avoided when possible, especially for vertical inside vertical. horizontal inside vertical isn't as bad, that just messes with your reading, not so much with your ability to use the browser. —TheDJ (talk • contribs) 09:53, 15 May 2020 (UTC)

  oh and iOS in particular provides no visual cue that an area is a nested scrollable. You can only find out by experimenting with touch, which is bad for discovery. —TheDJ (talk • contribs) 09:56, 15 May 2020 (UTC)

  Can we make not happen on mobile (not that that would fix all problems -- I'd still want the inside window to adjust its height so as to fit vertically inside whatever outside window was present)? EEng 21:56, 15 May 2020 (UTC)

• The reflist at COVID-19 pandemic is indeed overwhelming, but I don't think that's the case with most articles. This definitely should not be an option in the template itself, as I don't think forcing a scrollable list on all viewers of an article would go over well. If anything, this idea sounds like a potential gadget that users can test and/or add to their own profiles based on their viewing/navigation preferences, maybe with the option to set the number of citations after which they want the list to change.— TAnthony^Talk 06:08, 11 May 2020 (UTC)
• Cue someone to point out that this won't work well on mobile. There's been a real fad recently for fixing things that aren't broken. EEng 06:13, 11 May 2020 (UTC)
  • I did check it on my mobile before I posted. It works, but it feels a bit odd.
    And what do you mean "recently"? --RexxS (talk) 17:24, 11 May 2020 (UTC)

    Starting around the time I graduated high school. EEng 01:33, 15 May 2020 (UTC)

    What a coincidence. I thought the same (except I left secondary school in 1969). --RexxS (talk) 21:30, 15 May 2020 (UTC)

Previously, the {{reflist}} template took a single parameter: a number of columns. Now I see the template is more advanced, but it seems the old behavior “broke”; for example, if I put {{reflist|2}} then I get 3 columns instead of the desired 2. Indeed, I tried with several numbers, and {{reflist}} and {{reflist|1}} produce 1 column spanning the whole page, that is to say, a non-columnar format; and larger numbers produce three columns. How do I produce exactly two columns of references? Bwrs (talk) 22:11, 5 June 2020 (EDT)

You cannot any longer (for good reason). The numbers were retained as rough equivalents to certain column sizes. --Izno (talk) 02:23, 6 June 2020 (UTC)

Template:Reflist#Columns. – Jonesey95 (talk) 04:18, 6 June 2020 (UTC)

@Izno: Yes you can. You set |colwidth=some-value and set your window width to twice that, --RexxS (talk) 19:19, 6 June 2020 (UTC)

I use Timeless. I'm pretty much confined to 2 columns on a good day. --Izno (talk) 20:55, 6 June 2020 (UTC)

I'm pretty sure it used to be the case that {{reflist|refs=...}}, when editing and previewing the references section, would format and display the references in the previous window, even though they are unused within that section. In the past few weeks, that has stopped happening, making it difficult to edit references sections formatted in this way. The template itself hasn't changed in years. Anyone have an idea how this might have changed and how to get the preview of references back again? —David Eppstein (talk) 23:15, 16 February 2020 (UTC)

WMDE has been working on Extension:Cite code recently. They may have broken reference previews in a different section functionality. I'd recommend going straight to Phabricator. --Izno (talk) 23:24, 16 February 2020 (UTC)

https://phabricator.wikimedia.org/T245376 —David Eppstein (talk) 23:35, 16 February 2020 (UTC)

Thanks for filing that report, David. I too miss this very useful functionality and was wondering what happened. BTW, I use Vector skin.

--Matthiaspaul (talk) 02:39, 28 March 2020 (UTC)

Until this get's fixed, there's kind of a "workaround" by temporarily removing the first "{" of {{reflist}} in edit preview in order to "disable" the template, so that the embedded list of references will be shown again. You just need to remember to restore the "{" before saving the improved references.

--Matthiaspaul (talk) 03:06, 28 March 2020 (UTC)

David, I meanwhile ran some tests: The normal "Preview of references" in section preview still seems to work fine for all references defined outside of a {{reflist}} template. Even references defined only in preview like

{{If preview|<ref name="Test">Test</ref>}}

are still displayed correctly in preview. As far as I see it, the problem exists "only" for references defined as

{{reflist|refs=<ref name="Test">Test</ref>}}

but not invoked in the previewed section.

Now, knowing that it is possible to define a named reference twice without error message if the contents is exactly the same, I tried to work around the problem by prefixing the code of a sandboxed version of {{reflist}} with

{{If preview|{{{refs|}}}}}

to emulate the invocation of all references defined in {{reflist}}. This will produce anchors like [1]..., but still the definitions won't show. I then tried something like this

{{((}}If preview{{!}}{{{refs|}}}{{))}}

hoping to delay the evaluation of the {{If preview}} template until into the preview of the target article (rather than that of the sandboxed {{reflist}} template), this triggered the references to occur, but left something like this visible on the screen as well:

{{If preview|[1]...}}

So, nothing really new and still no fix, but perhaps this helps someone else to further narrow down the problem.

--Matthiaspaul (talk) 08:12, 10 May 2020 (UTC)

The Phabricator task has been sitting untouched since May. It's currently in a backlog of 160+ tickets concerning citation issues. --RexxS (talk) 16:36, 14 July 2020 (UTC)

Something is moving... (Thanks, Thiemo. ;-)) I can't wait until the fix will be rolled out... --Matthiaspaul (talk) 22:16, 24 July 2020 (UTC)

While the ticket still shows a status of "open", the feature now works again. Thanks a lot, Thiemo, for the great work.

--Matthiaspaul (talk) 19:45, 7 August 2020 (UTC)

Is there a parameter on the reflist tag to display unused (orphaned) references when using LDR? It would be very useful for a lot of purposes. ImTheIP (talk) 09:11, 24 September 2020 (UTC)

Unused LDR references display an error. --Izno (talk) 14:06, 24 September 2020 (UTC)

Ran into a weird thing: Use of this template and its derivatives (e.g. {{Notelist}}) causes and extraneous </div> to be generated under some circumstances. The one I can nail down is when it is indented (as might happen with {{Notelist}} on a talk page) with : (<dd>) markup. This will cause breakage of any surrounding <div>...</div>, such as a page-wide font style, which is common on user talk pages. See these sandbox tests:

1. Looks good with notelist https://en.wikipedia.org/w/index.php?title=User:SMcCandlish/sandbox22&oldid=997499381
2. Breaks when indented: https://en.wikipedia.org/w/index.php?title=User:SMcCandlish/sandbox22&direction=next&oldid=997499381
3. Still broken with reflist, even without any refs to generate: https://en.wikipedia.org/w/index.php?title=User:SMcCandlish/sandbox22&direction=next&oldid=997499471
4. Still broken with reflist, with refs to generate: https://en.wikipedia.org/w/index.php?title=User:SMcCandlish/sandbox22&direction=next&oldid=997499534

This is obviously a MW parsing problem, but I wonder if there's a simple workaround for it?  — SMcCandlish ☏ ¢ 😼  20:34, 31 December 2020 (UTC)

This is phab:T11996. --Izno (talk) 22:32, 31 December 2020 (UTC)

As for a workaround, I see 0 reason to have a notelist/reflist inline with whatever is being said. Put it on its own line at the end of the section. --Izno (talk) 22:33, 31 December 2020 (UTC)

Do not use a colon to indent a reflist or notelist template, or anything else on an article page, really. See

MOS:INDENT. If you see a colon before reflist or notelist, remove the colon. – Jonesey95 (talk

) 05:09, 1 January 2021 (UTC)

On talk pages, {{reflist-talk}} is helpful. —David Eppstein (talk) 06:58, 1 January 2021 (UTC)

I just noticed that on my computer at work footnotes no longer appear in columns. Did something change? (I looked thru the archives here, but found no recent discussion.) Or is it something to do with my browser (Chrome Version 87.0.4280.88 (Official Build) (64-bit) for Windows, managed by my worksite)? So any computers, so little time to keep up with all of the changes... -- llywrch (talk) 17:40, 15 December 2020 (UTC)

@Llywrch: It is dependent on viewport size and the specific page's column width. What page were you looking at and at what resolution were you viewing the site? --Izno (talk) 17:43, 15 December 2020 (UTC)

Also, per the documentation, a single-column list will be generated if there are fewer than 10 references in the list. – Jonesey95 (talk) 17:54, 15 December 2020 (UTC)

@

Cluvia (gens); when it did not act as expected, I RTFM'ed Template:Reflist. My edits conformed to the examples (although I did find myself lost in all of the explaining of how columns worked), so I opened Ebola virus disease (02:02, 12 January 2018), only to find that had a single column. Since documentation does not always keep up with reality when it comes to technology, I searched the archives here for an answer. (I figured the answer would either be "Yes, support was dropped see this discussion" or "It's working for me, the problem must be with your browser.")

Okay, now I see columns at "Cluvia gens" (explainable by a lag in the Wiki updating the page change -- I've seen that before), but I am still puzzled that the example didn't show multiple columns. -- llywrch (talk

) 18:28, 15 December 2020 (UTC)

@Llywrch: Column support isn't one of the things likely to be dropped, seeing as we've long-ignored the fact that IE doesn't support them in order to have them. :^)

I am not entirely sure why columns did not display for you. Sometimes I've had it happen that I have been resizing my browser window and the browser struggles to keep up. Something like that might be all that happened. --Izno (talk) 18:57, 15 December 2020 (UTC)

Okay, this one wasn't my fault in any way, shape or form. No changes were made to this template or its dependencies before January 8, 2021. I suspect Chrome was broken in version 87. I know that Chrome is reworking their columns support so you may have been subjugated to a change there. I cannot reproduce an issue today in Chrome 88 64-bit for Win 10. --Izno (talk) 04:51, 3 March 2021 (UTC)

Hi, have a problem that reflist is not producing columns on ipad 11" safari desktop version on desktop view at 100% page display. However it does display the columns when 30em is added. Today i've changed the display to 85% and the reflist does work at that size but still not at 100% page size, please advise, regards Atlantic306 (talk) 00:23, 27 December 2020 (UTC)

Please link to a page where this is happening. – Jonesey95 (talk) 14:43, 27 December 2020 (UTC)

Please also provide the version of Safari and your native resolution. --Izno (talk) 20:22, 27 December 2020 (UTC)

Hi, it's happening on all pages without the em parameter, high profile examples include New York City, Donald Trump and Spain regards Atlantic306 (talk) 03:09, 28 December 2020 (UTC)

The safari version is for OS 14.3 and the resolution is about 114hz, regards Atlantic306 (talk) 03:13, 28 December 2020 (UTC)

Resolution is measured in pixels, not in "hz" (most typically in context the screen update rate instead). --Izno (talk) 07:00, 28 December 2020 (UTC)

hi, it's 2388 x 1668 pixels Atlantic306 (talk) 00:11, 29 December 2020 (UTC)

I have no idea why this one is happening. I'm reading about how em widths work today because it's the only thing that makes sense to me as to what's causing your issue here, but even that doesn't make sense to me.

• The core implementation of <references responsive/> sets the column width of 30em on the div including the ordered list. This div isn't produced without responsive enabled.
• We wrap that div/ol with our own. (See structure below.)
• MediaWiki:Common.css sets the font size of our div to 90% and sets the font size of the generated ordered list to 100%.
• An em is a unit of size that is based on the parent element's font-size.

Structure of "default" columns:

<div class="reflist">                  <!-- 90% -->
  <div class="mw-references-columns">  <!-- 30em columns (of 90% == 27em width) -->
    <ol class="references"></ol>       <!-- 100% of 90% -->
  </div>
</div>

Structure when you set the widths locally:

<div class="reflist">                  <!-- 90%, 30em columns (of 100% sizing most likely == 30em width) -->
  <ol class="references"></ol>         <!-- 100% of 90% -->
</div>

Note the ems should be getting their widths from the parents, which means that theoretically the width of the auto-columns version should be smaller, not larger, and thus more able to display. That's where I'm at today... This issue is definitely unrelated to the below.

Another direction with this one could be that a recent version of Safari is broken in its column rendering in some way. I guess another possibility is that the desktop improvement work has been futzing with font sizes or something much further up the stack. --Izno (talk) 08:17, 3 March 2021 (UTC)

There are a few related threads above but the change that broke them is very new. I recently noticed that {{refbegin}}/{{reflist}} deprecated column number form stopped working, so have updated my user page to use explicit em, that worked: Special:Diff/997616208. But this recently also broke. Another example where I just noticed it is at Sidney Powell that specifies 30em but where a single column remains, even if I increase the browser window size to 1920px (normally at its ~1024px size that allows to have decent paragraph width and multiple windows, 30em would still produce two columns). In case it matters, while I use a recent browser with good CSS support, Javascript is completely disabled on purpose. Thanks, —PaleoNeonate – 06:02, 14 January 2021 (UTC)

Izno, it appears from this post and those above that the changes to this template and to {{refbegin}} on 7 January may have had unintended consequences in some edge cases. You may want to revert those changes or work to gather more information about them in order to resolve this apparent regression. – Jonesey95 (talk) 16:40, 14 January 2021 (UTC)

@Jonesey95 and Izno: I think it would be more useful to understand why PaleoNeonate only sees one column when I see four columns at 1920px window size, regardless of whether I am logged in or not, or which skin I set, or which of half-a-dozen browsers I use to display the page, or whether I have JavaScript enabled or not, or whether I'm using a Win10 PC or a Linux box. I simply can't reproduce the behaviour. Can you test some options and check how many columns you see? --RexxS (talk) 18:46, 14 January 2021 (UTC)

Thanks, I'm a bit AFK this week so it's hard to look into things. I'll look sometime soon. --Izno (talk) 18:50, 14 January 2021 (UTC)

@PaleoNeonate: Do you still see one column at Sidney Powell if you are logged out, or if you use a different browser? --RexxS (talk) 18:48, 14 January 2021 (UTC)

I'm unfortunately unlikely to test with other browsers in the short term, but they still display as one entry per line when logged out. In case it was due to new UA-specific code, I tried advertizing another User-Agent as part of the HTTP request, but with the same results. Thanks, —PaleoNeonate – 12:11, 15 January 2021 (UTC)

<h2><span class="mw-headline" id="References"><span class="mw-headline-number">6</span> References</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/w/index.php?title=Sidney_Powell&action=edit&section=16" title="Edit section: References">edit</a><span class="mw-editsection-bracket">]</span></span></h2>
<div class="reflist columns references-column-width" style="column-width: 30em; list-style-type: decimal;">
<ol class="references">
<li id="cite_note-1"><span class="mw-cite-backlink"><b><a href="#cite_ref-1">^</a></b></span> <span class="reference-text"><link rel="mw-deduplicated-inline-style" href="mw-data:TemplateStyles:r999302996"/><cite class="citation web cs1"><a rel="nofollow" class="external text" href="http://worldcat.org/identities/lccn-n96002132">"Powell, Sidney K."</a> <a rel="nofollow" class="external text" href="https://web.archive.org/web/20201120033535/http://worldcat.org/identities/lccn-n96002132/">Archived</a> from the original on November 20, 2020<span class="reference-accessdate">. Retrieved <span class="nowrap">November 16,</span> 2020</span>.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=Powell%2C+Sidney+K.&rft_id=http%3A%2F%2Fworldcat.org%2Fidentities%2Flccn-n96002132&rfr_id=info%3Asid%2Fen.wikipedia.org%3ASidney+Powell" class="Z3988"></span></span>
</li>

The above-generated HTML does show "column-width: 30em;" as part of the CSS style, so I'm not sure what's up yet. I might have an archived page somewhere that I could compare it to eventually... —PaleoNeonate – 12:22, 15 January 2021 (UTC)

Adding: I see two columns at 1024px (and 4 at 1920px) widths with the default {{reflist}} template (no parameter supplied). HTML output:

<h2><span class="mw-headline" id="References"><span class="mw-headline-number">6</span> References</span></h2>
<div class="reflist" style="list-style-type: decimal;">
<div class="mw-references-wrap mw-references-columns"><ol class="references">
<li id="cite_note-1"><span class="mw-cite-backlink"><b><a href="#cite_ref-1">^</a></b></span> <span class="reference-text"><link rel="mw-deduplicated-inline-style" href="mw-data:TemplateStyles:r999302996"/><cite class="citation web cs1"><a rel="nofollow" class="external text" href="http://worldcat.org/identities/lccn-n96002132">"Powell, Sidney K."</a> <a rel="nofollow" class="external text" href="https://web.archive.org/web/20201120033535/http://worldcat.org/identities/lccn-n96002132/">Archived</a> from the original on November 20, 2020<span class="reference-accessdate">. Retrieved <span class="nowrap">November 16,</span> 2020</span>.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=Powell%2C+Sidney+K.&rft_id=http%3A%2F%2Fworldcat.org%2Fidentities%2Flccn-n96002132&rfr_id=info%3Asid%2Fen.wikipedia.org%3ASidney+Powell" class="Z3988"></span></span>
</li>

—PaleoNeonate – 14:57, 15 January 2021 (UTC)

Interesting. The main difference that I see between {{reflist}} and {{reflist|30em}} is that the first is equivalent to <div class="reflist " style=" list-style-type: decimal;">{{#tag:references||group=|responsive=1}}</div> while the second is equivalent to <div class="reflist columns references-column-width" style="column-width: 30em; list-style-type: decimal;">{{#tag:references||group=|responsive=0}}</div>. So with the first, you basically responsive with no additional outer styling/classes, and with the second you get additional outer styling/classes but no responsive. But, I may be reading the code wrong :) Plastikspork _―Œ^(talk) 19:48, 15 January 2021 (UTC)

Browser support issue? When a column width is not specified, a div is created with the class mw-references-column, which adds the styles column-width, -moz-column-width, and -webkit-column-width. All is well on just about any browser. When the column width is specified explicitly (eg. 25em), a div is created with the class references-column-width (which does nothing?) and also an explicit 'style="column-width: 25em"'. On older browsers, the column-wdith style without a prefix will not be recognised. Mozilla switched from -moz-column-width to column-width in Firefox 52, which is quite old but not so old that people aren't still using it. I've tested either side of that version and it seem to be causing thae issue at least for Firefox. Lithopsian (talk) 21:00, 18 January 2021 (UTC)

I have also noticed that {{reflist}} now seems to have stopped automatically columnizing things, so if I want columns I have to ask for it explicitly with an explicit spec (e.g. 30em). For me (using Chrome), it does work once that spec is added. —David Eppstein (talk) 06:26, 3 March 2021 (UTC)

@David Eppstein: You will need to provide OS, version, browser, browser version, screen resolution, and browser zoom, and any other font-size modifications you may have made elsewhere. I guess there may be gadgets interfering also? And lastly, the particular pages of interest, to ensure that the automatic column case is kicking in (it requires >10 list items). Your issue sounds more like Atlantic306's above too, so I'm not sure if it's best in this thread or there (there is at least one non-commonality, OS/browser combo; Safari is still using Webkit where Chrome is... Chromium). Have you tried zooming out to see if columns show up at a 'smaller' font size?

I ask for that info because I can't reproduce on Windows 10 Chrome 88 (Chromium) or Firefox 86 (Gecko), which are the two major engines of interest. --Izno (talk) 07:40, 3 March 2021 (UTC)

It's OS X 10.12.6 and Chrome 88.0.4324.192, window size set wide enough that 30em produces two columns. It's hard to tell whether this is a rendering bug or whether it is the intended behavior of the template to not columnize when the number of references is small; in the case that caught my attention diff, there were 9 short footnotes, which seemed enough to columnize to me but maybe not to the template. —David Eppstein (talk) 08:32, 3 March 2021 (UTC)

@David Eppstein: No, I would definitely place that page in the intended behavior category. The auto-columns implementation in MediaWiki (that reflist leans on when no parameters are supplied) only works from >10 notes under the belief that spreading 10 or fewer notes across 3 columns will result in some subpar behavior (especially at 1-3 notes) and that having columns for such short lists isn't fundamentally necessary to boot. Feel free to test on that page by adding a couple of dummy refs in preview and let us know if columns there are not working for you. --Izno (talk) 09:04, 3 March 2021 (UTC)

@PaleoNeonate: Given that you are not having issues with {{reflist}} without other parameters, and the timing of this particular thread unlike the other two above, I believe your browser version is in fact older contrary to your statement (please provide it in the future so we don't have to guess). I did make some changes on January 8 to remove vendor-specific CSS. The major browsers with a release from the past 4 years will recognize the standard CSS for columns. The removal was because traffic data from WMF indicates that less than 1% of people are using a browser which is unable to use columns with standard CSS. Of that 1%, the vast majority are using one specific version of Chrome on mobile, which probably wouldn't productively render columns anyway. See WT:ACCESS, particularly my lengthy comment at 06:47, 21 December 2020 (UTC). --Izno (talk) 07:40, 3 March 2021 (UTC)

I confirm that this is a solved issue. I use highly customized software and something interfered with some of the late CSS features that used to be supported using aliases but now have more official tags. Sorry for the waste of time, —PaleoNeonate – 02:46, 4 March 2021 (UTC)

@PaleoNeonate: No worries. Down to just 1 more "wtf is going on?"... --Izno (talk) 03:36, 4 March 2021 (UTC)

I've added TemplateStyles to the sandbox template. The test cases look good to me. Please take a look. This is in effort to remove the relevant CSS from MediaWiki:Common.css as documented at MediaWiki talk:Common.css/to do.

One thing I'd like to consider, possibly with this rollout, is removal of |liststyle=. Most of the 350 live cases (in all namespaces) with reflist are notes versions (which should probably use {{notelist}}) or are fundamentally misused (I must have removed some 100 such earlier today). In potentially reader-facing spaces it reduces to a count of 210.

--Izno (talk) 04:26, 3 March 2021 (UTC)

I'm also thinking this implementation may be fairly naive or something regarding the font-sizes since reflist should only wrap a references list (after some amount of prior cleaning on my part). --Izno (talk) 06:11, 3 March 2021 (UTC)

TemplateStyles is live. I'll remove the interesting styles from Common.css in the next week or so. --Izno (talk) 00:38, 9 March 2021 (UTC)

Removed ~ --Izno (talk) 17:50, 16 March 2021 (UTC)

I cited a museum exhibit incorrectly on a few articles, but when I went back to fix them all I got was this reflist thing confusing the hell out of me and not letting me do a thing. How do you edit a reference/citation in reflist without knowing how to program? I’m not about to spend an afternoon learning the code I need to fix four words. RedRedRowan (talk) 14:14, 12 May 2021 (UTC)

@RedRedRowan: This venue is the place to discuss the {{reflist}} template itself, not about article citations that it renders. Consider taking your question to Wikipedia:Help desk. When you ask there, give those editors as much information as you can: article title, reference number, etc so that they can go to that page and see how best to help you.

—Trappist the monk (talk) 14:27, 12 May 2021 (UTC)

I'm guessing the OP is confused by the fact that the ==References== section of the article he's working on, which on the rendered page is chock-full of actual references, contains only {reflist} when you go to edit it. Here's my advice: open the entire page for editing (using the Edit button at the top of the page) and then do a text search for the author's last name (or some other word or string used in the reference); I think that will take you to what you're looking for. EEng 05:39, 13 May 2021 (UTC)

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Replace {{{refs|}}} with {{{refs|{{{references|}}}}}}, so people aren't forced to use the abbreviated form if that's not what comes to mind for them.  — SMcCandlish ☏ ¢ 😼  23:49, 11 May 2021 (UTC)

This seems harmless enough to me. I'm assuming that the performance hit of the added code would be so small as to be non-problematic even when multiplied over 10% of all Wikipedia articles. —David Eppstein (talk) 00:03, 12 May 2021 (UTC)

Not a personal fan of adding aliases these days. I also don't think this should be the only thing that goes into this template if updated given the template's use. Izno (talk) 18:15, 16 May 2021 (UTC)

 Not done for now: please add in sandbox version and this can be deployed with the next substantive edit — Martin (MSGJ · talk) 19:12, 26 May 2021 (UTC)