Template talk:Reflist/Archive 21

Autodetecting columns
My general preference for Reflists is that if an article has a short number of references, I use and if it has a lot of them (e.g. more than one browser screen, loosely), I use  (2 columns). I'm not sure how much that matches the usage of other editors. But I wonder if it would be useful to have a variant that uses 2 columns if there are more than 60 or so refs, and otherwise uses 1 column. Perhaps even in time such a thing could be come the default. Interest or opinions? jhawkinson (talk) 04:17, 19 January 2013 (UTC)
 * I use {reflist|30em} when more then 25 refs - As it will allow the browser of each user to pick how many colums. I think its bedt we don't forces set colums. 30em will also let the columns again set at will by user's that increase or decrees there screen size for font.--Moxy (talk) 05:21, 19 January 2013 (UTC)
 * So? That doesn't seem convincing. If we can agree that one particular form is a good default, we can use it and editors can override as they like. The question I'm [trying to be] posing is whether there should be an auto option that counts the number of refs and changes the display as a result. I don't really care whether it uses |30em or |2, the idea is autodetection based on number. jhawkinson (talk) 06:21, 19 January 2013 (UTC)
 * There's no way for the template to count how many refs there are. Anomie⚔ 16:31, 19 January 2013 (UTC)
 * When there are many references, certainly 30em is a better practice in my opinion due to widely varying screen sizes. -- Beland (talk) 19:52, 21 March 2013 (UTC)
 * Anomie, I hadn't thought too hard about the implementation. I think my question is whether there is support for such a thing, regardless of how it would be achieved :). Could I get some feedback on that? But now that we have WP:Lua surely it is implementable, right? jhawkinson (talk) 15:21, 24 May 2013 (UTC)
 * You could, maybe, hack something up by unstripping the strip marker resulting from and scraping the HTML (and then being sure to still return the original strip marker). But changes to Cite.php might well break it, and it would be quite a kludge. Anomie⚔ 23:43, 24 May 2013 (UTC)

Documentation improvement
This comes up fairly often, so I will add it to the documentation:

The number of columns to use is up to the editor, but some major practices include: --— Gadget850 (Ed) talk 12:24, 19 January 2013 (UTC) ✅ --  Gadget850talk 14:59, 29 May 2013 (UTC)
 * 1 column (default): Where there are only a few ; see
 * 2 columns/30em: Where there are a number of Footnotes; see
 * 4 columns/20em: ; see.

Precedence?
Does "reflist|group=n" go before or after the primary reflist? Thanks! Illegitimate Barrister (talk) 08:25, 13 April 2013 (UTC)
 * Before. — Edokter  ( talk ) — 08:58, 13 April 2013 (UTC)

CSS3 support
This template and others use column-width to provide column support. The styling is fairly simple: -moz-column-width: ; -webkit-column-width: ; column-width: ;

The style includes Gecko/Mozilla and Webkit browser-specific CSS and standard CSS. Earlier versions of Gecko and Webkit supported columns only through the browser-specific CSS but the newer versions now support standard CSS3. With this styling, we can support older and newer versions. caniuse.com only documents standard CSS. --  Gadget850talk 12:40, 24 May 2013 (UTC)
 * I can confirm that Firefox 3.5 supported columns, since that's the browser which my mother's laptop still has, and is also the version that I was using when I . I'm willing to bet that all subsequent versions of Firefox have done too; it certainly didn't begin with 19.0 as claimed in . -- Red rose64 (talk) 14:33, 24 May 2013 (UTC)
 * Firefox 19 is where they switched from  to  . --   Gadget850talk 15:27, 24 May 2013 (UTC)

Wrong error message
I just forgot to remove the extra Reflist template I added to an article for testing. This produced a big red Cite error message at the bottom of the page; this is A Good Thing. However, the actual text suggested there was no Reflist in the article, not multiple instances. Any chance of a more appropriate Cite error message for this case? You can see the error message here. HairyWombat 18:47, 13 September 2013 (UTC)
 * The big red error message comes from the cite.php extension, not from (which is essentially  but with some CSS styling and classes in the div). If you replace both  with  the problem disappears. If you replace both  with, which places two sets of the following


 * into the wikicode, the error message also disappears. This is interesting, and suggests that the problem is in this template, in some subtle manner. -- Red rose64 (talk) 21:35, 13 September 2013 (UTC)
 * The error message was due to the issue described at Template:Reflist. Since both instances of the template were parameterless, for the second instance MediaWiki just reused the cached output from the first use. Which means the references declared after the first use were never actually shown by a, which results in that error message. Anomie⚔ 03:33, 14 September 2013 (UTC)
 * So, is there any chance of a more appropriate Cite error message for this case? HairyWombat 19:30, 15 September 2013 (UTC)
 * No. More likely would be for the parser to be fixed so that Cite can somehow mark the output of as uncachable. Anomie⚔ 00:34, 16 September 2013 (UTC)

Whitespace
There is a hard return after the closing noinclude which causes whitespace on some layouts. SchmuckyTheCat (talk) 04:50, 7 June 2013 (UTC)
 * That "hard return" is automatically added by MediaWiki when the page is saved and cannot be removed. If you check, you'll find it is present in all templates. Anomie⚔ 10:24, 7 June 2013 (UTC)
 * I thought it was stripped when you save the page, along with any terminal whitespace. Regardless, please provide examples of where this is a problem. --  Gadget850talk 11:29, 8 June 2013 (UTC)
 * I misspoke. All terminal whitespace is stripped when it is stored in the database. But a newline is added on when the edit form is created. Anomie⚔ 14:03, 8 June 2013 (UTC)
 * OK, so what we're discussing is not a characteristic peculiar to, but a normal feature of the MediaWiki edit window? My own observations over the last four years show that when you edit a section, terminal whitespace is adjusted twice. The first occurs when the edit window is opened and loaded; the second when a save is committed. In both cases, any whitespace at the end of the text being edited is reduced to a single newline, but when you save a section that is not the last section, a second newline is added. -- Red rose64 (talk) 15:10, 8 June 2013 (UTC)
 * This is documented somewhere, but I can't find it. --  Gadget850talk 15:44, 8 June 2013‎ (UTC)

I still see the surplus line-break too. I suggest this fix:
 * ... decimal}}}}};">{{#tag:references ...

just to remove one EOL --Franta Oashi (talk) 02:10, 18 October 2013 (UTC)
 * I tried that at {{tlx|reflist/sandbox}} using a slightly different technique - I wrapped the line break inside comment markers  But at Template:Reflist/testcases, I see no difference from that at Template:Reflist/testcases - the line breaks are the same; moreover, the spacing between the heading and the first ref, and between the last ref and the next heading, is consistent with other article sections. Can you upload a screenshot of a page where you see an additional line break? -- Red rose64 (talk) 08:37, 18 October 2013 (UTC)
 * You probably wouldn't see any difference due to HTML Tidy tidying up. — Edokter  ( talk ) — 19:30, 18 October 2013 (UTC)
 * I knew that; I'm trying to find out how and where users like {{user|SchmuckyTheCat}} and {{user|Oashi}} are seeing these extra linebreaks, which I am unable to reproduce. -- Red rose64 (talk) 09:16, 19 October 2013 (UTC)
 * I did not make any note about such case, and I did not link it here neither, before... My fault. Now I do not remember. I am sorry. --Franta Oashi (talk) 12:04, 31 October 2013 (UTC)