This is an archive of past discussions about Template:Reflist. 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.
I saw an editor removing 30em from one instance of the template, saying this parameter was deprecated and that it should be removed for accessibility reasons. I knew that setting the exact number of columns (|2, etc.) has long been deprecated, but it's news to me that the same has also happened to the parameter for the column width. Is this really so? The template's documentation still gives examples of the use of this parameter, and from a very quick skim of the archives I'm not seeing anything to suggest such deprecation. The impression I get from those discussions is that 30em is currently the default, so removing it apparently won't make a visual difference, and that even then editors should not just remove it as it reflects editorial judgement about the average size of the footnotes on each individual article (something that the template doesn't itself have access to). – Uanfala (talk)16:52, 16 May 2021 (UTC)
That claim, if it was made in the way you attest (no links were provided), is untrue. The documentation is up to date. – Jonesey95 (talk) 16:55, 16 May 2021 (UTC)
I would advise to remove it, but only because I am of the opinion that we should send the minimal CSS to the browser, and adding a custom "30em" adds the associated inline styles, rather than relying on the already-loaded styles in the variety of sheets available. The lack of an explicit width set in the template is just as telling about an editor's choice IME.
You are otherwise correct in your understanding that the integer version for column count is deprecated, and in fact is implemented as column-widths under the hood. Izno (talk) 18:14, 16 May 2021 (UTC)
The 30em default doesn't seem to be working at the moment. Can this either be restored, or the documentation updated? (Hohum@) 14:02, 7 August 2021 (UTC)
The column width is usually not needed for {{reflist}}, but it is needed to make columns in {{refbegin}}/{{refend}}, and when it is used for those it should also be used in {{reflist}} to make sure that the columns are the same width for all. —David Eppstein (talk) 16:32, 7 August 2021 (UTC)
You are unable to use "|liststyle=" in this template to make an unordered list (i.e. dot point lists), because it does not change the HTML from "<ol> </ol>" to "<ul> </ul>" allowing an unordered list. This can cause issues. — Preceding unsigned comment added by Geordannik (talk • contribs)
I was about to remove the column count parameter from a Template:Notelist but checked the template documentation first, and it does not say that the count param is deprecated, nor does it document the colwidth param. Should the Notelist documentation be updated to say the same thing as Reflist about columns? GA-RT-22 (talk) 01:43, 25 December 2021 (UTC)
In this version of the Russian invasion article, without any hardwired column-width or number of columns, in desktop firefox with a very wide window, and with either my default fontsize or five sizes smaller, I only get one single column. There are 677 references, which is more than 10.
Could there be something forcing a single column somewhere else in the page? presumably earlier, or inside of the same html or mediawiki scope?
It would be better to handle this at the source of the bug rather than hardwiring the column width, which, as I understand it, is not recommended, even though it remains as a suggestion in the template documentation. Feel free to fix this at 2022 Russian invasion of Ukraine directly. Boud (talk) 01:38, 9 April 2022 (UTC)
I typically use <references /> rather than {{Reflist}} when I create a new article because I use VE, which can't refresh the references within a template, and because I understood the behaviour was identical -- that is, that reflist with no parameters uses the defaults that one gets with <references />. I just found out this is not the case. The last two revisions of The Trundle look identical on my iPad in mobile mode, but if I request the desktop version, I get a single column with <references /> but two columns with reflist. I don't have my laptop with me so I can't check what it looks like on a PC. I tried looking in the Mediawiki documentation for an explanation but couldn't find anything that explained this behaviour. Is there any documentation that explains exactly when the two differ? Mike Christie (talk - contribs - library) 11:38, 18 February 2022 (UTC)
This is because the reflist resets the font-size twice.. As a side effect of this, the one usage has a 30em cut off calculated in 100% of the font-size, the other has a 30em max column width in 90% of the font-size. We should really remove this hack from this template to make it consistent... That might also cause the 30em to be a little bit to big actually, so maybe we need to do something about that as well... Ideally we would set the font size on the responsive wrapper itself, but we still have non-responsive mode that has to be consistent in size... —TheDJ (talk • contribs) 11:20, 8 March 2022 (UTC)
TheDJ, what would it take to make this change? I think it would be best if the template did match the behaviour of the raw tag; that was the intent of defaulting to 30em, I believe. Mike Christie (talk - contribs - library) 11:42, 7 April 2022 (UTC)
We're going to need to reassess the defaults on this regardless when new Vector rolls out. With fixed width, I anticipate 30ems may just barely fit two columns into the main content column.
I agree that the template should match the raw tag on column sizing behavior, I just couldn't figure it out the last time I looked. Izno (talk) 21:36, 27 May 2022 (UTC)
It appears that if there's no whitespace in front of {{Reflist}}, Parsoid doesn't parse the wikitext correctly (see T292277 for details). The opinion from the parsoid folks is that it's not fixable in Parsoid. Is there anything that could be done in the template to work around this problem? -- RoySmith(talk)22:03, 1 October 2021 (UTC)
It might actually help if you move the <templatestyles src="Reflist/styles.css" /> inside of the <div class="reflist" … >. Matma Rextalk22:34, 1 October 2021 (UTC)
Matma Rex My assertion is based on my understanding that HTML parsers will go node to node in order down the tree in the order the file is read. If the style element targeting the element of interest comes after the element, that means the HTML parser needs to get to that element first. Meanwhile, in parallel systems (I understand Firefox to be and I expect Chrome to be also), the CSS parser will have gotten a job or some other indication to start styling the element of interest, before it will have gotten to the style definition. This also assumes the jobs system employed by the browser doesn't take care of all elements at any given DOM level first and then proceed to jobs at lower DOM levels.
In practice it may not show up much, but FOUCs are basically predicated on some data race existing anyway (or total misstyling I guess). I prefer to guarantee the non-existence of FOUCs, so styles go before elements. Hence why I used the word 'can'.
I know for a fact that bottom/late loading styles, such as MediaWiki:Mobile.css, causes FOUCs, so it may be a matter of distance from the element to the styles of interest. Maybe that's a different root cause, but I'm pretty sure it's not.
Regardless of this question with reflist, you will want to review phab:T303378, where the only workaround I know is to move any identified templatestyles tags (or their strip marker forms I guess, I haven't started working on the problem) out of their containing elements. You can call that a hard blocker for those particular components having internal TemplateStyles, so, work still needs to happen on the WMF side.
@Izno Hmm, you're right that it theoretically allows FOUC, although it seems nearly impossible in practice. Something would have to cause the browser to render a page exactly after it received the <div class="reflist" … >, but before it received the <style>…</style>, and in my experience they really don't want to render anything while still receiving the HTML (it's also freaking impossible to search for information about this, all I get in results is barely better than SEO junk). But I was able to make a sufficiently slow-loading website and reproduce it myself.
(And on top of that, the rendering of <div class="reflist" … > would have to be something visible – most elements don't have any content or borders etc. unless you add some in your CSS/HTML, and in this situation it hasn't loaded yet.)
I didn't know MediaWiki:Mobile.css causes FOUC. I looked into how it's loaded, and this is a different situation: it is loaded from the JavaScript code after the page HTML has finished loading. This obviously causes a FOUC, and I don't really understand why it's done this way. It was apparently supposed to be solved in 2018, but then wasn't: T190083.
I also didn't know about T303378, and you're right that it seems like a blocker in some cases (although not this one, right?). I outlined a solution there, I don't think I'll work on implementing it, but I would help review a patch if someone had a try at it.
Consider leaving some part of this comment on the related task, where I also copied (and added a bit). Izno (talk) 02:37, 1 June 2022 (UTC)
I don't feel like it adds much to that discussion? But feel free to quote me if I accidentally said something smart. Matma Rextalk20:23, 1 June 2022 (UTC)
I noticed that a few months ago you updated {{reflist}} to use templatestyles, it seems that in the process the liststyle function seems to have gotten broken.
using {{Reflist|group=note|liststyle=lower-alpha}} is supposed to produce a references tag for the group "notes" with the liststlye "lower-alpha", but running it through Special:expandtemplates produces:
Where you are only applying the liststyle setting if the group parameter is empty?
I think you have your checks back to front here, the liststlye parameter should always be getting applied if it is set, and the group parameter should only be setting the CSS if the liststyle parameter is empty?
So, looking at what I did and what I commented on the talk page:
When I TemplateStyled the page, I did leave a note that I think |liststyle= should be removed. However, it remains. (Someone should work on that; I have similar counts for dis-use today as posted then.)
So this being broken is my misinterpreting how this piece was supposed to work, I agree.
Regardless, I agree with my statement then that if you're using note groups you should be using {{notelist}}, which I'm guessing is the case I was thinking about.
The test cases page works when you set group.
I can say that your suggested first line is wrong. The idea is that reflist always supplies the appropriate CSS for the set of groups. I think this gets fixed, with loss of flexibility (that is mostly unneeded) if we just make the two synonyms in the template in the HTML context. In other words:
with simple removal of the hard-coded style later.
I think I still favor 'working around' the issue by using t:notelist. Will have to investigate to see what all the uses of liststyle are doing today. Izno (talk) 01:23, 28 May 2022 (UTC)
(Of interest: it's been a year and you're the first one to catch the bug.) Izno (talk) 01:26, 28 May 2022 (UTC)
Your proposed fix is a lot more elegant than my suggestion, the second line of my proposed fix is also stupidly written in that it has two identical if statements nested inside each other. I probably shouldn't be trying to debug templates in the middle of the night.
The reason I noticed this bug was a question at the teahouse. There's an editor there who wants to write an article full of tables, each one of which contains notes with references in them with a separate notelist immediately following each table. With the notelist template's current implementation there is no way of having note groups with names other than the 6 numbering schemes. The person I was talking to at the teahouse didn't like the solution I proposed of using the different families of notelists as it would have resulted in each of their tables having a different numbering system, which brings us to using reflist template with custom group names, at which point I had a play with the liststyle parameter and realised it wasn't working properly. 192.76.8.78 (talk) 02:02, 28 May 2022 (UTC)
I may not be able to get to this Soon. If someone could double check that my suggested change works, that would be appreciated. :^) Izno (talk) 22:38, 4 June 2022 (UTC)
It's not specific to {{reflist}} – all templates at the end of the article are failing. Is the article so big that it's hit an expansion limit? Kanguole06:57, 25 June 2022 (UTC)
I use the |refs= parameter of {{reflist}} all the time. As far as I know that cannot be handled with a pure references tag. The unnamed column width parameter is also useful sometimes, mostly to match up the appearance of separate footnote and bibliography sections; it could probably be handled separately by wrapping in some other column templates, but that would be more cumbersome and not really help reduce your usage of templates. —David Eppstein (talk) 07:33, 20 August 2022 (UTC)
My apologies for not responding for relatively long time.
Some of my edit attempts on <Byte> (also discussed in <Talk:Byte> # [20220818] On recent editing that had references "broken") should already reveal much about the subject. (may not completely due to the implementation problem in current MediaWiki)
I'm trying to generate an output having all references in order, as they appear in the article using reflist, but with all the Wiki-markup - i.e. including the various parameters (date= |, title= |, etc.). Is there any way to do this using this template?
When I copy the reflist as it appears in the article, I get a list, but it's only the shown text (no markup). And when I try dig into an article source, or export an article as xml, the only thing I can find is "{reflist}" (unexpanded, no list). PhotogenicScientist (talk) 22:45, 13 January 2023 (UTC)
This edit request has been answered. Set the |answered= parameter to no to reactivate your request.
Hello. Would it be possible to edit this template in such a way, that a particular (hidden) category would be added to the articles that have more than 800 references? On Marathi wikipedia, I repaired infobox film, it basically adds Category:<language> films from <production year>" to the article, if production year parameter is present in the infobox. (निर्मिती वर्ष = production year, मधील = from भाषा = language, चित्रपट = film)
{{
#if:{{{निर्मिती वर्ष|}}}
|{{#ifexist: वर्ग:इ.स. {{{निर्मिती वर्ष}}} मधील {{{भाषा}}} चित्रपट|[[वर्ग:इ.स. {{{निर्मिती वर्ष}}} मधील {{{भाषा}}} चित्रपट]]}}
}}
Not done Don't know what that infobox code has to do with {{reflist}}. I don't think that what you want {{reflist}} to do is possible because this template doesn't actually see the references. This template marks the location in the article where the reference list will be placed and specifies the list's styling.
@Trappist the monk: Hi. Thanks for the prompt response. The infobox code was just an example. How would I be able to populate that particular category automatically? (without scanning the pages, I have already created a script/bot for that, but it is not feasible for large-scale use). —usernamekiran (talk)16:41, 12 February 2023 (UTC)
I would prefer that you didn't delete these. The value may represent an editor's considered judgement of what is needed in a particular reference list, which would be useful if the default ever changed. Kanguole10:46, 6 January 2023 (UTC)
I can't think of any legitimate reason for somebody to specify the width of the reflist, let alone hard-wire the default value into the template call. That's a presentation decision. Article authors should be concentrating on marking up content to describe the structure of the document, not the presentation details. -- RoySmith(talk)14:26, 6 January 2023 (UTC)
You need to develop your imagination a little more. The usual reason I would do this is that I want the {{reflist}} columnization to match the columnization of a {{refbegin}}/{{refend}} on another part of the references, and I don't trust the templates to have default parameters that stay in synch (they currently don't, for instance). —David Eppstein (talk) 19:01, 6 January 2023 (UTC)
I've noticed that {{Reflist}} columns have been hit-or-miss since last year (when deployed without a parameter). I've been wondering if the template was changed due to the new Vector 2022 skin. Thank you for the above insight. — CJDOS, Sheridan, OR (talk) 04:10, 8 February 2023 (UTC)
More likely what you are seeing is that the default behavior is to make columns only when the number of references is large enough. If there are only a small number (I don't remember what the cutoff is), it will keep them all in a single column. —David Eppstein (talk) 17:52, 8 February 2023 (UTC)
That's not what I see in desktop view, David. When I'm logged-out of Wikipedia, the articles Barcelona and Monopoly (game) have well over 150 inline citations, and list as two-column. When logged-in to Wikipedia, however, the inline citations list as single-column. I would expect {{Reflist}} to display columns regardless of my login status. — CJDOS, Sheridan, OR (talk) 10:21, 27 February 2023 (UTC)
Might you be using the Vector 2022 interface? On my device (using Microsoft EDGE on Windows desktop), that interface displays a tools list on the right-hand side of the page. That list appears to take up enough screen/display real-estate to cause reflist to display refs in a single column. If I change the browser's zoom level to 90%, it displays in two columns. When logged out with zoom set to 100%, the tools menu is not displayed, and refs are shown in two columns. If I use the Vector legacy (2010) interface, I see two columns when logged on. At least that is my experience. — Archer1234 (t·c) 10:58, 27 February 2023 (UTC)
Upon further testing, I discovered that one of the scripts I have loaded in my common.js for AutoEd caused the tools menu to display persistently on the right-hand side of the Vector 2022 interface, with no ability to close/hide/collapse the menu. This is what reduced the screen/display real-estate. When I removed "AutoEd" from common.js, the tools menu appeared collapsed/hidden, the screen/display real-estate was restored to normal, and the two-column display of references was restored when logged in to pages like Barcelona and Monopoly (game). YMMV. — Archer1234 (t·c) 11:43, 27 February 2023 (UTC)
That is correct. Wikipedia switched me to the Vector 2022 view (I certainly don't like it), but I left it rather than switching back to legacy view as that's the default (so I would see what most others see). That seems to be the answer to the Reflist columns on/off. I will try keeping my browser at 90% view for Wikipedia; thank you for your assistance. — CJDOS, Sheridan, OR (talk) 17:56, 27 February 2023 (UTC)
What about these Enable responsive mode and Enable limited width mode just below the skin choices? I assume the latter just wraps text that would otherwise require a horizontal scroll bar (excludes tables and boxes), but what does the former do? I didn't find much of an explanation for either, but they're both ticked by default. — CJDOS, Sheridan, OR (talk) 18:11, 27 February 2023 (UTC)
List-defined references
Are these useful/popular? It's inconvenient to be unable to edit them in the Visual Editor, and I'm wondering if this is really a feature worth keeping. DFlhb (talk) 16:43, 27 March 2023 (UTC)
I prefer them. It is inconvenient to edit article text broken up by paragraph-length chunks of stuff that is not article text. Putting the reference details elsewhere helps with that. Your experience with Visual Editor may not be typical; I use the source editor. —David Eppstein (talk) 17:34, 27 March 2023 (UTC)
Putting {{clear}} before the References section fixes the overlap problem. The root cause is probably too many images on the page. – Jonesey95 (talk) 14:00, 13 April 2023 (UTC)
The new aggressively-wide side margins in the default skin (Vector 2022) mean that on most monitors at 100% zoom reflist always renders as single column This is one of my greatest frustrations with the skin, and I don't think I'm alone (as @CJDOS: noted above) :).
While we continue to push for less enthusiastic sidebar width and padding, the default reflist column width could also be revised so that refs are two columns in some "standard browser size" configuration. Say a 1200px wide window, running the default skin, with sidebars open? I believe 25em would work. – SJ +13:18, 19 September 2023 (UTC)
I'd rather see us fix Vector 2022 locally with CSS than change this reflist default that has worked well for many years. I can easily get two reflist columns on my 13-inch laptop screen in Vector 2022 with CSS that fixes the absurd whitespace, leaving me with 69em of space for content (it is 94em in Vector 2010 on the same screen). – Jonesey95 (talk) 14:12, 19 September 2023 (UTC)
Let me rephrase. I have no problems with this being fixed in the V22 CSS loaded by enwiki, but as somebody who doesn't use V22, I don't want to see changes to the template which will affect what I see to accomodate V22. RoySmith(talk)15:21, 19 September 2023 (UTC)
You can use different values for vector and Vector 2022.
To target styles based on skins, use a selector such as body.skin-vector-legacy .myClass; specification of the body element is required and must be followed by a descendant combinator (i.e. the space). Other classes on the body or html elements may be targeted in the same manner. See phab:T197617. 1.32+
(ec)If we want to make this change, we would presumably also want it implemented in <references /> since there are plenty of articles with <references /> instead of {{reflist}} as the default widths are the same at the moment. Mike Christie (talk - contribs - library) 14:15, 19 September 2023 (UTC)
Yeah I think this would be the better way. I'm someone who uses the <references /> tag instead of {{reflist}} in my articles. SWinxy (talk) 15:02, 20 September 2023 (UTC)
Reflist inherits the width from the CSS of the skin being used, which is 30em in Vector 2010. When a value is put into the template, then it overrides the skin to make the width something else. SWinxy (talk) 18:23, 21 September 2023 (UTC)
JK I was wrong. It's not set in the skin, the default column width seems to actually be pulled from the Cite extension: ext.cite.styles.css. The templatestyles does the whole list-style-type thing, and .reflist-columns-2/.reflist-columns-2 are for backwards-compatibility, but the rest don't seem to need to be there. SWinxy (talk) 23:43, 21 September 2023 (UTC)
I use Vector 2022 with the sidebar, and I get two columns of references on both my PC and iPad. Out of curiosity I tried switching the iPad to portrait mode, and got a single column of references. Switching the ToC to the top menu with the Vector 2022 "hide" button gave me two references even in portrait mode. This strikes me as a more natural answer than changing global css. Is there some reason why those with monitors too narrow for two columns of references would not want to set Vector 2022 to have the ToC hidden in the top button? Mike Christie (talk - contribs - library) 12:02, 22 September 2023 (UTC)
I assume you're leaving the toolbar menu closed as well?
Logged out users get the TOC expanded by default, which is convenient. And they won't know that there's an option for references to be two columns. The question for them is whether they are likely to be using a persistent Tools toolbar. Logged-in users are more likely to want to access the tools regularly as well.
The experience varies a lot with combinations of window size and default font size. Many readers use windows between 1200 px and 1680 px with font zoom between 100% and 133%. Here are a few width break points for when refs become two-column (Mac/FF):
The body column has become a second-class citizen, and is the only one whose width is variable, so sidebars that feel normal at a 1800px-wide window at 100% zoom are quite big at 1280px. As a result, what feels like a significant range of normal use cases have body columns that fall between 50em and 60em in width, hence this request.
This is in addition to, not as a replacement for, requests to reduce sidebar margins and horizontal whitespace across the board, including the "bonus" 60px margin that gets added to the main menu at a window width of 1200px / 100%.– SJ +19:57, 23 September 2023 (UTC)
The text would have to be different to {{no footnotes}} because there would be no way of telling if there is a list of references, related reading, or external links. Given that the only information you have is that that no footnotes are properly defined (there could even be an attempt at inline references, not using a <ref> tag), I think the most it could say would be something like:
It could also create an appropriate maintenance category, which would either be useful or worrying depending on the amount of previously unknown unsourced articles it reveals. -- D'n'B-t -- 09:33, 21 April 2024 (UTC)
That looks good, yeah. Also a good idea with a tracking category. My major question is whether it's possible to detect the lack of <ref> tags within the template. – Joe (talk) 09:35, 21 April 2024 (UTC)
