Template talk:Reflist/Archive 32

== Using, , etc. and gives them sensible column-widths; it turns on responsive when there are no parameters (and I believe you can still force non-responsive by using  ). Colwidth, the groups and lower-alphas, etc, all seem to work as expected. I agree about the narrow and wide keywords, but I originally wrote the code anyway so that it would be easy enough to re-instate them if consensus were established. If nobody else comments and objects in the next day or so, I'd recommend that you go ahead and update the main template from the sandbox. I'll look out for the change and try to catch any issues after deployment if you don't get there first. Nice work! --RexxS (talk) 16:00, 3 July 2017 (UTC)
 * I have just deployed this. —Th e DJ (talk • contribs) 08:04, 8 July 2017 (UTC)
 * I just noticed that it's working and came here to search. Sort of a dream come true for me, haha. Reflist|2 now displays 3 columns and it was sorta weird to me, heh. So what now? Is there going to be a bot to remove all instances of reflist|2, 3 and 4? --Jennica ✿ / talk 19:00, 8 July 2017 (UTC)
 * I noticed this doesn't work with attribute needs to be present, but not as  . -- Red rose64 &#x1f339; (talk) 08:00, 9 July 2017 (UTC)

So is reflist going to be phased out and replaced with this down the road? Why not just change
 * The issue is  see mw:Help:Parser functions in templates, so that test needs to be changed to
 * at the moment if  is called like that, it defaults the width to 25em rather than usual default of behaving like.
 * - PBS (talk) 13:56, 8 August 2017 (UTC)
 * The effects of this change have now been seen widely. If there had been opposition, we can be sure it would have been voiced. When I noticed it, I agreed, but didn't register my support formally here. For the record, I now do. -- Michael Bednarek (talk) 14:05, 8 August 2017 (UTC)
 * I can't see how the "fix" you tried to put in place actually fixed your issue, especially when you claim to have never considered someone specifying more than three columns. The bit of code you were messing with only takes effect in that situation. Your claim that the test needs to change to  is not correct either, the test is working as intended (just not as you'd like it). Also, BTW, the default width is 30em on the desktop site, not 25em.
 * Again, see above where several people commented in support of the change after it was made a month ago. It might, maybe, have made sense to revert it when the change was made a month ago. At this point, after it has been live for some time and praised by several other editors, it's a bit late to try to do so. Anomie⚔ 19:36, 8 August 2017 (UTC)
 * Again, see above where several people commented in support of the change after it was made a month ago. It might, maybe, have made sense to revert it when the change was made a month ago. At this point, after it has been live for some time and praised by several other editors, it's a bit late to try to do so. Anomie⚔ 19:36, 8 August 2017 (UTC)

I disagree with making width 30em or 25em or getting four columns if first parameter is set to 2. This means users wanted 2 columns. Only if number is greater than 5 or 10, then it might be ignored and set to 25em because there are no that much wide normal screens that would properly display 10 columns of references nor article with that much references that needs more than 5 or 10 columns. --Obsuser (talk) 04:52, 13 August 2017 (UTC)
 * Selecting a fixed number of columns had been deprecated a long time ago. Given the wide range of screen widths, this selection was never a good idea, and overriding it is a good thing. -- Michael Bednarek (talk) 09:37, 13 August 2017 (UTC)
 * I agree. — Paleo  Neonate  – 23:47, 13 August 2017 (UTC)

I said, "I'm shocked that something this sensible and useful didn't meet with kamikaze-like opposition", and sure enough PBS has come along to fulfill the prophecy!  E Eng  21:54, 8 August 2017 (UTC)
 * ===EEng's faultless crystal ball===
 * Guilty. Whilst we might not achieve full support for the usual tarring and feathering for doing something necessary and useful, would you prefer the Welsh not or the sambenito? Andy Dingley (talk) 10:25, 14 August 2017 (UTC)

Having no columns has been the default since the project started, and I do not see a broad consensus for change. -- PBS (talk) 09:20, 15 August 2017 (UTC)
 * There seems to be a lot you don't see, such as how ensconcing criticism of oneself in a big green collapse box merely draws more attention to it.  E Eng  10:46, 15 August 2017 (UTC)


 * did you follow the earlier discussion above which noted the recommendation at Contributors/Projects/Columns for references? I believe we are merely falling in line here, not doing something controversial with this template.— TAnthonyTalk 14:51, 15 August 2017 (UTC)

Template size limit?
Is there a limit on the number of citations an article may use? The article List of 2017 albums seems to have hit a size limit. It currently has 1,284 citations. There are at least two articles with more citations, List of cult films with 1,610 citations, and List of Australian treaties with 2,136 citations, and both these article show all the references below, but 'List of 2017 albums' is currently showing Template:Reflist and no citations. When I make an edit and look at the preview, a warning is listed that states"Warning: Template include size is too large. Some templates will not be included." The article currently calls out the reflist by stating. If I change the call-out to, the size warning is still there, but it will show all but the last three references. For those last three references, instead of the citation, it shows #invoke:citation/CS1.
 * Note: (To invoke the reflist template, the double '<' would be replaced with a double '{', but I cannot use the double '{' in the talk page without activating the template).

If there is a size limit for reference citations, can it be increased? If there is a size limit, why does 'List of cult films' manage to list 326 more citations without running into a listing error?

I think this is a problem for the programmers rather than administration, but I think this talk page is the appropriate place to raise the issue. I hope someone can help. Thank you. Mburrell (talk) 00:58, 28 August 2017 (UTC)
 * This isn't an issue of this template really, but more of templates generally. See WP:TLIMIT. Nikkimaria (talk) 01:03, 28 August 2017 (UTC)
 * I agree with Nikkimaria, it's a template limit problem. The article List of cult films contains a significant proportion of references that are bare urls, i.e. those particular references don't use citation templates, so that article falls short of hitting the limit on number of templates. Similarly, List of Australian treaties uses hardly any templates, so doesn't encounter the problem. If someone attempted to update those articles to use citation templates (to ease maintenance and help guard against WP:Linkrot), those articles would hit the same limit that you've encountered. HTH. --RexxS (talk) 02:10, 28 August 2017 (UTC)
 * Thanks for the responses. I suggested to my article users that we split up our article due to the template limitations. This looks like a constant rather than variable limit and I guess we just bounced into the limit ceiling. Thanks for pointing to the right definition page. Mburrell (talk) 05:30, 28 August 2017 (UTC)
 * To name a template in a talk page without activating the template, use the template. -- Red rose64 &#x1f339; (talk) 11:29, 28 August 2017 (UTC)

Not displaying at United States House of Representatives elections, 2018
At United States House of Representatives elections, 2018 the references aren't showing but it's not clear why. Timrollpickering 13:28, 20 December 2017 (UTC)
 * Not the fault of this template. That article uses too many templates and has exceeded the template include size.  There is a red error message display when the page is previewed.  A discussion at the article's talk page about how editors there can rework the article somehow to reduce the number of templates, to split the page, perhaps other solutions, is in order.
 * —Trappist the monk (talk) 13:51, 20 December 2017 (UTC)

HELP ME
I'm pullling my hair out why isnt it working https://simple.wikipedia.org/wiki/User:Hjk321/Advent_calendar — Preceding unsigned comment added by Hjk321 (talk • contribs) 17:53, 7 December 2017 (UTC)
 * Hi, I fixed the error, you were just missing a slash ;) — TAnthonyTalk 17:59, 7 December 2017 (UTC)
 * Thanks, I feel really stupid. Shame there's no syntax highlighting in that wikipedia...
 * , please look at w:simple:Special:Preferences and consider testing the syntax highlighting feature. Whatamidoing (WMF) (talk) 18:38, 12 January 2018 (UTC)

Feedback requested at Template talk:Div col
There is a discussion at Template talk:Div col about changing the default from two columns to a specified width, as was previously discussed and implemented here. The talk page has only 38 watchers. Feedback from technical folks who lurk is welcome. – Jonesey95 (talk) 21:24, 12 January 2018 (UTC)
 * More specifically, Template talk:Div col. -- Red rose64 &#x1f339; (talk) 00:31, 17 January 2018 (UTC)

Columns
Why does it seem like the default nr of columns has changed again? Now it's 4 in a lof of places and you can't even use the em form to change it if it would be better with more or less.

I have no idea what the point in any of this is. All it does is make people have to change their habits and everyone has to waste time and fix the old articles and implement the new changes. It's changed from 2 to 30em to whatever it is at the moment even though nothing seemd to be wrong with the previous ones. Now it's changed to being like 4 columns, why? Why aren't projects informed of these kinds of changed also? Few people I've met seem to have known that old standards have become outdated. It's making me pretty confused.★Trekker (talk) 10:54, 26 January 2018 (UTC)
 * Please give an example article where you see this problem. -- Red rose64 &#x1f339; (talk) 12:36, 26 January 2018 (UTC)
 * The article here has four columns now for example and I don't seem to be able to do anything about it despite trying to use the em format. The problem is also why this stuff changes without explanation and no one seems to get to find out about it beforehand.★Trekker (talk) 13:01, 26 January 2018 (UTC)
 * That has 2 columns on my monitor. This is the point of using "em"s--that different size monitors (and zoom levels/resolutions) will cause a different number of columns. Maybe you changed the zoom level or resolution on your computer? --Izno (talk) 13:30, 26 January 2018 (UTC)
 * (edit conflict) The "desktop" default is 30em which can be changed with a parameter; In this case, at a width I consider decent for reading (1024px) I see two columns, or four if extending the window to 1920px width (probably confirming what you see). Explicit column numbers are indeed deprecated (with different behaviors, documented at Reflist).  However, these also had the problem of not scaling properly with window width...  — Paleo  Neonate  – 13:35, 26 January 2018 (UTC)
 * I think I get why the columns looked weird on my computer but why is it that the no one seems to be informed of these changes, there was an issue before with the Harv citations as well, I had to go to the teahouse to figure out what it was.★Trekker (talk) 13:44, 26 January 2018 (UTC)
 * I see three columns, that's using the of the article where  has no parameters. Inspecting the HTML source and associated style sheets, I find that this is equivalent to . If I edit the page to add a parameter and preview it without saving, I see a different number of columns, for example:  - 5 columns;  to 22em - 4 columns; 23em to 30em - 3 columns; 31em to 46em - 2 columns; 47em or more - 1 column. You may see different amounts, since your system setup is not likely to be the same as mine. What we should be aiming for is not a particular number of columns but an optimum balance between text and blank space, where the main consideration should be that longer refs should not wrap excessively. If most refs are short, as with the Gärdestad & Liimatainen 2005 refs, a narrower column is desirable; but where most refs are long, a wider column would be more suitable. For an article like this which has a 50/50 (nearly) split between the two, a compromise between narrow and wide is in order. Generally I would not specify a column width to greater precision than 5em. -- Red rose64 &#x1f339; (talk) 13:50, 26 January 2018 (UTC)
 * I've just edited Ted Gärdestad to specify . I think that looks better on a range of monitor widths up to 2560px. However, please feel free to alter that to what you feel is best, but please keep the colwidth now, even if you reduce it back down to 30em.
 * This is an example of the issue that the default carries less information that the parameter explicitly set to the default value. There's a difference between no parameter and 30em – the latter implying a deliberate decision to set 30em, rather than a laissez-faire reliance on the default value. Hope that makes sense. --RexxS (talk) 14:16, 26 January 2018 (UTC)
 * Hmm yes... There various articles I've set to use default as there seemed to be no reason to use a custom value; but I guess that 40 for the above article is decent considering the long harv notes (just as 25 or 20 is common for short harv-only).  — Paleo  Neonate  – 14:51, 26 January 2018 (UTC)

oh for goodness' sake
I switched from using, when the following div sets its column width in ems, those ems are 90% smaller in absolute terms than for the same content without the reflist class. If you use your browser's inspect function, you can see that happening. In Monobook, 'references' columns are never narrower than about 345px, but 'reflist' columns can be as narrow as approximately 306px, which is the expected ratio of 90%. Hope that makes sense. --RexxS (talk) 11:54, 3 March 2018 (UTC)
 * Oh, I see. But is this behavior intended or unexpected? --Vriullop (talk) 12:24, 3 March 2018 (UTC)
 * It's unintended, but expected from the way the template was originally created. In any given article, there really shouldn't be a problem, because you're unlikely to be mixing the two styles. Nevertheless, simply setting  in reflist should make it behave closer to the way  does. You might want to test that and see. --RexxS (talk) 12:33, 3 March 2018 (UTC)
 * I can only think it as an unlikely problem if someone uses both notelist and references tag. The issue has arisen when a user changed the tag for the template and found it confusing that the number of columns changes suspecting of some bug somewhere. Let me reword the question, without any parameter shouldn't both render the same columns? Just for consistency, without prejudging which one is better and without having tested how to achieve it. --Vriullop (talk) 14:06, 3 March 2018 (UTC)
 * To answer your question: in my humble opinion, without any parameters both should render the same number of columns at the same screen size. And with my ancient and gradually worsening eyesight, I would much prefer it if reflist simply didn't make the font size smaller, which would solve both problems. But the tyranny of the majority ensures that some folks' idea of what "looks good" triumphs over functionality, accessibility and consistency every time. --RexxS (talk) 21:49, 3 March 2018 (UTC)
 * On the other hand, if colwidth is specified as some number of ems, it refers to the width of letters, so one would expect it to vary with the font size. So should the default be some number of pixels instead of 30em?  Kanguole 00:08, 4 March 2018 (UTC)
 * No, because then it wouldn't react properly if someone adjusts their browser to display the page with a larger font size. Anomie⚔ 05:12, 4 March 2018 (UTC)
 * No, because then it wouldn't react properly if someone adjusts their browser to display the page with a larger font size. Anomie⚔ 05:12, 4 March 2018 (UTC)

The default is 30em
I suggest that the documentation should mention that 30em is the default, in two places i.e.: Shall I change it as above? -Lopifalko (talk) 07:51, 4 July 2018 (UTC)
 * "Syntax (for example, the default) |30em with no space"
 * "Automatic columns (default, of 30em, when no width is specified)"


 * This needs to changed/clarified.
 * Since 30em is the default, it should not be mentioned under "Optional parameters". Instead, use a different width: "Syntax (for example) |20em with no space (i.e. not |20 em)".
 * Same for "Columns" section: "Reflist|20em (for example) instructs the browser to create as many columns as possible (of width at least 20 em, in this example). Also, "Automatic columns (the default is 30em when no width is specified)" and remove the "30em: Where there are many..." example.
 * H:REFCOLS should also be changed to reflect that the default is 30em and remove the "Reflist|30em: Where there are many footnotes..." and change the "For example: Using Reflist|30em..." and further mentions of 30em to a different width, such as 20em.
 * —Ojorojo (talk) 14:34, 4 July 2018 (UTC)
 * Whatever documentation is provided, it needs to recognise that there is a difference between (1) and (2)  (or ). In the second cases, there is a clear indication that the editor is aware of the parameter that determines column width and has chosen an appropriate value for it. In the first case we don't know whether the editor has made any determination of what column width would be best, or if they have simply added the template without any further consideration. The parameterless template should be an invitation for others to check whether the default 30em is optimal; hence specifying 30em can save repetitive checking of the same article. --RexxS (talk) 16:11, 4 July 2018 (UTC)
 * Though people are removing this from templates indiscriminately. 18:59, 4 July 2018 (UTC)
 * Huh? Removing what from what templates? EEng 19:09, 4 July 2018 (UTC)
 * Removing the 30em from the reflist template. Keith D (talk) 20:46, 4 July 2018 (UTC)
 * That will at least be me. I have learned to do otherwise today. -Lopifalko (talk) 20:48, 4 July 2018 (UTC)
 * Albeit only manually and when making other changes.-Lopifalko (talk) 06:14, 5 July 2018 (UTC)
 * Ditto. — Paleo  Neonate  – 06:57, 5 July 2018 (UTC)
 * Will look but there was someone running a bot last month that removed 30em from thousands of articles. I just assumed this was ok. ...will research some more.--Moxy (talk) 21:16, 4 July 2018 (UTC)
 * Jesus Christ, why do people do idiot stuff like that? Even if you don't realize, as Redrose explains above, that that's a negative change, it's at best a zero-value change, so how in the world can that seem like something worth clogging up watchlists and histories for? How could something like that get BAG approval? Please let us know what you find out. I'm in the mood to kick some butt and take some names today. EEng 21:45, 4 July 2018 (UTC)
 * On reflist, versus on see also div? (I did see a bot editing those lately.)  — Paleo  Neonate  – 02:52, 5 July 2018 (UTC)
 * I would suggest not saying that 30em is the default without adding further explanation. This will lead people to think that and  have the same behavior. 30em is in fact not the default; the default is "automatic", and the documentation currently says that. And the absence of a colwidth does not necessarily mean no one has thought about what the optimum colwidth should be; it's possible someone thought about it and decided that automatic was appropriate. Kendall-K1 (talk) 03:21, 12 July 2018 (UTC)
 * The "someone" will be the various people who contributed to discussions on this matter over the last four years. See most of the threads at Archive 25, Archive 26, Archive 27, Archive 28, Archive 29, Archive 30, Archive 31, Archive 32. -- Red rose64 &#x1f339; (talk) 11:52, 12 July 2018 (UTC)
 * The "someone" will be the various people who contributed to discussions on this matter over the last four years. See most of the threads at Archive 25, Archive 26, Archive 27, Archive 28, Archive 29, Archive 30, Archive 31, Archive 32. -- Red rose64 &#x1f339; (talk) 11:52, 12 July 2018 (UTC)

Rows of whitespace between references
Recently I noticed several rows of whitespace, each no wider than a column, randomly appearing both between and within numbered references. It seems to occur when asterisks are used to create bullet-point lists within grouped references (by "grouped references", I mean listing more than one citation template within a single reference). Here is one example (both before and within reference 4). Am I missing something here? I know that certain parameters regarding width are now deprecated, or at least I think that's the case, but I don't think that's the problem here. Levdr1 lp /  talk  07:09, 26 July 2018 (UTC)
 * No such problem here with Safari, but I do note that such lists are inside spans, which is not allowed in HTML (See also T49544), so combined with the columnbreaking CSS statements, it might cause some weird effect in some browsers perhaps.. This behavior possibly also changed, because Tidy used to attempt to correct such constructs, where RemexHTML likely leaves it alone and leaves it up to the browser to interpret. —Th e DJ (talk • contribs) 07:48, 26 July 2018 (UTC)
 * Thanks. Firefox appears to be the culprit, at least in part-- no whitespace *within* reference 4 on either Safari or Chrome. However, whitespace is still present *before* reference 4 regardless of browser. It would seem that "grouped references" (again, by this I mean more than one citation template within a single numbered reference) must now remain within a single column. I don't think this was always the case. If a single numbered reference had a bullet-point list of multiple citations and it appeared near the bottom of a reflist column, sometimes the reference would be split in two, with leftover bullet-point citations overflowing into the next column. Am I remembering correctly? Are "grouped references" limited to a single column now? (By the way, what do we call "grouped references" with bullet points as I have described in this thread? I am *not* referring to WP:REFGROUP.) Levdr1 lp  /  talk  09:11, 26 July 2018 (UTC)
 * I usually see them referred to as "bundled citations" and I generally think of them as a poor idea, introducing a lot of extra complexity for no real gain, and making a mess of the wiki-text with a new line for each bullet. If those same set of citations were to be used again elsewhere in the article, I could see a case for bundling them and naming them as a bundle, but otherwise I can't discern any improvement over unbundling them into separate references, especially when they are re-used individually in the article. Others will have different opinions. --RexxS (talk) 13:19, 26 July 2018 (UTC)
 * I usually see them referred to as "bundled citations" and I generally think of them as a poor idea, introducing a lot of extra complexity for no real gain, and making a mess of the wiki-text with a new line for each bullet. If those same set of citations were to be used again elsewhere in the article, I could see a case for bundling them and naming them as a bundle, but otherwise I can't discern any improvement over unbundling them into separate references, especially when they are re-used individually in the article. Others will have different opinions. --RexxS (talk) 13:19, 26 July 2018 (UTC)

Examples
The "Examples" section here doesn't actually show examples. It just shows an overview of the syntax. An example would show, you know, an example of the text you'd actually type. IAmNitpicking (talk) 13:07, 29 July 2018 (UTC)
 * Where? I see two sections titled "Example" (no "s") and both have what I would call examples in them. Kendall-K1 (talk) 13:30, 29 July 2018 (UTC)
 * An "example" would be . (I had the Embryophyte article open in another tab.) Examples have actual values. A list of possible types of things you can include is a syntax illustration or something. An example could actually be put in an article and work. Note that my example above is a valid example of "example".IAmNitpicking (talk) 17:25, 30 July 2018 (UTC)
 * That would be an example for Template:Citation; this template merely shows the list at the bottom of the page, and is not for generating a citation Galobtter (pingó mió) 17:28, 30 July 2018 (UTC)

column default
I do not see how introducing columns, by default, improves their display in digital documents (or print, fwiw). Would someone here be able to point out the advantage, or the discussion where some sort of consensus was reached, because using the parameter to force a single column feels belligerent. Otherwise, I am a big fan, and appreciate the functionality it allows. cygnis insignis 12:25, 31 October 2018 (UTC)
 * There is plenty on this talk page, and in its archives. See for example my comment of 11:52, 12 July 2018 (UTC) at the bottom of above. -- Red rose64 &#x1f339; (talk) 12:45, 31 October 2018 (UTC)
 * I appreciate the time taken to quickly respond to my query. which I hoped would be seen by someone active on this page. I would prefer to have received a succinct, or nutshell, a reference to the quintessence of the decision, because while the course of that decision that overrides my own preference to follow the convention of reading from left to right—without the need to rescroll to find the next column—may well be punctuated with the missives and well informed opinions of my colleagues here, I am inclined instead to refocus on improving the content of our document. Sincerely yours, cygnis insignis 13:45, 31 October 2018 (UTC)
 * Feel free to write such a summary if you think it will benefit other editors in the future. Kendall-K1 (talk) 14:30, 31 October 2018 (UTC)
 * Hi. Is that intended to be a helpful suggestion? If the reason is made known I would add it to the template documentation and propose that the MOS be altered to guide those who have the same concerns. Please enlighten me and others if this is obvious, or your response may be misconstrued. — cygnis insignis 14:57, 31 October 2018 (UTC)
 * The gist of the discussion is that "we don't know what kind of device each reader is using, so we will let that user's browser or printer decide how many columns to display". --Izno (talk) 14:41, 31 October 2018 (UTC)
 * Hi, and … Thanks. My understanding is that the device may elect to render pagination in various ways, forcing columns would not be helpful when that occurs, the output seems to be related to the page layout here and is probably ignored when the content is scraped out or rendered elsewhere. This doesn't address the issue of two or three columns rendered by the template here, in mainspace, or I fail to see how that relates to the concern raised. — cygnis insignis 14:57, 31 October 2018 (UTC)
 * Research shows – and experience, such as in newspapers, demonstrates –  that for most people reading is hampered by columns that contain too many words because then the eye loses its ability to scan from the end of one line to the beginning of the next. Since citations are of indeterminate length and browser windows are of indeterminate width, we cannot guarantee that no citation will wrap onto multiple lines no matter how long we try to make the lines. Once we have accepted that we have to cope with multiple lines, the only outstanding question is how wide should we make them, and most editors seem to have agreed that somewhere around 30em to 40em makes for the most comfortable experience. The result is that what you see for the column default has considerable consensus. --RexxS (talk) 19:17, 31 October 2018 (UTC)
 * Thank you for the response, however, the part of the rationale that was posted as "we cannot guarantee that no citation will wrap onto multiple lines no matter how long we try to make the lines" is not understood by me, or at least what the relevance of it is. I am not able to understand the transition from 'people cant read long pieces of text' to 'forcing columns', and it may be that the assumption was made that I thought there ought be any columns, instead of none, and the width was to be determined by some means. If there is some research to indicate that breaking the text assists with reader attention, and it is not impolite to request a citation be included in those sort of assertions at our document, then a sort of paragraphing would surely be less disruptive than navigating to the continuation of the text at some point in the part of the page just past. Again, if a RS states something contrary to this, then please allow me to verify that. Or if I am personally unable to comprehend this rationale, to exclude any other possibilities in this discussion, then at least add it to the documentation to allow others to appreciate the decision that was made by the community … somewhere. —cygnis insignis 15:44, 1 November 2018 (UTC)
 * I'm not sure what's so difficult to comprehend about "we don't know how long a citation might be" and "we don't know how narrow a reader's screen might be". Taken together, I'm at a loss to see how you can fail to grasp the point that we have to accommodate the possibility that lines may need to wrap. You can either take my word for it that long lines that wrap are less comfortable to read than some optimum line length around 30-40 characters, or you can do your own research. --RexxS (talk) 15:58, 1 November 2018 (UTC)


 * This recommends 50-60 (though the kind of content matters) but the point is the same: line length matters. EEng 16:10, 1 November 2018 (UTC)
 * That recommends 50–60 characters, which is around 20–30 ems depending on the content and font. Kendall-K1 (talk) 17:13, 1 November 2018 (UTC)
 * Thanks RexxS and EEng. Cygnis insignis: forced but dynamic columns were implemented awhile back after lengthy discussions, so there isn't one succinct paragraph that can inform you of how the decisions were made. If you are desiring to change the way Wikipedia displays citations, you should probably open up a discussion in a larger forum than this template talk page, but I don't foresee it getting much traction at this point. In any case, I should point out that if an article has 10 or less citations, they are currently not broken into columns. Part of the rationale for columns was that they save a lot of vertical space, which is believed to improve readability. Further, the assumption can be made that we typically read citations individually, not as a group, so the only times you'd have to rescroll is when the citation you are looking at is broken across 2 columns.— TAnthonyTalk 18:09, 1 November 2018 (UTC)
 * Ideally the consensus following someone's desire to "change the way Wikipedia displays citations" was also conducted in a different forum than this talk page, with broader consultation and a formulation of consensus by the closer (even if that ran to three paragraphs). Did that not happen? Have I overlooked the links to something other than another users own comments here? If such a discussion is available to be skimmed, I have read many similar opinions on layout and markup so should be able to sift out the substance of the rationale and produce a formulation if nobody has done that already. An obvious objection would be that the column format (albeit in the next to smaller size of whatever the readers regular font size is set to) follows text that is not in column format, like printed newspapers in the example given above of what readers prefer, and strings out—in who knows how long a sentence—to be wrapped to the readers preferred layout with their other respective preferences or default. If there is a preference to 'display all text as columns' in any device or app's rendering, and I have never noticed one, then that would likely fouled by the rendering of columns in the markup here (resolvable, if it is the case that others apply that functionality, but which I doubt is sought or provided). — cygnis insignis 06:13, 2 November 2018 (UTC)
 * Well, how about Village pump (proposals)/Archive 141? -- Red rose64 &#x1f339; (talk) 10:51, 2 November 2018 (UTC)
 * I would have preferred a link that that discussion at the outset, but understand that a shabby totalling of "I like it" and "I support guy above who is supporting it" by the team who wanted to make a big splat in main space with the tweakers who believe CAN equals MUST apply every naff complication without a rationale or interest in its utility. The only points of legitimate discussion were smothered after it was presented as a fait accompli! So thanks, after being presented with "research shows" statements that mainspace editors recognise as weaselish bluff, and blatant assertions that this is obviously better and I'm a fool not to see that, I'll continue doing what I'm doing until the same mob make it compulsory in discussions on this page. At no point did the points raised there or here become addressed, so average. cygnis insignis 14:08, 2 November 2018 (UTC)
 * I'm not sure how you believe the discussion should have occurred, and I'm sorry the result goes against your personal preferences. You seem to be annoyed by it, so by all means reopen the topic if you think a significant number of people agree with you. I don't really appreciate your condescending "show me the consensus you nitwits" attitude and obvious belief that you are a shining beacon opposed by a mentally-challenged mob, but you're entitled to your delusions. Thanks.— TAnthonyTalk 15:09, 2 November 2018 (UTC)
 * Project much? Thanks? Really? That is the standard recourse of people who make bluff assertions and pile on to make, as you say, condescending responses instead of responding a simple and polite request, a rationale or a link to the discussion. If they don't exist then the option is to exhaust anyone who questions your preference, give them the run around and imply heavily they are being odd not to see the advantage. This was implemented as I pointed out, by those who are focused on naff features as a fait accompli, collecting anything that seems to support the thing that was going to happen, like it not. Address the points I raised or go get your jollies elsewhere, we are supposed to working toward something in discussions. cygnis insignis 18:40, 2 November 2018 (UTC)
 * Excuse me, though you have made good points about why you disagree with fixed columns, you've been subtly obnoxious during this entire discussion. No one here (except me, apparently) has been rude or dismissive to you. I'm sorry no one was able to whip up a link to a consensus discussion fast enough for you, but it is really not the responsibility of other editors to do so under some deadline. No single person made a unilateral change, so there's no need to condescend to everyone reading this page, you can get over it now.— TAnthonyTalk 19:46, 2 November 2018 (UTC)
 * And by the way, you did more than raise some points. You are within your rights to ask for explanations, but all you did when you got them was dismiss or dare-I-say mock other editors' comments, and malign the integrity of the Village pump discussion as well as basically any editor that voted in favor. That's not "working toward something in discussions", that's the opposite.— TAnthonyTalk 19:59, 2 November 2018 (UTC)
 * I shouldn't have to do this, but I'm now sick of your tendentious whining simply because the facts don't fit your pet theories that nobody else agrees with. If you'd taken even a couple of minutes to do a search on the issue of line length and readability, you'd have found dozens of results with slightly differing opinions on optimum characters-per-line, but all agreeing that an optimum exists. You don't even have to look very far as we even have a Wikipedia article, Line length, that discusses the issues and provides 10 references. The other editors here are not your gophers, and I for one am uninterested in trying to convince you to change your mind, because the standard procedure of cynics is to continually demand that others have to provide more and more evidence. That evidence is freely available and understood by most editors. And that is the reason why we have consensus on a default column width for reflist. --RexxS (talk) 20:07, 2 November 2018 (UTC)

The OP needs to do his own research, review past discussions, then if he or she has something new to offer that hasn't been considered before bring it up here. EEng</b> 22:19, 2 November 2018 (UTC)


 * The OP can also customize the view so that he does not need to see columns. Ever. Or 2. Or 80em-wide columns. Or 5em-wide. This is tendentious at this point. --Izno (talk) 02:06, 3 November 2018 (UTC)
 * Nice.
 * Bullet points
 * Why does the line length 'problem' not also apply to the main body of text?
 * What evidence is there that a mix of formats, none and some columns, is assisting the reader? Newspapers only use one, unless they are using to push the attention of the reader.
 * The convention, citation not needed, is to read from left to right then return to left margin. Introducing a new format to a page is avoided without a good reason, ten times better than not doing it, because this also disrupts the ingrained expectation of those who read texts.
 * How does reducing the amount of white space improve readability, I thought the opposite was generally true.
 * It is not tendentious to make these points when the are responded to with none answers and deflection from the same concerns that others have raised in the past, likewise, without responses that address that creepiness of this abrupt and nigh compulsory change. — cygnis insignis 12:01, 3 November 2018 (UTC)
 * compulsory change – It's just been explained to you where you can find instructions on overriding the default behavior. Your approach is very unpleasant, and I suggest to my esteemed fellow editors that there izno need to engage further on this. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 13:11, 3 November 2018 (UTC)
 * References are not article text. Article text consists of sentences organised into paragraphs, which suit a wide layout, and online newspapers do the same. Printed newspapers historically used narrow columns because it suited the pre-computer age which used blocks of certain standard widths in order to match the slugs prepared by Linotype machines.
 * In our articles, references are typically short, they suit a multi-column layout - imagine if these references were not organised into columns, there would be a large blank space in the article. -- Red rose64 &#x1f339; (talk) 13:45, 3 November 2018 (UTC)
 * , noted, now that I thought to look again. Simple solution: add the rationale to the template documentation. Response here to that suggestion: a pile on of helpfulness and insinuation, not a team sport I'll remind everyone. The consensus is said to have been formed here, not an inappropriate to raise the concern again. So what if there is white space, it is a good thing, we are not running out of paper here. cygnis insignis 08:19, 5 December 2018 (UTC)

Percentile width
For modern behavior, this really needs to support percentage widths: like, well, everything else on the modern web. Specifying anything in fixed units is generally foolhardy. This has been a vexing issue for some time now. — SMcCandlish ☏ ¢ 😼  07:56, 5 December 2018 (UTC)
 * I smothered this new section with a reply to an old post, apologies, and good luck with that sensible suggestion. cygnis insignis 08:34, 5 December 2018 (UTC)
 * , does this mean that you want the Reflist to take up 50% of the screen width, or do you want each column to take up 50% of the allotted space for the reflist? In either case, I would not recommend using an unnamed parameter, but instead using something like colwidth or total-width. – Jonesey95 (talk) 10:31, 5 December 2018 (UTC)
 * Any "CSS thing" specified as (say) 50% in CSS should take up 50% of the available space for the element; that's just how it works. We can't have things taking up literally 50% of the screen width without taking them out of the normal document flow and imposing them as overlays or other awfulness, that would break in a lot of browsers, and no one would expect that.  I.e., this should work like 50% (or whatever) does in all other contexts on this site.  Since the parameter accepts  other valid CSS measurement value, then we obviously don't need a separate parameter for this.  There isn't anything magically special about % vs em or whatever.  — SMcCandlish ☏ ¢ 😼  11:28, 5 December 2018 (UTC)
 * Thanks for the answer, and see below for why I was confused. A column width of 50% is the same as two columns, which is no longer supported. Perhaps this talk page or the template's documentation should have an explanation answering this perennial question or a permalink to the discussion that led to the removal of support for a fixed number of columns. – Jonesey95 (talk) 23:46, 5 December 2018 (UTC)
 * This is because "percentage values are also invalid" for setting column-width. Galobtter (pingó mió) 11:44, 5 December 2018 (UTC)


 * Perhaps I'm dense, but how would "each column is 50%" be any different from saying "2 columns"? <b style="color: red;">E</b><b style="color: blue;">Eng</b> 12:20, 5 December 2018 (UTC)
 * You're not dense. It wouldn't be any different from "2 columns" and that's why the suggestion is a non-starter. --RexxS (talk) 14:22, 5 December 2018 (UTC)
 * Yeah, I am a bit puzzled by this suggestion from SMC as well... Maybe he knows something we don't? :) --Izno (talk) 23:13, 5 December 2018 (UTC)
 * Specifying anything in fixed units is generally foolhardy. No, it's not. Quite often some interface elements are intended to be a specific size relative to the font (typically "em" units), leaving the remaining space for the main content and using @media rules to handle the case where the device is too small for that "remaining space" to be enough. Anomie⚔ 12:39, 6 December 2018 (UTC)
 * , @media rules sez i can haz colums? cygnis insignis 12:57, 6 December 2018 (UTC)
 * We're not saying that you can't have columns. What we're saying is that if you use columns, you should specify their widths using known quantities (like em, ex, px etc.) rather than as a fraction of the available width. -- Red rose64 &#x1f339; (talk) 21:47, 6 December 2018 (UTC)

Reflist needed
Somewhere there is a maintenance catalog showing errors where where N is parameter in the inline citation, and providing a Notes line is needed, but a red message exists instead, but I do not know where. Advice, anyone?--Dthomsen8 (talk) 02:08, 9 February 2019 (UTC)
 * Possibly and . – Jonesey95 (talk) 05:42, 9 February 2019 (UTC)

Template:RE listed at Redirects for discussion
An editor has asked for a discussion to address the redirect Template:RE. Please participate in the redirect discussion if you wish to do so. Headbomb {t · c · p · b} 16:20, 3 April 2019 (UTC)