Template talk:Reflist/Archive 27

Archive 20

←

Archive 25

Archive 26

Archive 27

Archive 28

Archive 29

Archive 30

colwidth obsolete

Why is it encouraged, as suggested here, to remove named parameters, in this case |colwidth=, in favour of unnamed positional parameters? IMO that diminishes the readability of source text. I suggest to remove that point, which was introduced in the cited edit. -- Michael Bednarek (talk) 14:02, 15 February 2015 (UTC)

Because it is redundant. Since its inception, the columns feature was always ment to be controlled by the first unnamed parameter, but it was miscoded. Since that mistake has been fixed, it is simply redundant. I don't think |20em leaves any question about its meaning. -- [[User:Edokter]] {{talk}} 15:15, 15 February 2015 (UTC)

The only problem with "20em" being self-evident is that "2" might not be; the colwidth parameter still accepts either a number of columns or an actual width. I do understand that reading the instructions is the best course for anyone first using the parameter, of course. --User:Ceyockey (talk to me) 15:32, 15 February 2015 (UTC)

Actually, |colwidth= only accepts a valid width value, no fixed number of columns; only |1= allows that. Note that using a fixed number of columns is deprecated anyway in favor of dynamic columns (using column width). -- [[User:Edokter]] {{talk}} 16:02, 15 February 2015 (UTC)

I think the use of em is -- in my case -- unhelpful in the extreme. On both my old computer and my new computer it defaults to one column. The forced two-column alternative is far better from what I have seen. My personal point of view. Epeefleche (talk) 06:17, 16 February 2015 (UTC)

The main problem is that you are forcing two columns on everyone's screen. So you have either a very small screen, or a very big font. -- [[User:Edokter]] {{talk}} 09:17, 16 February 2015 (UTC)

@Epeefleche: What browser and version are you using? --  Gadget850 ^talk 12:10, 16 February 2015 (UTC)

Tx for the questions. My screen is 14" by 12"; 1024 x 819 pixels, 24 bit. The font is a normal one -- Times New Roman 20; not a "very big" one. I'm using Mozilla Firefox 35 on Windows 8.1, and it is up to date. Epeefleche (talk) 20:21, 16 February 2015 (UTC)

@Epeefleche: What do you see at Template:Reflist/testcases#Column width em test? --  Gadget850 ^talk 21:08, 16 February 2015 (UTC)

Thanks, doctor. One col at 30em, two at 20em, four at 10em. Epeefleche (talk) 00:19, 17 February 2015 (UTC)

Then you should see the same in articles. If not, what arcicle? --  Gadget850 ^talk 00:23, 17 February 2015 (UTC)

The problem for me, on my 14-inch-wide screen, is that refs (where we have more than 10) would look better as two columns. But 30em is typically put into articles where two columns would be better, and result in me seeing only one column. The forced-two-column approach is therefore -- for me, as a viewer on a screen over a foot wide -- the preferable one. Epeefleche (talk) 06:38, 17 February 2015 (UTC)

I get that behaviour (1 / 2 / 4 columns there) when I set my browser window to about 800 pixels with my default font of 16px; if I set the font to 20px, I get the same behaviour at the size you mention, 1024 pixels. Conclusion: 20px is indeed rather large. -- Michael Bednarek (talk) 06:36, 17 February 2015 (UTC)

Tx. It's denoted on my computer as "medium" font size. I could make it smaller than medium, but with my eyesight (which is 20-30 ... a reasonably good eyesight) medium is comfortable. But two ref columns at that font size (which I get when 2 are forced, but not at 30em) in long ref lists are far easier to read -- for the same reason that newspapers like the NY Times have many columns. Epeefleche (talk) 06:47, 17 February 2015 (UTC)

That is helpful. Need to add a note about browser font size.

Firefox defaults to a font size of 16px: 30em gives two columns until the browser window is 11.4 inches wide. At 20px, 30em gives two columns until the browser window is 14.1 inches wide. But at 16px, 30em gives three columns on a 16 inch wide monitor. I can't test a larger monitor at the moment, but you would obviously get more columns. By setting the columns to 2, you force it to two columns for everyone.

@Edokter: Would it be possible to add a class so that users could add CSS to adjust the column-gap? Looks like the default is 1em, which is a bit generous. --  Gadget850 ^talk 09:24, 17 February 2015 (UTC)

@Gadget850:, users can already select .reflist.columns (or either .references-column-count and .references-column-width)to target reflists (or just .columns for other column templates), so there is no need for another class. 1em isn't that much though. The reflist documentation also explains how one can force two columns, see § Customizing the view. -- [[User:Edokter]] {{talk}} 09:40, 17 February 2015 (UTC)

Which is why I defer to your CSS fu. --  Gadget850 ^talk 09:43, 17 February 2015 (UTC)

I'm doing something wrong here. I can increase the gap, but I cannot decrease it unless I set it to 0. I tried 5px and other values with no effect. If I set it to 0, then the gap decreases but not to 0 (it does seem to fix the problem though). --  Gadget850 ^talk 10:22, 17 February 2015 (UTC)

.references-column-count, .references-column-width {
    -ms-column-gap: 0;
    -webkit-column-gap: 0;
    -moz-column-gap: 0;
    column-gap: 0;
}

Seems to work on my end. You can remove -ms-column-gap; it does not exist. You can also play with {{column-gap}}, and {{div col}} also has a |gap= parameter to play with. Note that with ordered lists (as used in reflist), there is always a minimum gap of 3.2em reserved for the (decimal) list markers. -- [[User:Edokter]] {{talk}} 10:48, 17 February 2015 (UTC)

-ms-column-gap was suggested when I edited my JS and added the others. And the list indent is what I was missing. --  Gadget850 ^talk 11:02, 17 February 2015 (UTC)

Number of columns?

I was wondering, what's the criteria for deciding the number of columns to be used? Is there a rule or is it just up to the editors to decide? Illegitimate Barrister 10:23, 27 February 2015 (UTC)

See Template:Reflist#Columns. Common practice is to let browser software determine the number of columns. Betty Logan (talk) 10:25, 27 February 2015 (UTC)

Thanks. Illegitimate Barrister 10:32, 27 February 2015 (UTC)

Replacing bare references tag with reflist with no params

I often see editors replacing <references /> with {{reflist}}, with no parameters. Is there any reason to do this? The appearance is exactly the same. The reason I mention it is that for editors who use VE, it's much easier to work with <references />, and I typically make the reverse edit when I see {{reflist}} with no parameters. Of course if {{reflist}} is being used with parameters, that's a good reason to make the change, but does the template with no parameters add any value? Mike Christie (talk - contribs - library) 17:02, 5 March 2015 (UTC)

Consistency perhaps. Using {{reflist}} is pretty much the defacto standard over using <references />, even if thre is no difference. -- [[User:Edokter]] {{talk}} 18:01, 5 March 2015 (UTC)

Well, there's one difference -- the template is much harder to work with in VE. If there's no other reason, I won't feel guilty about replacing the template with the bare references tag when I'm working on an article (only if there are no params, of course). Mike Christie (talk - contribs - library) 18:04, 5 March 2015 (UTC)

I think this may be T53146; see also T56906. --  Gadget850 ^talk 18:17, 5 March 2015 (UTC)

We should not be expected to change established practices in order to work around some problem with VE. Instead, VE should be fixed to conform. --Redrose64 (talk) 20:53, 5 March 2015 (UTC)

I agree; reflist is a very valuable template, and I'm not asking anyone else to change their behaviour. I was just checking that it was harmless for me to change reflist to references when there are no parameters. Mike Christie (talk - contribs - library) 21:01, 5 March 2015 (UTC)

User:Mike Christie removing the {{reflist}} removes the ability to simply add parameters when needed later. For instance, when the number of references pass say ten and columns may be desirable. In that natural article progression, it seems a retrograde step to undo part of that article progression. To do that only as a workaround for a bug elsewhere seems highly undesirable. Widefox; talk 10:02, 3 May 2015 (UTC)

To reiterate: If VE has trouble handling a template used on 3.5 million pages, then the issue is with VE. -- Gadget850 ^talk 12:19, 3 May 2015 (UTC)

Something just broke the 30em parameter

--LKAvn (talk) 12:17, 17 June 2015 (UTC)

Where did you see it break? What are the symptoms? -- Michael Bednarek (talk) 12:38, 17 June 2015 (UTC)

Using a bot to replace all static columns

Since it is depreciated to force the number of columns used, is it possible to have a bot replace all of them with 30em? Just curious, as I've been performing some other work on articles and am seeing a number of these cases. And each time I change it to 30em, since that is preferred. - Favre1fan93 (talk) 18:36, 13 August 2015 (UTC)

There may be articles where the deprecated specification of columns is a well-considered choice. -- Michael Bednarek (talk) 05:35, 14 August 2015 (UTC)

Change default behaviour to |colwidth=35em

This is the default behaviour for the majority of pages. Making it the default behaviour for the template would simplify our vast task of coding pages. Convention over configuration.

30em instead, I don't care.

If any page needs something different, then an explicit parameter would of course override this default behaviour. Andy Dingley (talk) 17:04, 16 November 2015 (UTC)

It is being considered, but at the MediaWiki software level. -- [[User:Edokter]] {{talk}} 17:26, 16 November 2015 (UTC)

Well that's an obviously stupid idea. 8-( Andy Dingley (talk) 21:39, 16 November 2015 (UTC)

Any further word on this? The default should definitely be 30em. Alex|The|Whovian 01:41, 24 December 2015 (UTC)

There may be articles where he omission of any parameter, relying on the current default behaviour of no columns, is a well-considered choice. -- Michael Bednarek (talk) 04:32, 24 December 2015 (UTC)

Yes, such as when there are few refs, and all those refs are long. --Redrose64 (talk) 23:45, 25 December 2015 (UTC)

Then those few articles can have their own parameter set for a single column; however, this would benefit the majority of articles using this template. Alex|The|Whovian 00:55, 26 December 2015 (UTC)

How do you know that only a few articles use deliberately the current default behaviour? How many do you think is a few of 3,600,000 uses? -- Michael Bednarek (talk) 03:11, 26 December 2015 (UTC)

You use {{template usage}} to find counts, behaviors, of template users. — CpiralCpiral 04:08, 27 December 2015 (UTC)

That doesn't help much when assessing the default, though. If I just use {{reflist}} when I create an article, is that because I want the default behaviour (which is currently one column), or because I only have one reference at that time (and thus might approve of changing once there are more), or because I just don't know about the available parameters, or because I just don't bother? Whereas using {{reflist|1}} is a much clearer statement that I want a one-column reflist (or possibly that I copied code from someone who did). Nikkimaria (talk) 19:20, 27 December 2015 (UTC)

{{Notelist}} removes most of the use cases for single-column {{Reflist}}. Also note that setting column width need not (as it tends to at present) force multiple columns for short lists. A short list can still be narrow, but a single unbroken column. Andy Dingley (talk) 20:16, 27 December 2015 (UTC)

references tag

I have been using <references/>. Is this deprecated? Should I use this template instead?--DThomsen8 (talk) 14:16, 5 February 2016 (UTC)

I don't think it's officially deprecated, but many would argue that {{reflist}} is better, because of the column parameter if for no other reason. I tend to use just <references/> on new articles, because VE works better with it, but I think most editors would typically create a new article with {{reflist}} with no parameters instead. Mike Christie (talk - contribs - library) 15:14, 5 February 2016 (UTC)

@Dthomsen8: <references />, when no attributes are provided, is functionally identical to {{reflist}} without parameters, but is slightly longer (13 characters if the optional space is omitted, as opposed to 11 chars). The processing time of <references /> is marginally less than that of {{reflist}}, but the difference is insignificant compared to the processing time of the references themselves. I'm pretty sure that all of the features available when when attributes are provided to <references /> are also available when appropriate parameters are given to {{reflist}}. It's not the case the other way around though: the main features of {{reflist}} that are not available with <references /> are multiple columns (as noted by Mike Christie) and also the option to vary the list style. --Redrose64 (talk) 21:05, 5 February 2016 (UTC)

{{reflist}} versus {{reflist|30em}}

I've been changing the reflist code for articles with numerous references from {{reflist}} to {{reflist|30em}} because I think it looks better. Another editor User:Justlettersandnumbers with this edit[[1]] reverted my code, saying he thinks the unparametered plain version is more visually appealing. I disagree but rather than getting in an unproductive revert war, I thought I'd ask here if there are guidelines for choosing one way over the other, rather than the slippery slope of leaving it up to everyone's range of personal preferences. I also see the discussion stating that {{reflist|35em}} is a preferable default. I noticed it has no display impact on my mobile device, in mobile view. Anyone able to clarify how this should work logically and amicably?Timtempleton (talk) 14:33, 23 March 2016 (UTC)

I would think the slippery slope would be trying to enforce a uniform preference. This type of thing should be left to the preference of the principal editors on the given page, in my opinion. Like citation style, choice of images, etc, it is best to examine the needs of the article and make a decision. --Laser brain (talk) 16:46, 23 March 2016 (UTC)

Indeed! While WP:CITEVAR does not cover (and is surely not meant to cover) this particular minor detail, the general principle of not messing about with the established reference format is probably a good starting-point here. Changing the references into little bunched paragraphs makes them, in my opinion, just that much harder to read; I'll leave it to others to decide whether this amounts to the level of an accessibility issue. Justlettersandnumbers (talk) 17:07, 23 March 2016 (UTC)

Hopefully it's not as subjective as that. There should be more of a reason than personal preference. While I admit I always get a bit of a rise when I see that something I did was reverted, I don't take it personally - I just like it when things are clear and run smoothly - as I suspect most of us here also do. If there are no clear reasons why to set reflists one way or the other, why have different parameter options? Who gets to be the principal editor could be another slippery slope. Outside of the common case when a new article is done incorrectly, and there's only one editor, nobody likes to hear the argument "I've been on the site longer than you so my way goes"? I should call the rebuttal WP:BUDWEISER - the majority isn't always right. ;-)Timtempleton (talk) 17:24, 23 March 2016 (UTC)

"the general principle of not messing about with the established reference format"' is always popular as little more than an exercise in WP:OWN. Certainly in this case there is a clear consensus to use columns at 30-35em, a body of readability and usability studies that columns with more than 55em width become significantly less readable and also a recognition that hard-coding two columns is unfriendly to mobiles. Andy Dingley (talk) 17:35, 23 March 2016 (UTC)

To me, the value of the principle of not changing things such as reference formats and citation styles is the inertia that it brings. I think global edits should be reserved for things not covered by that principle. One way to look at it is that the variety of formats and styles reflects the choices of the editor population, and that's probably a good thing, in most cases. Global changes bring uniformity, and I'd rather see that happen only with a well-established site consensus. Mike Christie (talk - contribs - library) 18:00, 23 March 2016 (UTC)

The wording used on the templates says it best- "Flexible formatting for a variety of display screen sizes is best".--Moxy (talk) 18:02, 23 March 2016 (UTC)

Template:Reflist#Practices. --Redrose64 (talk) 21:49, 23 March 2016 (UTC)

Andy Dingley, if there is such a consensus, please link to it. Thanks, Justlettersandnumbers (talk) 10:32, 25 March 2016 (UTC)

Columns in Firefox

Hi, there appears to be some problem in Firefox 45.0.2 with the {{reflist|30em}} not giving multilple columns. The previous, but now deprecate, usage {{reflist|2}} is OK and produces columns. Any ideas what the problem is? Keith D (talk) 18:21, 14 April 2016 (UTC)

Works fine for me, with and without explictly stating |colwidth=. Got an example? Andy Dingley (talk) 18:28, 14 April 2016 (UTC)

I was looking at this revision with the old format that gives 2 columns. While the latest revision uses the new format and gives a single column. Keith D (talk) 19:15, 14 April 2016 (UTC)

Looks fine to me now, 2 or 3 columns as I resize the window. Andy Dingley (talk) 21:22, 14 April 2016 (UTC)

I see the problem now it is the screen width, I was expecting that I would get same columns as previously. If I widen the window then I get 2 columns. Keith D (talk) 22:43, 14 April 2016 (UTC)

Examples should have sufficient entries to actually show columnization

The examples currently don't include enough items to drive the rendering into multiple columns, so renderings that in principle should look different don't actually look different. This reduces their value as examples. I'm happy to add the additional items if nobody objects. --jmcgnh^{(talk) (contribs)} 07:21, 16 May 2016 (UTC)

Go ahead. The documentation isn't proteced. -- [[User:Edokter]] {{talk}} 08:00, 16 May 2016 (UTC)

After experimenting, the explicitly 2-column example is easy, but forcing the 30em example to wrap was difficult. Works for 20em as a demonstration, though. User:jmcgnh/sandbox/Template_Reflist --jmcgnh^{(talk) (contribs)} 08:07, 16 May 2016 (UTC)

The examples shown do not necessarily need to use the exact code; the examples are for illustration only. -- [[User:Edokter]] {{talk}} 09:16, 16 May 2016 (UTC)

OK, I'll go with what I've got except I won't explicitly point out the 20em vs 30em, in the spirit of for illustration only. --jmcgnh^{(talk) (contribs)} 07:49, 17 May 2016 (UTC)

Alright, Edokter, I see what you did there. Yes, it makes it all clearer, with less discrepancy. Thanks for letting me do something that others might find useful or illustrative. --jmcgnh^{(talk) (contribs)} 01:49, 18 May 2016 (UTC)

Of course; this is Wikipedia. -- [[User:Edokter]] {{talk}} 06:44, 18 May 2016 (UTC)

Open Access template not showing up inside reflist

I added a newspaper.com clipping to a citation in Gerri Major, and included the Template:Open access template at the end, per the instructions at WP:Newspapers.com. The icon that should appear (File:Open Access logo PLoS white.svg) as a result doesn't appear; hardly surprising given that this is being parsed inside Reflist. Is there a way to make that icon appear at the end of a reference, or could a true/false switch be added to make the icon appear? Mike Christie (talk - contribs - library) 14:34, 22 May 2016 (UTC)

Shouldn't that have been place inside the <ref>...</ref> tags?

—Trappist the monk (talk) 14:43, 22 May 2016 (UTC)

D'oh. Yes. Fixed. Thanks. Mike Christie (talk - contribs - library) 14:48, 22 May 2016 (UTC)

I have an idea for a change: Add the {{clear}} template at the top of the source code.

That way, an object (like an image) in the previous section of an article will not disrupt the columns. A small obstruction in just a small part of the top of the list will cause the entire reflist to get pushed to the side. I see no reason why this shouldn't be done. FabulousFerd (talk) 21:34, 23 July 2016 (UTC)

Oh... now I see a problem. The ==References== heading won't follow this rule. So, it will stay in a position and the ref list will be much lower in case there is an obstruction. In some other wikipedias, the {{Reflist}} template automatically creates the ==References== heading, so in that case, it would work. Shame. FabulousFerd (talk) 21:38, 23 July 2016 (UTC)

• Oppose {{Reflist}}} normally follows a == References == heading, and any CSS clear should happen on that element (i.e. before the heading), not after.

Also it's common that a {{Commons category}} will be used, and CSS floated, between the heading and the {{Reflist}} (if this is the last heading on the page, i.e. there is no == External links == section). The added clear would thus introduce unwanted whitespace. Andy Dingley (talk) 22:09, 23 July 2016 (UTC)

• Oppose In the present state the relist will appear on the place where it is added. With the clear-option it will be pushed to the bottom (after all sidebars or picture), leaving ugly white spaces. The Banner talk 20:18, 25 July 2016 (UTC)