Template talk:Reflist/Archive 11

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)

—Apis (talk ) 06:58, 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).


 * 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:, followed by

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

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 . #32 doesn't invoke , 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... 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  was before  ) 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.  C h a m a l  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 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. I posted a message about it at the village pump: WP:VP/T. The problem seems to have something to do with spaces within quotes in the title of a ref: for example,  causes a problem, but   and. The problem is not unique to ; it also happens even if you use manually. This shit is messed up, man. r ʨ anaɢ talk/contribs 18:58, 4 April 2009 (UTC)

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 doesn't?  —   pd_THOR  undefined | 02:21, 26 March 2009 (UTC)
 * Because, for some reason, they work in totally different ways. reflist-2 uses . 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)., 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 . 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,  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. —Th e DJ (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:


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


 * Here we have two competing font sizes defined by:


 * I will look at this again, but I think that IE7 honored . I'm sure this issue is buried in the archived discussions. If you look through the history of common.css, you will find that   was originally set to   but later changed to  . ---—  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  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  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 . 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  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  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  can be safely removed from Common.css. The big question remains though: would there be a consensus to change   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 . —  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: If I do this, then note of this should probably be made in this template's documentation. —Th e DJ (talk • contribs) 12:38, 12 May 2009 (UTC)
 * I would suggest


 * This doesn't have to rely on those (pretty useless) classes, and should work with the  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. —Th e DJ (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) —Apis (talk ) 14:23, 13 May 2009 (UTC) —Apis (talk ) 14:33, 13 May 2009 (UTC) —Apis (talk ) 14:23, 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). —Th e DJ (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)
 * (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.)
 * Ok, it just feels like solving the wrong end of the problem. That is: badly formated citations, and misuse of columns.