Template talk:Reflist/Archive 26

Archive 20

←

Archive 24

Archive 25

Archive 26

Archive 27

Archive 28

→

Archive 30

Vertical whitespace

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

==References==
{{reflist|30em}}

==External links==

and extra whitespace above the references when used like this:

'''Online sources'''

{{refbegin|30em}}
* {{citation...}}

Not sure exactly what needs fixing, though. - dcljr (talk) 18:06, 9 May 2014 (UTC)

For the first issue, see #Extra space following reference list. The second is explained by way of the refbegin template adding a newline in the top (which is a temporary issue). — Edokter (talk) — 19:01, 9 May 2014 (UTC)

It's not clear to me why that newline is necessary. Can't the <div> go directly after the }} and so eliminate that newline? --Redrose64 (talk) 23:55, 9 May 2014 (UTC)

Actually, it's time to remove the category. The value has been steady around 250K. — Edokter (talk) — 01:22, 10 May 2014 (UTC)

(Oops. Forgot to say I was looking at it in Google Chrome 34.0.1847.131. Have not checked in FF. Thanks for the replies. - dcljr (talk) 21:26, 12 May 2014 (UTC))

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==
{{reflist|2|group="nb"}}

==References==
{{reflist|2}}

Deleting the linefeed made no difference. 24.241.69.99 (talk) 21:14, 26 June 2014 (UTC)

It's a small Chrome bug, see #Extra space following reference list above. Since items will not split between columns, large items result in large whitespace. I've removed the columns for nb. Hope that helps. -- [[User:Edokter]] {{talk}} 22:47, 26 June 2014 (UTC)

Ah, thanks. Yes, I'm using Chromium port Iron v35. 24.241.69.99 (talk) 21:15, 27 June 2014 (UTC)

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#Resolution 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. --Redrose64 (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)

@SlimVirgin: 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 {{reflist|30em}} gives me three columns. --Redrose64 (talk) 08:13, 9 May 2014 (UTC)

Hi Redrose64, 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#Notes. --Redrose64 (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#Notes. I think that Thryduulf's laptop - which is widescreen - shows more than four; I think that HJ Mitchell 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 #Deprecating fixed number of columns 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. --Redrose64 (talk) 10:25, 10 May 2014 (UTC)

At NBR 224 and 420 Classes#Notes 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)

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 T33834. It is scheduled for deployment with MediaWiki 1.24wmf8 on June 21 12. This means that |close=1 will no longer be needed. --  Gadget850 ^talk 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, Cite was updated to "mark the output of <ref> and <references> as volatile so that caching can be avoided."[1] 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. --  Gadget850 ^talk 19:50, 9 June 2014 (UTC)

"I cant see that NOTEMPLATECACHE will be - someone did suggest it, but the solution is different. See [2] 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)

@EEng: Which link would that be? I've not previously commented in this thread, nor in the one which presumably prompted it. --Redrose64 (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 |close=0 option now. PrimeHunter (talk) 10:28, 10 June 2014 (UTC)

This was not deployed in 1.24wmf8. --  Gadget850 ^talk 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. --  Gadget850 ^talk 18:38, 20 June 2014 (UTC)

Yes it has been. See https://wiki.riteme.site/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. --  Gadget850 ^talk 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. -- [[User:Edokter]] {{talk}} 07:47, 23 July 2014 (UTC)

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

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

Markup	Renders as
<ref>1</ref><ref>2</ref> <ref name=a1 group=u /><ref name=a2 group=u /> {{#tag:references| <ref name=a1>ref1</ref> <ref name=a2>ref2</ref> |group=u}} <ref>3</ref><ref>4</ref> <references />

I am still investigating as to why this does not occur on every use. --  Gadget850 ^talk 23:41, 22 July 2014 (UTC)

You are defining notes a1 and a2 without group U tags, and then referencing them with "group U" tags; to all intents and purposes although these notes have the same name they belong to different groups. Betty Logan (talk) 00:48, 23 July 2014 (UTC)

Markup	Renders as
<ref>1</ref><ref>2</ref> <ref name=a1 group=u /><ref name=a2 group=u /> {{#tag:references| <ref name=a1 group=u>ref1</ref> <ref name=a2 group=u>ref2</ref> |group=u}} <ref>3</ref><ref>4</ref> <references />

Thanks. Obvious when you point it out. Although it does work if you use <references />. And we should be getting an error message that we invoked an undefined reference.

Markup	Renders as
<ref>1</ref><ref>2</ref> <ref name="a1" group="u" /><ref name="a2" group="u" /> <references group="u"> <ref name="a1">ref1</ref> <ref name="a2">ref2</ref> </references> <ref>3</ref><ref>4</ref> <references />

--  Gadget850 ^talk 10:47, 23 July 2014 (UTC)

Default to multi-column view

The majority of Wikipedia articles should have a large number of references. However, this template defaults to rendering entries in a single column, which quickly becomes disorderly and long. The ability to change the widths of the columns rendered by this template is frequently used, but I believe that this template should be modified so that the default column width is 30em.

Is this a good idea? ViperSnake151  Talk  18:31, 23 July 2014 (UTC)

No. Multiple columns are only useful if the majority of inline refs are short. Unless a system like Shortened footnotes is in use and adhered to, the majority of inline refs will be long. --Redrose64 (talk) 18:55, 23 July 2014 (UTC)

Agreed. And a list with one reference would be split into two columns. We currently have no way to detect the number of references in the list. See T33597. --  Gadget850 ^talk 19:23, 23 July 2014 (UTC)

Help

Hi. I'm tryong to do a merge at British Ornithologists' Union. It's mostly done, but I'm a little confused about how "refList" works. There are some duplicate referenes that I can't get rid of. I started reading this page, but got overwhelmed by the detail and technical stuff. Howunusual (talk) 17:12, 22 August 2014 (UTC)

Try Help:Footnotes and get back to us. --  Gadget850 ^talk 17:37, 22 August 2014 (UTC)

Now redundant?

Is reflist now redundant? In training recently, a new article produced a list without reflist being added. Or is this citation template-dependant? Wiki CRUK John (talk) 14:43, 25 September 2014 (UTC)

It's sill needed, because if you don't use it, the reference list goes at the very bottom, which is usually the wrong place for it (since it should be above things like navboxes). Jackmcbarn (talk) 14:46, 25 September 2014 (UTC)

See Automatically generated reference lists for all the broken bits. --  Gadget850 ^talk 15:06, 25 September 2014 (UTC)

Ok, thanks Wiki CRUK John (talk) 15:57, 25 September 2014 (UTC)

Just wondering...

Does this template have permanent protect only, or does it also have cascading protection? I'm curious since when I try to edit the template, the edit notice supersedes any protection notice that may have appeared, render in the protection notice invisible. Steel1943 (talk) 01:55, 30 December 2014 (UTC)

Both. And I do see both protection notices. -- [[User:Edokter]] {{talk}} 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 "<ref name="stuff">stuff</ref>" and "<ref name="stuff" />" in it.

This is already covered in § Grouped references. Your example had multiple errors, including defining the same reference twice, and using a reserved group name. -- [[User:Edokter]] {{talk}} 10:00, 11 February 2015 (UTC)