Template talk:Reflist/Archive 24

Reflistp
I just stumbled across reflistp. I'm trying to understand why this is needed if it isn't to be saved in an article. --  Gadget850talk 21:58, 22 March 2014 (UTC)
 * According to the doc, it is supposed to show only in preview, and should auto-hide after saving, when accidentally left in. — Edokter  ( talk ) — 22:10, 22 March 2014 (UTC)
 * When I'm editing a section, I sometimes want to see how the changes I made to references show up, so I add
 * The  is causing the   element to use   by inheritance, which is almost certainly unintended, because we're using   and not  . I'll look into it further. {&#123; Nihiltres &#124;talk&#124;edits}&#125; 22:39, 13 April 2014 (UTC)
 * Thank you. Darekk2 (talk) 22:45, 13 April 2014 (UTC)
 * The primary cause is that you omitted an equals sign. I fixed them . -- Red rose64 (talk) 22:48, 13 April 2014 (UTC)
 * Thanks again. I didn't notice that, but made this mistake only in few pages, probably only these listed above, becuase few other ones checked just while ago are correct. How it was possible ... Darekk2 (talk) 23:22, 13 April 2014 (UTC)
 * Well spotted. I was getting worried there. The inherit is necessary to enabled custom list styles defined on div.reflist. — Edokter  ( talk ) — 22:52, 13 April 2014 (UTC)
 * Edokter, we should still probably fix the template so that it's sure to apply  whenever we're not specifying custom list styles, shouldn't we? I'm taking a moment to try and parse the  structure of the template; I'm just a little slow right now because I'm busy with a game of D&D. :P {&#123; Nihiltres &#124;talk&#124;edits}&#125; 23:03, 13 April 2014 (UTC)
 * It is already doing that, see the #default value in the #switch: statement. Forgetting the "=" in "refs=" dumps the entire list within the div tag; not a 'fixable' situation, just wrong usage. — Edokter  ( talk ) — 23:16, 13 April 2014 (UTC)
 * Edokter, OK, it took me a while to realize what you were getting at, because at first I thought that the "list-style-type" was somehow inside the #if structure, which would be silly. I thought this because I looked at the source and saw a normal div tag with list-style-type in the latest version of Pika, but not in the preceding one where would return true.
 * So the problem we're actually seeing is that there's elements in the list, and if the list gets dumped straight into the CSS properties by omitting the equals sign, then MediaWiki neatly cleans up the resulting garbage by simply omitting the style attribute. If we're willing to get hackish, there is a fix: specify two style attributes. In the first, specify only the list-style-type, and in the second, specify both the list-style-type and the column properties. If both are valid, MediaWiki will output only the second, with all the properties, but if the second is invalid, the first will still be outputted.
 * The obvious argument against this fix is that it duplicates code to fix a minor problem without fixing the bigger input problem—the best behaviour would be for bad input like this to produce an error string—but it's at least interesting in theory. I bet we could exploit this behaviour to produce an error message if we include an error message that's only present if element attributes would be stripped. Just throwing it out there. {&#123; Nihiltres &#124;talk&#124;edits}&#125; 01:21, 14 April 2014 (UTC)
 * I've just noticed that bullets vs numbers isn't the only difference. The last three references of Pika - those numbered 5, 6, 7 in the fixed version - have their back-links duplicated in the unfixed version. In the bulleted version, there are "a" and "b" back-links for each (the URL fragments are "#cite_ref-Erbajeva11_5-0" "#cite_ref-Erbajeva11_5-1" "#cite_ref-Erbajeva03_6-0" "#cite_ref-Erbajeva03_6-1" "#cite_ref-GuthrieMatthews71_7-0" "#cite_ref-GuthrieMatthews71_7-1"); in the numbered version, there is only the "^" back-link (the URL fragments are "#cite_ref-Erbajeva11_5-0" "#cite_ref-Erbajeva03_6-0" "#cite_ref-GuthrieMatthews71_7-0"). -- Red rose64 (talk) 09:51, 14 April 2014 (UTC)

Yeah, I noticed that too. That's the case because the references are technically there as garbage while everything's being rendered, but then those elements get removed in the cleanup at the end. Thus, there's an incentive to throw some sort of error, or prevent the parameter being dumped into the style attribute in the first place, if the passed parameter isn't appropriate for CSS. My concern is that code for detecting that would be too expensive to justify its use in such a widely-used template. Any other ideas? Anyone with better knowledge of the relative merits of using expensive functions? {&#123; Nihiltres &#124;talk&#124;edits}&#125; 15:15, 14 April 2014 (UTC)
 * The "easy" solution is to disallow any non-numeric numbered inputs into CSS, instead requiring a named parameter for cases like "30em". This would require a bot to update all articles that currently contain that usage, which could be many, many pages … not to mention updating various bits of documentation and probably outputting an error message and/or category for non-numeric numbered inputs once the bot's task was done.
 * The "expensive" solution is to filter the input properly with some sort of string function from Lua; I don't know exactly how bad that would be, but the acceptable input (a valid CSS column width) is so narrow we wouldn't need much string-crunching.
 * The "quick-and-dirty" (but also potentially expensive?) solution if the previous proves too much is a simple Lua length count (acceptable input is likely never over 10–15 characters long) that would output a maintenance category for long inputs, which would be enough for manually fixing instances of this error.

Extra space following reference list
There seems to be an excessive amount of space following the template. When followed by another section, there is quite a gap of white space between the bottom of the list and the heading for the following section. In reading earlier notes, it seems someone else noticed this and thinks they fixed it. I disagree; could someone look at it again? If you want to see the problem, visit Virginia Tech massacre. Thanks for the help!&mdash;D'Ranged 1 talk 14:16, 4 May 2014 (UTC)
 * Looks OK to me: the gap at the bottom of "Notes", which is the one containing, is the same as the gap at the bottom of the preceding section "References" and the following section "Further reading". -- Red rose64 (talk) 14:23, 4 May 2014 (UTC)
 * Please see the image in my Google Drive folder: https://drive.google.com/file/d/0B8w5UlcNH1pGN1Y4MW1lRlJEY2M/edit?usp=sharing. I drew a colored box outlining the gap at the bottom of the "Notes" section and copied and pasted it over the gaps between other sections. There is, at least on my browser, more space after "Notes". I could possibly see where some of the extra space is due to the reduced font size in the footnotes, but not that much, I don't think.&mdash;D'Ranged 1 talk 15:50, 4 May 2014 (UTC)
 * What browser and version? --  Gadget850talk 16:14, 4 May 2014 (UTC)
 * Google Chrome Version 34.0.1847.131 m. More info: I went to an article with a short list of references that just used {{{Reflist}}, Sternwheeler Columbian disaster, and changed the template to . The result was more space after the footnotes than had been there before. Maybe the "|30em" parameter is the problem? Trying to help, here. Thanks for your assistance.&mdash;D'Ranged 1 talk 16:17, 4 May 2014 (UTC)
 * Looking at your examples, they look like the same spacing. Try a screen ruler. You can also try previewing with 30em removed. --  Gadget850talk 16:21, 4 May 2014 (UTC)
 * Gadget850, did you check the photo I provided? There is definitely more space on my screen; however, I viewed the pages in Firefox version 28.0 and the issue isn't there—so some part of this is browser-related. Thanks.&mdash;D'Ranged 1 talk 16:25, 4 May 2014 (UTC)
 * Using a ruler, the difference is more apparent; about 6 pixels. --  Gadget850talk 16:33, 4 May 2014 (UTC)
 * This is a result of how Chrome handles columns. It has a small bug in calculating the required vertical space when  has been applied to individual list items. —  Edokter  ( talk ) — 16:28, 4 May 2014 (UTC)
 * Thank you, Edokter. And thanks to Gadget850 for the screen ruler—very nifty. The gap from the bottom of the last line of text in the Notes section to the rule under the heading of the next section (Further reading) is 70; the gap between Further reading and the following section (External links) is 59. Glad to know I'm not going crazy. Thank you, all, for your attention and assistance. Enjoy your day!&mdash;D'Ranged 1 talk 16:34, 4 May 2014 (UTC)

Reflist in templates
I'm having trouble producing references in a template, and I wonder if someone here knows what to do.

Metaphysical movement has a collapsed timeline and references. What I would like to achieve is a list of references that don't combine with the references in the articles the template is added to, so that the refs in the template show up on the template itself, not in the articles. The reason I want to do that is so that the template refs can use a different format (also because it is odd to have unclickable refs in the article).

When I added the template to Christian Science (using reflist in the template), several of the references in the article showed up in red and said the named refs didn't exist, but they did. I tried template reference list, but that places the template references in the article (unclickable), as well as in the template.

Does anyone know how to achieve the separation? SlimVirgin (talk) 21:00, 8 May 2014 (UTC)


 * You can group references. — Edokter  ( talk ) — 22:07, 8 May 2014 (UTC)


 * Thanks, that has worked in the template, and I've just previewed it in the article and it's not messing anything up there. SlimVirgin (talk) 22:37, 8 May 2014 (UTC)
 * WP:REFGROUP is a better overview, and the following WP:EXPLNOTE might be a better implementation. --  Gadget850talk 23:20, 8 May 2014 (UTC)
 * Thanks Gadget. I tried to understand that page, but couldn't get any of it to work on the template, so I obviously wasn't doing it properly. SlimVirgin (talk) 23:36, 8 May 2014 (UTC)