Template talk:Reflist/Archive 26

Vertical whitespace
Looks like this template is causing extra whitespace below the references when used like this:

Charles B. Rangel page white space
Anyone understand why this template calling a 'nb' section followed by the reference section call have so much white space between the two sections? What can be done about it? This is how the source looks and there is 15 cm of white space before the References section ==Notes==

Columns
It has now been been over 30 days since Category:Articles using fixed number of columns in reflist has been created, and about 262,500 articles are showing up there. The problem of too many columns showing up on mobile devices has been solved, apparently with a CSS change. Hurray! Even if only 1% of mobile users look at references (I certainly do), then this has greatly improved the experience for many thousands of people.

Taking a look at how articles are using a fixed-number-of-columns parameter, many have |2, but some have |3 and some even have |1. In some cases these choices look bad even in medium-sized browser windows, such as setting 2 or 3 columns when there is only one reference. If the point of having multiple columns is to save vertical space, setting 2 columns is not optimal for very wide monitors, which can accommodate 4 or 5 columns.

MOS:ACCESS says "The lowest resolution that it is considered possible to support without adversely affecting other users is 1024×768". At that resolution, |3 makes columns that are uncomfortably narrow. In this case, I would argue that letting the browser decide the number of columns at resolutions smaller than this doesn't adversely affect users with larger screens; arguably it actually improves their experience. That opens the door to considering even lower resolutions. To my eye, at 800x600, another common older or table resolution, |2 produces columns that are uncomfortably narrow.

I think what is happening is that sometimes editors are choosing a fixed number of columns that looks good on their own screen, but doesn't work well for other users at different sizes and resolutions. This to me argues against having fixed-number-of-columns available as an option at all for footnotes, unless there is a particular page or topic I haven't seen yet where it is clearly needed. Variable-number-of-columns to my eye works pretty well for all of the different citation formats, whether long or short, so I don't see why it would be a problem for any page that is already using columns.

It's unclear that multi-column layout is actually needed to save vertical space, and the majority of articles use the default single column. However, if we are to have multi-column footnotes, it makes sense to me to have the same layout rules across all multi-column-footnote articles. This makes the site look better by avoiding common layout mistakes, makes the site look better at a wider variety of browser widths, and makes the site a little bit easier to read through consistency - once familar with the format, readers won't have to re-adjust to a different format on a different article. If we want to compare our eye-appeal and ease of use to commercial encyclopedias and academic journals, certainly I would expect a professionally laid-out publication to be very consistent. Even if we aren't forcing all single-column articles to be multi-column or vice versa, at least we're starting to move toward more harmonious uniformity.

Here is my proposal:


 * Get community approval through a more high-profile discussion, as well as bot approval, before changing hundreds of thousands of pages.
 * Leave the default for this template (no parameters) as single-column.
 * Mark the fixed-number-of-column parameter as "deprecated" in the template's documentation.
 * Have a bot go through and change all the pages which are currently using fixed-number-of-columns parameters.
 * Any page which currently uses |1 would have that parameter deleted, since that is the current default.
 * Any page which has 4 or fewer references, remove the multi-column parameter to make the list single-column.
 * Any page which has 5 or more references, convert |2, |3, etc. to |30em.
 * Use an edit summary which points to the community decision.
 * Based on community reaction and reverting of edits to use fixed column on pages the bot changed, determine whether or not there are any pages that actually need the fixed-number-of-columns parameter. If there is consensus to do so, make the fixed-number-of-columns parameter non-functional (defaults to single-column).

-- Beland (talk) 00:51, 5 May 2014 (UTC)
 * I would not set the lower limit for multiple columns at 5, but at 10 or 12. -- Red rose64 (talk) 10:16, 5 May 2014 (UTC)


 * Hi Beland, I think lots of editors prefer using columns, so we would need consensus to start changing things and calling them deprecated. Whenever I've used 30em, it turns into one list if you narrow the browser window even a little. If there are lots of refs, that makes them harder to read. SlimVirgin (talk) 23:35, 8 May 2014 (UTC)
 * you must have either a large font, or a narrow screen (such as a handheld). 30em is this wide so a reflist should only drop to one column if the available width is less than about twice the width of that bar. On my five-year-old desktop with a 1280-wide screen, and Wikipedia serving me a 12.7px font, there's room for three of those side by side, so  gives me three columns. -- Red rose64 (talk) 08:13, 9 May 2014 (UTC)
 * Hi, it's not screen width that I've found to be issue but width of the browser window. If you have several windows open at once to compare the refs between articles (checking them, moving them over, etc), you narrow the windows so you can see more than one set of refs. Having the columns suddenly disappear is a nuisance; and when they are long refs it can make them harder to read.
 * Remember that there's the bit to the side of the window with the toolbox, other language links, etc. Add that to the double width you measured above, and you don't have to narrow the window by much for the columns to disappear. SlimVirgin (talk) 00:23, 10 May 2014 (UTC)
 * That's one reason why I use narrower columns where possible - such as 20em at NBR 224 and 420 Classes. -- Red rose64 (talk) 00:27, 10 May 2014 (UTC)
 * I get three columns there at all widths. I put in some long refs and previewed, and they were still three at normal width (and hard to read), and only went to two when the window was very narrow.
 * What is the benefit of not using two fixed columns? SlimVirgin (talk) 00:38, 10 May 2014 (UTC)
 * I get four columns at NBR 224 and 420 Classes. I think that 's laptop - which is widescreen - shows more than four; I think that also has a widescreen laptop, and may also be able to confirm that. Which browser are you using that imposes three columns at all widths?
 * A fixed number of columns has the main problem that you are assuming that the screen is wide enough for that exact number of columns. As has been discussed in several venues - see the lengthy above - it is better to inform the browser how wide you would like the columns to be, and let it work out how many columns can be fitted into the available width. -- Red rose64 (talk) 10:25, 10 May 2014 (UTC)
 * At NBR 224 and 420 Classes I see the following:

!Window width (px)!!Columns
 * 640||1
 * 800||2
 * 1024||3
 * 1280||4
 * 1366||4
 * 1600||5
 * 1800||6
 * 1920||7
 * 2048||7
 * 2560||9
 * }
 * I normally use a window 1366px wide, maximised the window is 1920px wide on this HD laptop. Thryduulf (talk) 12:05, 10 May 2014 (UTC)
 * 1800||6
 * 1920||7
 * 2048||7
 * 2560||9
 * }
 * I normally use a window 1366px wide, maximised the window is 1920px wide on this HD laptop. Thryduulf (talk) 12:05, 10 May 2014 (UTC)
 * 2560||9
 * }
 * I normally use a window 1366px wide, maximised the window is 1920px wide on this HD laptop. Thryduulf (talk) 12:05, 10 May 2014 (UTC)
 * I normally use a window 1366px wide, maximised the window is 1920px wide on this HD laptop. Thryduulf (talk) 12:05, 10 May 2014 (UTC)

Redrose, if you have two fixed columns of Smith 2014, p. 1, your screen would have to be tiny not to be able to accommodate that. Even a longer cite – John Smith, Book title, Publisher, 2014, p. 1 – can be read comfortably in two columns on most screens. It would only be on mobile that it might be a problem, and as I understand it columns no longer show up on mobile. SlimVirgin (talk) 17:44, 10 May 2014 (UTC)


 * That may change (see TheDJs proposal above). And there are tiny screens out there. And going to the other side; 'only' two columns of Smith 2014, p. 1 on a 2560px wide screen is also not desirabe. That is why we promote flexible columns so much. — Edokter  ( talk ) — 19:52, 10 May 2014 (UTC)


 * I agree with Slim. On both my PC and my iphone, a forced two columns is superior to a 30em ... which in both cases yields one column.  I also agree with Slim that before calling the forced column approach "deprecated", since it affects a quarter of a million articles and many editors across the Project use it, we would need a Project-wide discussion such as the one we had for date formats. Epeefleche (talk) 06:22, 11 May 2014 (UTC)
 * Despite the lack of consensus on this point, an editor keeps on going into long-established articles and changing the format from the initially chosen (years ago) 2-column format, as here. He charges that the 2-column approach is simply verboten. That's a disruptive back-and-forth waste of time, reminiscent of the date wars on wp years ago. I urge such behavior stop, absent project-wide discussion and project-wide agreement on adoption of a single format. Epeefleche (talk) 19:47, 21 May 2014 (UTC)
 * No one has claimed that it's "verboten", but it is deprecated, and for good reason. Rather than engaging in "a disruptive back-and-forth waste of time", you could accept that what was initially chosen years ago is no longer considered good practice. Nikkimaria (talk) 20:14, 21 May 2014 (UTC)
 * Nikki -- you keep on reverting the age-old practice, and claiming it "is no longer considered good practice," as though there has been a proper community-wide discussion for this. This impacts the community.  If you want to start a community-wide discussion, as we had for date formats, that would be great.  But I haven't seen the consensus you claim.  So the back-and-forth waste of time is the one prompted by you, without support of community consensus, changing articles to the format you prefer.  That's not the best way forward. Epeefleche (talk) 17:51, 9 June 2014 (UTC)


 * I'd like to ask Nikkimaria to stop removing columns and reverting when they're restored. I often use them with indenting when I use manual short refs. Because manual, the short refs aren't linked to the long refs. Therefore, the surnames of the sources have to be easy to find at a glance. Using columns and indenting makes the names easy to spot. Example here. If you remove the columns, the indenting doesn't work so well (or at all), and the references section turns into one flat list, with the surnames not so easy to see. I'd therefore like to be able to continue using the columns/indenting style. SlimVirgin (talk) 17:14, 29 June 2014 (UTC)
 * Does anyone know why Slim is having this issue? The indents work fine for me either way, and I've not seen anyone else complain of that particular problem. Nikkimaria (talk) 01:10, 30 June 2014 (UTC)


 * As I wrote here on Nikki's talkpage, "I agree with SlimVirgin. I would also note that this issue has been raised on Nikki's talkpage (and other talkpages) a number of times. By various editors. Including here and here and here."

For some reason not made evident in Nikki's edit summary, Nikki then deleted my comment here. Nikki's edit summary said only "re". When Slim then wrote: "I don't know whether you intended to remove Epeefleche's post, but it makes clear that there isn't consensus to deprecate columns, so people are allowed to use them....," Nikki failed to respond--though Nikki went on to discuss other matters. From the above I assume Nikki has already read what I wrote, and that Nikki (before even posing the above comment) recalls from that the issue Slim raises with Nikki's columns format changes (and deprecation assertions) is one other editors have raised concerns about to Nikki. Epeefleche (talk) 02:55, 30 June 2014 (UTC)

Caching fixed
We finally have a resolution for. It is scheduled for deployment with MediaWiki 1.24wmf8 on June 21 12. This means that 1 will no longer be needed. --  Gadget850talk 10:33, 9 June 2014 (UTC)
 * Good. Of course, out of 10 zillion articles there's one that somehow relies on the current behavior. If anyone complains about that we'll just have that person killed. We lose editors all the time so one more won't make a difference.
 * Whose job is it to add the new NOTEMPLATECACHE to templates as needed?
 * I'm trying to think where, other than reflist and its relations, this would be needed. I can't think of any offhand.
 * I assume that NOTEMPLATECACHE disables caching only for the template in which it occurs -- doesn't dump the whole template cache, which would be close to catastrophic. I don't really imagine such a blunder would happen but I guess I'd like to hear that for sure.
 * EEng (talk) 17:33, 9 June 2014 (UTC)
 * Unless I am misreading this, NOTEMPLATECACHE was a suggestion that was never implemented. Rather, was updated to "mark the output of  and  as volatile so that caching can be avoided." We don't need to do anything to the templates other than wait until this is deployed. And then update the documentation. Current uses of 'close' do no harm, but can be added to AWB for removal. --   Gadget850talk 19:50, 9 June 2014 (UTC)
 * "I cant see that NOTEMPLATECACHE will be - someone did suggest it, but the solution is different. See Christian75 (talk)
 * Um, what did you say? EEng (talk) 21:35, 9 June 2014 (UTC)

Ah, I see. I think you'll understand how, by reading just the link Redrose Gadget  [corrected]  gave, I misunderstood what the fix was really going to be. EEng (talk) 21:35, 9 June 2014 (UTC)
 * Which link would that be? I've not previously commented in this thread, nor in the one which presumably prompted it. -- Red rose64 (talk)
 * Gadget, Redrose, whatever... you templategeeks all run together. EEng (talk) 23:35, 12 June 2014 (UTC) (And I say that with all affection, of course.)
 * I guess the user in http://xkcd.com/1172/ would demand a 0 option now. PrimeHunter (talk) 10:28, 10 June 2014 (UTC)
 * This was not deployed in 1.24wmf8. --  Gadget850talk 20:45, 12 June 2014 (UTC)
 * You think that's fiction? I hate war stories, but I'll offer one now. System [redacted] had a bug under which the system clock would lose a few seconds a day if (a) the configuration included between 112K and 128K of core (yes, core) and (b) the system was idle for significant periods of time. I fixed the bug and got a complaint for doing that because the a side effect of the fix was that the system would wake up a few milliseconds faster coming back from idle. Apparently this upset the timing of some home-grown communication protocol. EEng (talk) 23:35, 12 June 2014 (UTC)
 * 1.24wmf9 is now deployed, but this fix is not. --  Gadget850talk 18:38, 20 June 2014 (UTC)
 * Yes it has been. See https://en.wikipedia.org/w/index.php?oldid=613719402 Jackmcbarn (talk) 18:41, 20 June 2014 (UTC)
 * You are correct. Had to purge my test page. Not in the change log though. --  Gadget850talk 18:52, 20 June 2014 (UTC)

So should we take out all that close stuff from the documentation and just explain it's obsolete? EEng (talk) 02:02, 23 July 2014 (UTC)
 * I just removed it.  07:47, 23 July 2014 (UTC)

Use of #tag:references with a group causes a footnote numbering issue
- Cite: Use of #tag:references with a group causes a footnote numbering issue

{{markup

{{#tag:references|
 * group=u}}

08:53, 30 December 2014 (UTC)

Errors when trying to make segregated reflists
When I tried to add a section about multiple citations for the instructions manual for this Reflist template, the reflists end up on the bottom reflist. How can you make two different reflists segregated from each other in one article. Multiple citations, ones with " " and " " in it.
 * This is already covered in . Your example had multiple errors, including defining the same reference twice, and using a reserved group name.  10:00, 11 February 2015 (UTC)