Template talk:Reflist/Archive 11

Archive 5

←

Archive 9

Archive 10

Archive 11

Archive 12

Archive 13

→

Archive 15

Multiple reflists

A desirable feature, it seems to me, would be the option of adding reflists at the bottom of sections within long articles (or indeed talkpages). A problem with this shows up in my sandbox which has a paragraph with 3 notes followed by an unrelated paragraph with 1 more: one would hope for the new footnote to show up as #1 of the second reflist and maybe expect 1 thru 4 instead, but instead gets only the original reflist 1-3 and no new footnote. Is there a different tool for this job? Sparafucil (talk) 04:56, 3 February 2009 (UTC)

The behavior of references and the reference list is controlled by the MediaWiki software. This template only adds style/formating to the reference list. As far as I know you can't change this behavior from within Wikipedia, although you might be able to discuss a change of the MediaWiki software somewhere. (on the MediaWiki site I would think).
—Apis (talk) 06:58, 3 February 2009 (UTC)

But, if your page were in articlespace, you would see a big red cite error at the bottom of the page. --—— Gadget850 (Ed) ^talk - 10:25, 3 February 2009 (UTC)

Just stumbled on this which seems to do the job: <ref group = S> </ref>, followed by <references group = S> . Sparafucil (talk) 23:18, 17 February 2009 (UTC)

List of zombie movies

Resolved

The article List of zombie movies uses this tag, but appears to be missing quite a few references. Any thoughts on how we may correct this? Thanks. Surv1v4l1st ^{(Talk|Contribs)} 23:44, 25 February 2009 (UTC)

You forgot to close an {{imdb title}} template. I stuffed <references /> into it in multiple sections and previewed it until I saw where it blew up. --—— Gadget850 (Ed) ^talk - 00:02, 26 February 2009 (UTC)

I didn't change the references list myself, but just noticed that it was messed up. Thanks for correcting it and for letting me know what to look for in the future. :) Surv1v4l1st ^{(Talk|Contribs)} 00:11, 26 February 2009 (UTC)

Is something wrong here?

Can someone please take a look at this question regarding the article Post-rock at the help desk and see if it's something wrong with the template? Here's the question, posted by Nanonic (talk · contribs)

I was just randomly browsing around as one does and came across the article Post-rock. It uses the multi-column reference list functionality of {{reflist}} and is set to display two columns which works on my Firefox fine. What is puzzling me though is that this reflist display is lopsided, in all the other articles in which i've seen reflist used with 2 columns - the template automatically balance the columns out to avoid whitespace. {{reflist}} and {{reflist|3}} work fine on preview without leaving any whitespace, so why isn't {{reflist|2}}?

I've checked with several other articles using it, and they seem OK. Only this article shows the unbalanced columns. Chamal ^talk 11:48, 26 February 2009 (UTC)

Odd. When I first looked at it, column one broke at ref 22. making column 2 half the height. I opened it for editing and previewed it and column one broke at ref 17, making the columns even. I made no edits, but refreshed the page and now the columns are even. --—— Gadget850 (Ed) ^talk - 12:11, 26 February 2009 (UTC)

I'm surprised that two people would both have this problem at once. The column-balancing isn't even done by the server, it's done by the browser. Algebraist 12:36, 26 February 2009 (UTC)

Actually, three; I saw it until I refreshed the page. I don't believe I have ever viewd that article. --—— Gadget850 (Ed) ^talk - 14:06, 26 February 2009 (UTC)

• It's not working for me in IE 7 on Windows XP on the article Walt Whitman. Very annoying on that article due to long list of references.--Larrybob (talk) 17:43, 26 February 2009 (UTC)

Of course it isn't. As it says in the documentation, IE doesn't support columns. Algebraist 17:45, 26 February 2009 (UTC)

I'm now on a different XP box using FF3 and am seeing the same break at ref 17. I did a purge and a bypass with no effect. This time an edit has no effect. --—— Gadget850 (Ed) ^talk - 02:52, 27 February 2009 (UTC)

This is just odd. I am on my home PC. This morning, the reflist breaks at #17. I do a bypass and it breaks at #22. I click edit and the preview breaks at #17, click article and it stays at #17. I can consistently switch between the two breaks. While it breaks at #22, if I click on any backlink in the reflist, it magically changes to break at #17. The only thing I can remotely see that might look wrong is the HTML output for #32:

<li id="cite_note-31"><b><a href="#cite_ref-31" title="">^</a></b> <cite style="font-style:normal" class="web"><a href="http://www.sigur-ros.co.uk/band/faq.php#07" class="external text" title="http://www.sigur-ros.co.uk/band/faq.php#07" rel="nofollow">"Sigur Ros frequently asked questions"</a>. Eighteen Seconds Before Sunrise<span class="printonly">. <a href="http://www.sigur-ros.co.uk/band/faq.php#07" class="external free" title="http://www.sigur-ros.co.uk/band/faq.php#07" rel="nofollow">http://www.sigur-ros.co.uk/band/faq.php#07</a></span><span class="reference-accessdate">. Retrieved on 2006-11-28</span>.</cite><span class="Z3988" title="ctx_ver=Z39.88-2004&amp;rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&amp;rft.genre=bookitem&amp;rft.btitle=Sigur+Ros+frequently+asked+questions&amp;rft.atitle=&amp;rft.pub=Eighteen+Seconds+Before+Sunrise&amp;rft_id=http%3A%2F%2Fwww.sigur-ros.co.uk%2Fband%2Ffaq.php%2307&amp;rfr_id=info:sid/en.wikipedia.org:Post-rock"><span style="display: none;">&#160;</span></span></li>

If we compare this to #34, we see that #32 has no id.

<li id="cite_note-33"><b><a href="#cite_ref-33" title="">^</a></b> <cite style="font-style:normal" class="web" id="CITEREFCaramanica2005">Caramanica, Jon (2005-09-20). <a href="http://www.iht.com/articles/2005/09/19/features/heavy.php" class="external text" title="http://www.iht.com/articles/2005/09/19/features/heavy.php" rel="nofollow">"The Alchemy of Art-World Heavy Metal"</a>. <a href="/wiki/International_Herald_Tribune" title="International Herald Tribune">International Herald Tribune</a><span class="printonly">. <a href="http://www.iht.com/articles/2005/09/19/features/heavy.php" class="external free" title="http://www.iht.com/articles/2005/09/19/features/heavy.php" rel="nofollow">http://www.iht.com/articles/2005/09/19/features/heavy.php</a></span><span class="reference-accessdate">. Retrieved on 2007-09-28</span>.</cite><span class="Z3988" title="ctx_ver=Z39.88-2004&amp;rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&amp;rft.genre=bookitem&amp;rft.btitle=The+Alchemy+of+Art-World+Heavy+Metal&amp;rft.atitle=&amp;rft.aulast=Caramanica&amp;rft.aufirst=Jon&amp;rft.au=Caramanica%2C+Jon&amp;rft.date=2005-09-20&amp;rft.pub=%5B%5BInternational+Herald+Tribune%5D%5D&amp;rft_id=http%3A%2F%2Fwww.iht.com%2Farticles%2F2005%2F09%2F19%2Ffeatures%2Fheavy.php&amp;rfr_id=info:sid/en.wikipedia.org:Post-rock"><span style="display: none;">&#160;</span></span></li>

I have no clue if this is related to the issue. --—— Gadget850 (Ed) ^talk - 12:25, 27 February 2009 (UTC)

I can confirm the problem, in my case also breaking at #22. Incidentally, #34 has an id through {{citation/core}}. #32 doesn't invoke {{citation}}, ergo doesn't get an id. Aside: that article's reflist doesn't benefit from multiple columns (indeed, it suffers for it), so why does it have them? -- Fullstop (talk) 13:33, 27 February 2009 (UTC)

How does it suffer from the multiple columns? Algebraist 13:35, 27 February 2009 (UTC)

The question you should be asking is "How does it benefit from them?" Proponents of multi-column abuse may prefer to see such a question reformatted as...

How does		This is
it benefit		very reader
from them?		unfriendly.

Just curious: what resolution are you driving your monitor with? -- Fullstop (talk) 14:19, 27 February 2009 (UTC)

That is indeed a relevant question, but since you asserted it suffers for it, I thought I'd ask why. Incidentally, why do you assume I support multicolumning? Algebraist 14:39, 27 February 2009 (UTC)

I didn't assume that. My question stems from an idea that there is perhaps a correlation between display real-estate and preference for multi-column even for non-abbreviated (i.e. non-harv) ref style. -- Fullstop (talk) 14:59, 27 February 2009 (UTC)

My apologies if you weren't assuming that (which would've been wrong); you appeared to me to be doing so. Do you intend to answer my question? Algebraist 15:54, 27 February 2009 (UTC)

You mean why they suffer? I thought that would be obvious from my example. They are hard to read (on screen). -- Fullstop (talk) 16:09, 27 February 2009 (UTC)

Is this a problem with all multicolumn reflists, or just some? If all, then disable them. If some, then which are OK? Algebraist 16:17, 27 February 2009 (UTC)

Ok are those with abbreviated refs, i.e. harvnb et al. Even with 3 columns, these are sufficiently far apart that they don't become a mass of blue/black pudding. But here I am being compelled to bitch about something that shouldn't even exist, and when it is really the insanity that needs to legitimize itself. Its like a non-smoker being compelled to justify why smoking sucks. Sheesh! -- Fullstop (talk) 17:00, 27 February 2009 (UTC)

Thanks. Algebraist 17:11, 27 February 2009 (UTC)

Having a fiddle on my own, I stripped all the sources out individually, removed any duplicates and put them on User:Nanonic/postrock sources - you can see here that on their own, the template works as normal thus ruling out any potential errors in individual ref formatting. I then rearranged the text of the article to put the references in their logical order (in some cases <ref name="blah"/> was before <ref name="blah">this is the reference</ref>) and removed the images and placed that at User:Nanonic/postrock sandbox, you can see the problem still exists thus ruling out any template/infobox conflicts or placement wierdness. I then stripped out all of the text leaving just the references (including their duplicates) and placed that at User:Nanonic/postrock sandbox stripped. Again the problem still exists, so I thought perhaps it is something to do with the way these interact with each other. I spaced each reference out onto it's own line in and placed it on User:Nanonic/postrock sandbox stripped segregated and it still fails. So I went back to the sandbox and started removing references one by one and funnily enough - if you add or remove ONE reference from the end of the article it seems to balance out fine but I'm still none the wiser as to the reason this is failing on this article, but as a stab in the dark, could it be something to do with those multi-calls to the same ref name? Nanonic (talk) 13:45, 27 February 2009 (UTC)

It always breaks at ref 22 for me. And as Gadget850 reported, if you click on the backlink at the ref, it balances itself. Chamal ^talk 13:49, 27 February 2009 (UTC)

I'm now on my work PC running XP and FF3 and am seeing the same thing. --192.112.210.250 (talk) 13:57, 27 February 2009 (UTC)

For the main article, I see the same thing as Chamal_N describes, including reflow on backlink-click. All the User:Nanonic/postrock* except User:Nanonic/postrock sandbox are ok. /postrock sandbox has the same #22 problem as the article. -- Fullstop (talk) 14:24, 27 February 2009 (UTC)

Daeva#References seems to have the same problem. Second column starts at #16 (of total 18 refs). -- Fullstop (talk) 11:44, 11 March 2009 (UTC)

Same problem at Street newspaper#References. I posted a message about it at the village pump: WP:VP/T#Columns in reflist going crazy. The problem seems to have something to do with spaces within quotes in the title of a ref: for example, "Real Change's transformation includes plan to reach readers" causes a problem, but Real Change's transformation includes plan to reach readers and "Real_Change's_transformation_includes_plan_to_reach_readers". The problem is not unique to {{reflist}}; it also happens even if you use <div class="references-small" ...etc> manually. This shit is messed up, man. rʨanaɢ ^talk/_contribs 18:58, 4 April 2009 (UTC)

{{reflist|2}}

{{reflist|2}} does not create 2 columns on the computer in my university library, although it does on my computer at home. Maybe it's just Internet Explorer failing like usual (I use Firefox at home), but I just thought I'd give a heads up that they aren't appearing correctly on some machines. hmwithτ 17:51, 15 April 2009 (UTC)

Yes, IE doesn't support the multi-column CSS. See the template documentation for details. Anomie⚔ 22:26, 15 April 2009 (UTC)

two columns

Why does {{reflist-2}} work in Google Chrome, but {{reflist|2}} doesn't? — pd_THOR ^{| =/\=} | 02:21, 26 March 2009 (UTC)

Because, for some reason, they work in totally different ways. {{reflist-2}} uses <div class="references-2column">. MediaWiki:Common.css gives the class "references-2column" the styles "-moz-column-count: 2; -webkit-column-count: 2; column-count: 2;" (there are three different styles because browsers differ and this should work on as many as possible). {{reflist|2}}, on the other hand, doesn't rely on the sitewide stylesheets and just directly adds the styles "-moz-column-count:2; column-count:2;". Presumably the style recognized by Chrome is "-webkit-column-count", which is unaccountably absent from {{reflist}}. Algebraist 02:38, 26 March 2009 (UTC)

To quote from the documentation:

• Safari 3.1.2, Google Chrome and possibly other WebKit based browsers have a bug that breaks links in multiple columns; the column feature has been removed for these browsers until the bug is resolved; see Template:Reflist/Safari testcase for details.

Once the bug is fixed in a released version of both Safari and Chrome, -webkit-column-count may be re-added. Anomie⚔ 02:52, 26 March 2009 (UTC)

It should also be removed from .references-2column in Common.css, then. Algebraist 02:59, 26 March 2009 (UTC)

FYI, I have just done this. —TheDJ (talk • contribs) 12:26, 12 May 2009 (UTC)

I just confirmed that this is still a bug in Safari 4.0 beta. ---— Gadget850 (Ed) ^talk 18:13, 12 May 2009 (UTC)

Font-size (in IE)

The documentation makes a false assumption that it will not display smaller font-size in IE, partly due to the CSS in common.css. This is not true; IE does show a smaller font, it is just hardly noticable. This is because 90% shows virtually no differeent; the actual size isn't changed, only a slight difference in spacing is applied. If you actually want to show a smaller font in IE, as it would in Firefox and other browsers, make the font-size 88%. That would trigger IE to use a smaller font as well, while retaining the fontsize in other browsers, making it consistent across browsers. See Template:Reflist/testcases for the result. — Edokter • Talk • 12:58, 12 May 2009 (UTC)

I added that. Without {{reflist}}; the reference section will look like:

<ol class="references">

<li id="cite_note-0"><b><a href="#cite_ref-0" title="">^</a></b>Reference content</li>
</ol>

But with {{reflist}}, the output is going to look like this:

<div class="references-small">
<ol class="references">

<li id="cite_note-0"><b><a href="#cite_ref-0" title="">^</a></b>Reference content</li>
</ol>
</div>

Here we have two competing font sizes defined by:

• ol.references { font-size: 100%;}
• .references-small { font-size: 90%;}

I will look at this again, but I think that IE7 honored ol.references. I'm sure this issue is buried in the archived discussions. If you look through the history of common.css, you will find that ol.references was originally set to font-size: 90%; but later changed to font-size: 100%;. ---— Gadget850 (Ed) ^talk 14:13, 12 May 2009 (UTC)

100% of a parent font-size does nothing; you will find that it should and does show at 90%. Why ol.references is even there is beyond me, as it does not override another font-size in that same class, so it is completely useless. — Edokter • Talk • 14:25, 12 May 2009 (UTC)

I see where you are setting the font size now, and it does work with IE7. I have previously questioned the need for ol.references before, since it is already a default— I recommend that we delete it and change MediaWiki:Cite references prefix that inserts it into the output. As best I see, it was added to set the font size before {{reflist}} was created. It was originally set to 90%, but someone objected and changed it to 100%. BTW: I have pieced together the MediaWiki messages that format the references at User:Gadget850/Cite messages. ---— Gadget850 (Ed) ^talk 14:32, 12 May 2009 (UTC)

I just set it inline in the sandbox to serve as an example. I have also set it in my monobook.css, simply by setting the font-size to .references-small. Basic rule in Cascading Style Sheet is that relative values are calculated against their parent element (hence the cascading). I think the misunderstanding about not working in IE(7) is the fact that 90% simply does not have a noticable effect in IE.

I think ol.reference can be safely removed from Common.css. What would need to be changed MediaWiki:Cite references prefix? The class could come in handy sometime. — Edokter • Talk • 14:46, 12 May 2009 (UTC)

I was thinking the only use of ol.references was for the font size, but it is also used to highlight the target citation in the reference list. ---— Gadget850 (Ed) ^talk 15:12, 12 May 2009 (UTC)

So that needs no changing then (I struck it out), while ol.references can be safely removed from Common.css. The big question remains though: would there be a consensus to change .references-small font-size to 88%? I did change it once in Common.css, but was naturally reverted, because some people "suddenly coudn't read it anymore" (as if those using Firefox never could). I'll pose the question on MediaWiki talk:Common.css. — Edokter • Talk • 15:34, 12 May 2009 (UTC)

And there was much rejoicing. I will update the documentation here on both issues when the font size is changed. ---— Gadget850 (Ed) ^talk 17:35, 12 May 2009 (UTC)

I already removed the reference to ol.references. — Edokter • Talk • 17:44, 12 May 2009 (UTC)

Multicolumn in print

To avoid this problem, I was thinking about adding some CSS to MediaWiki:Print.css so that columns are NEVER used in printing pages. Since FF is currently the only browser properly supporting multicolumn at all, I don't think this should be a large issue. The proposed code that I would add is the following:

.references-column-count, .references-column-width {
    column-count:1 !important;
    column-width:auto !important;
    -moz-column-count:1 !important;
    -moz-column-width:auto !important;
}

If I do this, then note of this should probably be made in this template's documentation. —TheDJ (talk • contribs) 12:38, 12 May 2009 (UTC)

I would suggest

.references-small, .references-2column {
    column-count:auto !important;
    column-width:auto !important;
    -moz-column-count:auto !important;
    -moz-column-width:auto !important;
    -webkit-column-count:auto !important;
    -webkit-column-width:auto !important;
}

This doesn't have to rely on those (pretty useless) classes, and should work with the references-2column class too. Also, since WebKit supports multicol too, I'd add code for them to be sure, —Ms2ger (talk) 16:02, 12 May 2009 (UTC)

I was just considering getting "references-2column" removed alltogether :D I don't see what it is needed for. —TheDJ (talk • contribs) 18:55, 12 May 2009 (UTC)

It is used in {{Reflist-2}}, which is used in only a few articles. I was just considering putting it up for deletion and converting those articles. ---— Gadget850 (Ed) ^talk 19:07, 12 May 2009 (UTC)

It also used to be used directly in articles; has anyone downloaded a recent dump and checked if those have all been replaced? Anomie⚔ 00:55, 13 May 2009 (UTC)

I thought that problem was fixed some time ago? (in such a way that it wrapped?) If not, wouldn't it affect ordinary pages as well? I'm not very fond of multiple columns in general because they tend to be misused with bad layout (and thus become less accessible) as a result. Still, there are some cases when multiple columns are motivated (eg. shortened footnotes). If multiple columns were applied correctly there wouldn't be any need for this. I'm not really against doing this change because I think the way {{reflist}} is currently used is causing more problem than it solves, but it seems kind of pointless to only fix it for printed pages? (Except no one will notice in this case, so no one will complain?) :/
—Apis (talk) 04:19, 13 May 2009 (UTC)

In print, we have the URLs, and those don't wrap properly in several cases. (possible because the columns are not fully updates after we tell that the urls should be fully added). —TheDJ (talk • contribs) 10:49, 13 May 2009 (UTC)

Shortened notes in articles such as Learned Hand is a very valid use of columns. Please don't disregard printing- more people print articles than you might think, and this applies to the new PDF tool as well. ---— Gadget850 (Ed) ^talk 11:03, 13 May 2009 (UTC)

I didn't mean to disregard printing, I think printing is important, but I suspect doing a change like that wouldn't get a lot of attention (and consequently not a lot of discussion which might be bad.) Kind of like introducing changes that only affect a single browser and thus only a small part of the users. Also, Learned Hand is a terrific example of when not to use columns, since they combine shortened footnotes with long citations and explanations. That means much of the footnote-text is on 1-3 word lines which is really annoying if you actually want to read it. In that case they would probably be better off with a single column (or at least two instead of three)
—Apis (talk) 14:23, 13 May 2009 (UTC)

(P.S. It doesn't have to be 1-3 lines on your computer, it depends on screen resolution, size of the browser window, text-size, and so on. The idea of having a fixed number of columns and not a fixed column width is the fundamental flaw here.)
—Apis (talk) 14:33, 13 May 2009 (UTC)

Ok, it just feels like solving the wrong end of the problem. That is: badly formated citations, and misuse of columns.
—Apis (talk) 14:23, 13 May 2009 (UTC)