Template talk:Reflist/Archive 17

Add parameter standardisation aliases
Proposal: expand reflist so that and  define column widths in words people can understand, with the advantage that we're not hardcoding a specific width meaning, as we are with eg "30em". That would be easier to understand, better for standardisation, and helpful for any future changes. It doesn't conflict with existing uses, and doesn't require anybody to do anything. In terms of values, I'd suggest that narrowcolumns be initially set as an alias of colwidth=20em (can be debated and/or changed later) and standardcolumns as 40em (ditto). As to why specifying maximum minimum column width (which is what colwidth does) is better than specifying a fixed number of columns (which is what eg reflist|2 does): with appropriate values it works better for a wider of screen sizes, whilst being much the same on standard screens. Rd232 talk 00:39, 20 December 2010 (UTC)


 * I think that it is much better to put arbitrarily-chosen numbers like "20em" and "30em" inside the template. The whole point of the template is to be able to keep these things standardized rather than having to edit every article when we make a style change. So I agree with the proposal. &mdash; Carl (CBM · talk) 00:47, 20 December 2010 (UTC)


 * I Oppose. We tried this with "2" meaning "30em" and editors were not pleased. I expect the same may be true for these parameters. They can mislead people to believe that "narrowcolumns" is ment for small screens, resulting in a single long reference being splattered over 10+ lines, unless we educate editors really well. Also, this is the single most used template on wikipedia, and it needs as little bloat as possible; every parameter needing evaluation adds to the job queue with each article edited. Having to poll for these parameters wil at least double the codebase of this template, and I just finished making it loose considerable weight. (PS. I corrected a misunderstanding.) — Edokter • Talk  — 01:05, 20 December 2010 (UTC)
 * between appropriate parameter naming, documentation, and experience, I don't think we need to overly worry about greater misuse of these than any other parameters. Rd232 talk 01:18, 20 December 2010 (UTC)


 * I think that changing established articles to use the parameters is a separate issue from having them: established articles should generally be left alone anyway. Is there a significant benefit to having simpler code for this template? &mdash; Carl (CBM · talk) 01:12, 20 December 2010 (UTC)


 * to  failed because   does not suit every article. A lot of people use two colums on articles with 10 refs or fewer. In those cases, four or more columns (as produced by   on large screens) oftentimes destroy the references, splitting them over two or more columns and stuff like that. —bender235 (talk) 01:14, 20 December 2010 (UTC)


 * @Rd232: I actually support your proposal, but the definition of  and   (I suggest these short variants, btw) leads us back to the question what the "standard" width should be. I'd prefer   for   and   for , but I don't know whether that is consensus. —bender235 (talk) 01:14, 20 December 2010 (UTC)


 * Well the advantage is that can always be changed. The shorter form you suggest is unfortunately probably too ambiguous;as per my reply to Edokter above, the naming matters to avoid ambiguity. Rd232 talk 01:18, 20 December 2010 (UTC)


 * No, changing it later won't work. Assume we'd have  for   now, that would fit those references here perfectly, and someone might have implemented it just because it did fit that good. But if we later change that to say , those references don't look good anymore. Which means we need to have some sort of consitency here, and that means we should discuss the ideal values for   and   first. —bender235 (talk) 01:29, 20 December 2010 (UTC)


 * I believe I made a similar proposal some time back: standard for a regular reference list and shortened for a shortened reference list. Chaco Culture National Historical Park uses for a shortened reference list, which neatly shows four columns. However, 1965 South Vietnamese coup uses a mix, so it only looks good with two columns. Perhaps we should ask for column support to be directly added to the  extension, but I am not enough of a programmer to know the feasibility. ---—  Gadget850 (Ed)  talk 03:03, 20 December 2010 (UTC)

Other proposal: go user preferences
How about having user choice added to the user preferences, either width, or column amount, like the thumbnail size is user customizable? Issue I see with this are that it will require some work behind the scenes and that, I believe, there is no way to detect how many references there are so articles with just a couple of references will look silly, but I guess a parameter to overrule the user setting can still be in place for these cases, much like you can still define the thumbnail size and overrule the user settings.  X  eworlebi (talk) 12:41, 21 December 2010 (UTC)

Larger font
Where was this change agreed to? It's a fairly major change that affects most articles (and an unpleasant one, at that). All Hallow&#39;s Wraith (talk) 13:58, 21 December 2010 (UTC)
 * It seems it was decided on Village pump (proposals). Another major template change that was not sufficiently documented and discussed, if you ask me. E.g. has there been any notice on this talk page? Apart from that, the proposal and consensus over there was to adjust with
 * Replace the final  with
 * This directly uses the tags and will show that the styling applied by reflist or its sub-templates are not the issue. There have been a few CSS changes at MediaWiki:Common.css. I don't see they could have had this effect, but it is why I checked on another wiki that did not have those changes. ---—  Gadget850 (Ed)  talk 18:50, 24 December 2010 (UTC)
 * I've tried that and it's the same effect. I guess it doesn't matter that much since it literally takes all of 1 second to fix, and there is no urgency to address it so I'll just sort it out on the affected articles when I next edit them. I think it must have started happening after December 12 when there was a lot of snooker article activity, because when I add references I always check to see that they're rendered correctly so I would have noticed if it was happening then.  Anyway, thanks for your assistance. Betty Logan (talk) 19:04, 24 December 2010 (UTC)
 * I think it does matter that this gets fixed. Many editors prefer parameters on separate lines. Also, if you copy a template with parameters from (for instance) Template:Citation, it has a pile of line breaks, presumably encouraging editors to use that format. I tried Gadget850s suggestion on Kyoto Municipal Zoo and the problem persists (and removing line breaks fixes it). Using Gadget850s own logic, "this directly uses the tags and will show that the styling applied by reflist or its sub-templates are the issue" (Italics mine). The Kyoto Zoo article was fine when I last looked (on 11/20). If you look here you will see that the problem now exists in the 11/20 version, showing that it was not an edit someone made that caused the problem, but something in the template or CSS. Obviously we can all go in and fix this issue in hundreds of articles, but we should not need to do this. Donlammers (talk) 17:18, 27 December 2010 (UTC)

Ok, I think I've figured it out. It has nothing to do with this template, or with the css. The culprit is this edit to MediaWiki:Cite references prefix combined with MediaWiki's use of HTML Tidy.

The problem only occurs on the first reference in the references list, and only when that reference has linebreaks after the &lt;ref&gt; and before the &lt;/ref&gt;, like this:  Previously, the output HTML for the references list looked something like this: With reflist, it looked something like this: Everything was good. Now, however, as a result of the edit mentioned above, the output (before HTML Tidy) looks something like this: Or with reflist: As you can see, the bug now occurs. My best guess is that the &lt;div&gt; on the same line as the &lt;li&gt; for the start of the first reference is making tidy decide that it needs to paragraphize the remaining lines of the content of the &lt;li&gt;. For whatever reason tidy doesn't do this if that &lt;div&gt; isn't on the same line, which is why reflist never triggered it before despite using an almost-identical setup: reflist has a linebreak between the div and the references list.

So the solution requested by Donlammers seems to be simple: edit MediaWiki:Cite references prefix to put a linebreak between the &lt;div&gt; and the &lt;ol&gt;, and for good measure do the equivalent to MediaWiki:Cite references suffix. Anomie⚔ 20:07, 27 December 2010 (UTC)
 * Agreed, and done. —Th e DJ (talk • contribs) 20:39, 27 December 2010 (UTC)


 * Thanks Anomie, it is nice to know what is causing the bug. Now the cause is isolated hopefully it will be sorted out! Betty Logan (talk) 20:43, 27 December 2010 (UTC)


 * I would not have guessed tidy was to blame. That program can be a real pain sometimes. — Edokter • Talk  — 21:12, 27 December 2010 (UTC)


 * I thought HTML Tidy was not enabled for the MediaWiki namespace. ---— Gadget850 (Ed)  talk 22:28, 27 December 2010 (UTC)

Thank you. I have checked a few articles I knew that should have had the problem, verified that they had either a space before (or both), and they are fine now. It looks like the problem is solved and we don't need to go back and try correcting individual articles. Having said that, I will probably try to avoid the circumstances in any future editing I do (which, of course, guarantees that next time it will be something else). Donlammers (talk) 00:37, 28 December 2010 (UTC)

3 column parameter
The documentation currently says, "Three-column lists may be inaccessible to users with smaller/laptop monitors and should be avoided." That leaves the question whether existing uses of the parameter should be left in place or removed. If the goal is that the parameter shouldn't be used at all, why is it in the template? If the goal is to leave existing uses, the documentation should say so. &mdash; Carl (CBM · talk) 12:53, 30 November 2010 (UTC)
 * That sentence has been there for ages, but I feel it is out of scope in the template documentation. It entirely depends in what context reflist is used. I'll remove it. — Edokter • Talk  • 13:09, 30 November 2010 (UTC)


 * I think I brought this up fairly recently. Three columns are quite applicable to shortened footnotes. ---— Gadget850 (Ed)  talk 13:40, 30 November 2010 (UTC)


 * That's what I thought, but I have seen people change an article from 3 to 2 based on the unilateral recommendation here that 3 columns "should be avoided". &mdash; Carl (CBM · talk) 13:45, 30 November 2010 (UTC)

I'd like to reopen this. I'm one of those who change from 3 to 2 for the above reason. I was about to again when I went looking for the anti-3 authority to cite and found this. So I tested both layouts in my browser (Firefox 3.0.4) narrowed to about half the screen width, thus about 500 pixels (from normally 1024x768), which I think will be normal for many users, including netbook users and probably large-monitor users who have many windows open at once and thus prefer them smaller, and probably cell phone users are even more a concern. The 3-column layout makes columns of mostly single words. The 2-column layout is more readable. In both cases, some linked texts run longer and overlap into the next column, reducing readability further, or force horizontal scrolling, which is unpopular (per useit.com). I don't usually see footnotes that are so short that they'd occupy only one line each in a 3-column layout at 500 pixels wide. I usually work at full window width, so 3 columns are fine for me, but so are 2 columns, and other users should benefit from readability, too. Is there a strong enough rationale for 3? Thanks. Nick Levinson (talk) 05:35, 30 December 2010 (UTC)


 * Three columns works very nicely for pure shortened footnotes; see Chaco Culture National Historical Park. It does not work as well when long and shortened footnotes are mixed. ---— Gadget850 (Ed)  talk 13:39, 30 December 2010 (UTC)

No column support
Under the subsection No column support; please could an administrator add AOL, as there is no difference between and  when viewed on AOL. Obscurasky (talk) 23:16, 28 December 2010 (UTC)
 * AOL uses Internet Explorer under the hood, which does not support columns. We only list the major browser families; listing them all individually would take an inordinate ammount of space. — Edokter • Talk  — 00:52, 29 December 2010 (UTC)
 * OK, thanks anyway Obscurasky (talk) 01:17, 29 December 2010 (UTC)


 * Now that I look at the latest report, I don't see AOL listed at all, but it could show as IE. I am going to agree— any browser with less than 1% traffic is not a major concern. ---— Gadget850 (Ed)  talk 02:45, 29 December 2010 (UTC)

Include section title
Should we have a version of this template that includes a section title? I predict that >99% of the time, "== References ==" (or, equivalently, "==References==" ) precedes "" --Elvey (talk) 19:17, 9 January 2011 (UTC)


 * No. The edit link will then open the template for editing, not the article. You can create a heading using HTML, but then the edit link does not appear. Either way you would have to edit the entire article to change the reflist parameters. And the section title may be Notes, Bibliography, Works or other titles. ---— Gadget850 (Ed)  talk 20:04, 9 January 2011 (UTC)