Template talk:Reflist/Archive 15

Archive 10

←

Archive 13

Archive 14

Archive 15

Archive 16

Archive 17

→

Archive 20

Font size

This is not a discussion on changing the font size

A rcent change to the documentation implies that only Monobook reduces the font size. The default font size for Vector differs from Monobook; there is less difference between the Vector default font size and the reflist font size. The font size also depends on how the browser rounds font sizes.

• The Quick Brown Fox Jumps Over The Lazy Dog (plain)
• The Quick Brown Fox Jumps Over The Lazy Dog (references-small)
• The Quick Brown Fox Jumps Over The Lazy Dog (90%)
• The Quick Brown Fox Jumps Over The Lazy Dog (88%)

---— Gadget850 (Ed) ^talk 04:22, 9 September 2010 (UTC)

In IE6/8, I see no difference in font sizes between Monobook and Vector. Editors should take care not to put their own observations in the documentation without confirming if it applies to all users. I have reverted that change in the doc. — Edokter • Talk • 14:11, 9 September 2010 (UTC)

Editnotice?

It may not do much good, but should we create Template:Editnotices/Page/Template talk:Reflist with content something like this?

Anomie⚔ 11:00, 16 September 2010 (UTC)

Don't know why we need an id. Also add "If you have a cite error message, please use the link at the end of the message to open a help page specific to that error." ---— Gadget850 (Ed) ^talk 14:10, 16 September 2010 (UTC)

The documentation for {{editnotice}} implies the id is necessary, but internally it uses {{fmbox}} for which the id is optional. I don't care either way. Add the bit about the cite error message too if you want, but it seems to me the problems have all been people trying to add a reference to an article somewhere. Anomie⚔ 19:20, 16 September 2010 (UTC)

Fixed the {{editnotice}} documentation. I updated {{fmbox}} to make the id optional a while back, but I guess some templates will still document it as mandatory.

I had been querying users who made misplaced edit requests. The one answer I got is that the user saw the message about the missing reflist, came to the template, tried to edit it and found it was protected, then made the edit request.

Editnotice created. ---— Gadget850 (Ed) ^talk 04:42, 17 September 2010 (UTC)

Duplicate reference number

When I view the article Ambisonics using firefox version 1.5.0.12 (which is old), I see the references numbered correctly in the body of the article but two references numbered 10 in the "References" section. References after number 10 are then all one number out. This problem goes away if I replace "{{Reflist|2}}" with "<references />" or {{Reflist}} in the article. I am not sure whether this is a general bug with {{Reflist}} or a bug confined to my (old) version of Firefox. If it is the latter then somebody using a recent version of Firefox please say so and the matter ends. HairyWombat 17:22, 17 September 2010 (UTC)

I'm using the latest version of firefox and can't replicate the problem; that's an odd error... GiftigerWunsch [TALK] 18:04, 17 September 2010 (UTC)

I don't see the problem: there are refs 1-16 in Firefox (recently upgraded to 3.6.10), 1-16 in Google Chrome also 1-16 in Internet Explorer 7. I have heard of (but been unable to replicate) similar problems in unspecified versions of Firefox, when viewing at certain resolutions (again unspecified). --Redrose64 (talk) 12:10, 18 September 2010 (UTC)

This is a very old problem. Dig through the archives and you will find reports of this issue and that it is specific to older versions of FireFox. I encourage you to keep your browser updated to the latest version for security, stability and compatibility. ---— Gadget850 (Ed) ^talk 13:33, 18 September 2010 (UTC)

Who broke this template?

Passing an integer as the first parameter to this template used to produce a matching number of columns. Eg: {{Reflist|2}} used to produce 2 columns. Now it does not: Slugger Labbe. Pls fix.

--Hutcher (talk) 01:15, 27 September 2010 (UTC)

Did you recently change browsers, e.g. from Firefox to IE? Anomie⚔ 01:50, 27 September 2010 (UTC)

The {{reflist}} template itself hasn't changed since March. However, the multi-column feature which works with Firefox does not work with either Internet Explorer, Google Chrome or Opera. --Redrose64 (talk) 17:04, 27 September 2010 (UTC)

Yep, ff was giving me grief so I was using ie. I just assumed that wp was formatting that section with table columns. Thanks! --Hutcher (talk) 03:47, 29 September 2010 (UTC)

We should add a note to the top of the doc that IE does not support columns. And that older versions of Safari/Chrome have a bug, now that WebKit support as been restored. ---— Gadget850 (Ed) ^talk 05:37, 30 September 2010 (UTC)

Agreed and  Done. –Moondyne 06:37, 30 September 2010 (UTC)

Update: with this edit the multi-column feature now works with Google Chrome (ver. 6.0.472.63 anyway), although you may need to WP:PURGE the page to get the columns to show. It still doesn't work in IE (ver. 7.0.5730.13) or Opera (ver. 10.62), however. --Redrose64 (talk) 11:33, 30 September 2010 (UTC)

I thought we had disabled webkit support because there were still to many users out there with broken webkit support ? —TheDJ (talk • contribs) 11:43, 30 September 2010 (UTC)

Were broken means that elements from the second column render out of place underneath the first column, which was REALLY annoying. —TheDJ (talk • contribs) 11:45, 30 September 2010 (UTC)

As of August 2010, Chrome and Safari combined are now >15% of users, and this is on the rise. I'm guessing at least 95% of them would be on current or recent version which doesn't have the broken webkit (I've seen that data somewhere but cannot remember where). It seems silly to exclude this large minority, just for the handful who have chosen not to upgrade. –Moondyne 13:22, 30 September 2010 (UTC)

[1] About a 3rd of the Webkit users in June were still using webkit browsers that were not fixed. —TheDJ (talk • contribs) 13:38, 30 September 2010 (UTC)

Thanks. What version numbers are you looking at? –Moondyne 14:14, 30 September 2010 (UTC)

That's awesome! Yay :) Airplaneman ✈ 13:54, 30 September 2010 (UTC)

{{Reflist|2}} now does not work in Firefox. – S Masters (talk) 18:03, 16 October 2010 (UTC)

The problem doesn't show itself on an article until, an recent edit is done, I test this on an article (2008 Miami Dolphins season), which was working (meaning it show multiple reference columns), once I did a none related minor edit the problem showed up. This problem seems to be related to the recent edits by user WOSlinker to the template. Regards --Bocafan76 (talk) 18:49, 16 October 2010 (UTC)

Edit request from Kellymonaghan, 8 October 2010

{{edit protected}} On the page http://en.wiki.x.io/wiki/Magrodome

under References, reference #3 has an outdated link

current link is to http://hometravelagency.com/dictionary/magrodome.html

new link is http://www.travel-industry-dictionary.com/magrodome.html

Kellymonaghan (talk) 14:01, 8 October 2010 (UTC)

This is the place to request changes to the template which displays references on many articles; to make the change you describe, simply do it yourself by editing the Magrodome article. GiftigerWunsch [TALK] 14:05, 8 October 2010 (UTC)

 Not done Note that I removed the reference and its statement, since the ref is a very short sentence irrelevant to the point the article is making, unreliable, and is full of advertising: seems to be spam. GiftigerWunsch [TALK] 14:09, 8 October 2010 (UTC)

Orlady's edit

Revert this edit, please. It destroyed the colwidth feature. —bender235 (talk) 19:03, 16 October 2010 (UTC)

Recent changes

Todays changes broke columns for at least FireFox, so I reverted. Please test this in the sandbox and discuss why we need it. ---— Gadget850 (Ed) ^talk 19:03, 16 October 2010 (UTC)

Today's changes only affected articles that were edited while the changed template configuration was in place. Articles edited earlier were unaffected. Additionally, my observations indicate that articles that were last edited while the changed configuration was in place will not display columns (until they are edited again). --Orlady (talk) 19:24, 16 October 2010 (UTC)

Based on comments above, I checked that. Articles I know used columns did not show columns even after I made a minor edit. Columns did show after I reverted. ---— Gadget850 (Ed) ^talk 23:22, 16 October 2010 (UTC)

The sandbox version works OK. Just don't put spaces in the -count and -width templates. Please check in Firefox. — Edokter • Talk • 21:54, 16 October 2010 (UTC)

I am not adverse to using a template, but what is the advantage? ---— Gadget850 (Ed) ^talk 23:22, 16 October 2010 (UTC)

Same as other templates; centralizing code. — Edokter • Talk • 23:59, 16 October 2010 (UTC)

Edit request from Curdelyon, 19 October 2010

{{edit protected}} I have added to the list of headmasters of the old school and used as reference my copy of

A History Of Owen's School by R A Dare BA

could this be added to the reflist

Curdelyon (talk) 22:37, 19 October 2010 (UTC)

This is not the place to request edits to any particular article. Go to that article's talk page instead. Anomie⚔ 22:41, 19 October 2010 (UTC)

WebKit Columns Support

As was discussed at Template talk:Reflist/Archive 14#WebKit, I believe we should enable column support for WebKit-based browsers (e.g. Chrome and Safari). Based on the adoption of the new versions [2], the statistics are now two months old so I'd imagine the adoption of Safari 5 has increased, and for the month of June Chrome 5 was already fully adopted. --Odie5533 (talk) 05:52, 21 August 2010 (UTC)

Hi, please add -webkit-column-width in template, we have not any problem with that in our wiki! thanks.--ebraminio^t 17:15, 1 September 2010 (UTC)

 Done –Moondyne 06:37, 30 September 2010 (UTC)

Followup: Wikimedia Traffic Analysis Report - Browsers has been updated for October.

Safari use is:

Fixed:

• Safari 533.18 2.97%
• Safari 533.17 0.76%

Broken:

• Safari 533.1 0.47%
• Safari 531.21 0.32%
• Safari 531.22 0.30%
• Safari 531.9 0.21%
• Safari 525.1 0.16%
• Safari 523.1 0.04%
• Safari 525.27 0.03%
• Safari 525.2 0.02%
• Safari 525.28 0.02%

Chrome use is:

Fixed:

• Chrome 8.0 0.03%
• Chrome 7.0 0.36%
• Chrome 6.0 8.88%
• Chrome 5.0 0.24%

Broken:

• Chrome 4.0 0.07%
• Chrome 4.1 0.05%
• Chrome 3.0 0.04%
• Chrome 2.0 0.02%

---— Gadget850 (Ed) ^talk 17:25, 23 October 2010 (UTC)

Issues with Chrome

I've having an issue with Chrome 9, where the 2nd column is off to the right of the browser, forcing a left-right scroll bar, making the 2nd column non-viewable unless one uses the left-right scroll bar to view that column, I can offer a screen shoot if needed. Rick7425 (talk) 20:12, 14 February 2011 (UTC)

2/3 column format

At least one user has been working for a long time to remove hard-coded column counts from articles. This means replacing {{reflist|2}} with {{reflist|colwidth=30em}}. More recently, he started removing all uses of 3-column format from articles, based on guidance in the template documentation here.

If there is actually a consensus that the fixed column count parameters (2 and 3) should be replaced by colwidth? If so, we should simply fix this template to do that automatically. It would be possible to:

• Change the template to simply replace these with colwidth, and/or
• Make the template accept the "2" parameter but not the "3" parameter.

I can edit the template, but I want to gauge consensus first. Is it true that the 2- and 3-column parameters should not be used? — Carl (CBM · talk) 14:25, 29 October 2010 (UTC)

See September discussion. A pertinent comment that I made there: We could change the template to eliminate column-count; the numbers would select column-width, for example 2 would set colwidth=30em, 3 would set colwidth=25em and and 4 would set colwidth=20em. Anything larger sets colwidth=20em. And yes, 20em is quite suitable for the citation section of articles that use shortened footnotes; see Chaco Culture National Historical Park. ---— Gadget850 (Ed) ^talk 14:37, 29 October 2010 (UTC)

Thanks for the link. If the goal is indeed to avoid fixed column counts then that sort of calculation is easy to add to the template. It's just a question of whether there really is consensus for it. — Carl (CBM · talk) 14:42, 29 October 2010 (UTC)

It seems pertinent to eliminate fixed counts in favor of a measured value. That way, people's screens can adapt to whatever real estate they have available. Of course, almost no one is going to be watching this page—I only followed the discussion here because Bender changed quite a few articles on my watchlist. --Andy Walsh (talk) 15:19, 29 October 2010 (UTC)

I might also suggest everyone takes a look at this discussion. —bender235 (talk) 16:10, 29 October 2010 (UTC)

I'm not opposed, but there are some dangling threads. Editors may expect certain behaviour when entering {reflist|2}. Also, what happens if no parameter is given? Do we still asume no columns at all, or should there also be a default column width? If there is going to be number>width translations; I would allow the following values: 1: 40em, 2: 30em, 3: 25em and 4: 20em. And last, do we want a mechanism to still allow for hardcoded columns, ie. using "|colcount=2"? These questions need to be answered before we can even !vote on any proposal. — Edokter • Talk • 21:13, 29 October 2010 (UTC)

I agree these things need to be thought out. You have more experience with the template, so you may have better intuition about them.

One point of the announcement I made on the village pump was to warn people that reflist|2 would no longer mean "2 columns, no matter what". Instead it would mean "2 columns when the viewing area falls into a certain range of sizes".

I have no opinion on the default width. I guess leaving it alone would be the least surprising thing.

I would generally lean against adding new parameters - it's a heavily used template, and so any parameter intended to be rare has a potential for overuse. But if there is some compelling use case I would change my mind. — Carl (CBM · talk) 23:43, 29 October 2010 (UTC)

Proposal to change implementation

This section will be linked from the village pump. The proposal is to change the implementation of the template, as Gadget850 suggested just above, to use column-width instead of column-count. So the old syntax would still work, but would simply select a certain column width. The benefit is that the browser could change the number of columns if the screen is very wide or vary narrow. This should not change browser compatibility, if I understand things correctly. But under certain circumstances, it will cause a different output: for a user with a column-capable browser whose screen width is such that the widths specified for the columns cause the browser to break the data into a different number of columns. — Carl (CBM · talk) 19:13, 29 October 2010 (UTC)

• Support Hell, if not for issues of overtaxing the servers, we could figure out the column width automatically. --Cybercobra (talk) 20:32, 29 October 2010 (UTC)
• Yeah, do it. has more display benefits than detriments --ClubOranje^T 20:45, 29 October 2010 (UTC)
• Support - I think it's a great idea. --Alpha Quadrant ^talk 22:16, 29 October 2010 (UTC)
• Comment - Depreciate the use of colcount if you wish but I see no reason to support this proposal. – Allen for IPv6 00:23, 30 October 2010 (UTC)
• Weak support Do add |colcount=, and the mapping for "1" should be "no column width specified". Anomie⚔ 01:25, 30 October 2010 (UTC)
• Support — Lets see this sandboxed and tested. We also need to look at {{refbegin}} so they match. ---— Gadget850 (Ed) ^talk 16:20, 30 October 2010 (UTC)
• Support but make sure |2= still works and that it just results in what | does now, and add |colcount= because I think that is still useful in some cases. Also, per Gadget850, {{refbegin}} should be amended similarly. /ƒETCHCOMMS/ 02:03, 31 October 2010 (UTC)
• Comment in general, using fixed widths for text areas on websites is not a good idea. The widths should be allowed to change depending on window resolution, which these days could be anything from 2000 to 600 pixels wide (or possibly less - I haven't measured older smartphones). OrangeDog (τ • ε) 15:07, 2 November 2010 (UTC)
• Support -- d'oh! _[talk] 07:49, 5 November 2010 (UTC)

It seems we have generally positive response, so I will implement the changes. — Edokter • Talk • 14:07, 11 November 2010 (UTC)

Thanks for doing the implementation. I see that you updated the documentation as well. — Carl (CBM · talk) 14:38, 11 November 2010 (UTC)

Naturally :) {{Refbegin}} is next, ater some testing. — Edokter • Talk • 15:08, 11 November 2010 (UTC)

Two columns don't look good

Using {{Reflist|2}} gives some awful looking results on my 17inch monitor. See this page as an example. -- Alan Liefting (talk) - 03:27, 19 November 2010 (UTC)

Other people will probably see different things. Can you say which browser you're using, and which operating system? What exactly do you see that looks bad? A screenshot would be best, but if you're not familiar with how to post one online just a description will do. — Carl (CBM · talk) 03:48, 19 November 2010 (UTC)

Win XP, Firefox 3.X.X. The ref is displayed as three columns and since there are only two refs they are being needlessly being split into three. It makes reading them rather difficult. -- Alan Liefting (talk) - 04:12, 19 November 2010 (UTC)

Yes, that page does look awful, but not all of blame lies with the template. People who edit articles should not use the columns feature when there is a small number of references. This example is pretty ridiculous because two short references are displayed as three columns. I removed the columns feature (but the example still works).

The bigger issue with the example is that the template {{reflist|2}} should not be creating 3-column lists. I'm seeing 3-column lists all over Wikipedia in articles that use the template {{reflist|2}}, and I think many of them look awful. I presume this is a result of the well-intentioned change to the template. I'm seeing the 3 columns on a laptop with a 14-in. monitor (Firefox 3.6.12, Linux, 1280x800 resolution). --Orlady (talk) 05:36, 19 November 2010 (UTC)

I have a 22" monitor set to 1600px wide, FF3.6, Win7. If I expand the browser window to about 1250px it breaks over to three columns. ---— Gadget850 (Ed) ^talk 07:54, 19 November 2010 (UTC)

This is all, of course, an anticipated result of the discussion in the previous section. For some time, one or more editors (not me) have been editing numerous articles to remove the hard-coded column counts. Recently the template was edited, after a discussion and a notice on the village pump. The new template code allows the browser to choose the number of columns, based on the width available in the browser.

I'm not sure whether there is some easy way to reconcile these things (just undoing the change in template edit won't help, because if we do that I expect people will go back to directly editing articles to get rid of the hard-coded column count).

What would be ideal is a way to say "at most N columns, each of them at least X wide". I don't know whether CSS can do that. — Carl (CBM · talk) 13:13, 19 November 2010 (UTC)

We can't use both criterums at the same time; column-count will always result in a fixed number of columns, but column-width does ensure a minimum width of the columns, curretly 30em as the default. — Edokter • Talk • 14:00, 19 November 2010 (UTC)

That was how I understood those two, thanks for the confirmation. I was hoping there was a "max-columns" attribute (or similar), just like there are both "width" and "max-width". Apparently not. — Carl (CBM · talk) 14:19, 19 November 2010 (UTC)

Hmmm. So there is no solution to prevent the odd display when there are a small number of refs? -- Alan Liefting (talk) - 19:31, 20 November 2010 (UTC)

No. Only solution remains to remove the columns from a small list. — Edokter • Talk • 19:57, 20 November 2010 (UTC)

I agree that this change to the template, while a good idea, was not implemented perfectly. On my monitor, any articles using {{Reflist|2}} will break the references section into 4 columns, with a lot of the references wrapping to 3 or 4 lines. I would much prefer the old way, where {{Reflist|2}} means 2 columns, no matter what. However, would it fix the problem if you used % instead of em? In other words, {{Reflist|2}} would translate to column-width:50% and {{Reflist|3}} would translate to column-width:33%? Or perhaps we just need to tweak the actual em values. Right now the largest column we can make is 30em, which seems quite small for the largest column size. SnottyWong ^yak 21:52, 22 November 2010 (UTC)

Columns do not accept percentages (but would act exactly the same as fixed number of columns anyway). I did suggest using "1" for a 40em column width. It can still be done. — Edokter • Talk • 22:12, 22 November 2010 (UTC)

How did we come up with the em values for the template anyway? Was there any formula or calculation which resulted in the 30em, 25em, and 20em values? They seem extremely small for my monitor (1680x1050), but I understand that it needs to work for smaller monitors too. I did a quick test: for my monitor, the border where it switches from 1 column to 2 columns is at about 60em, and between 2 and 3 columns is at about 45em. So for this template to work correctly on my monitor, the em values would have to be almost doubled. {{Reflist|2}} would have to be increased to about 50em.SnottyWong ^gossip 22:23, 22 November 2010 (UTC)

I sugested these values above (my screen is 1280 wide, which seems the most common). The initilal purpose of columns is to avoid long lines of small text, which is hard to read. When screens got wider, the lines got longer again, which is what triggered this change. — Edokter • Talk • 22:55, 22 November 2010 (UTC)

I think it would be safe to assume that the smallest resolution width that any self-respecting computer user would be using in this day and age would be 768(x1024) pixels. According to one source, 76% of computer users use a resolution higher than 1024x768. Can we update the em sizes of this template so that it works well with the majority of resolutions (i.e. so that {{Reflist|2}} actually results in two columns as often as possible)? Right now, {{Reflist|2}} results in 4 columns on my 1680x1050 monitor. On your 1280 wide monitor, it might result in 5 columns. My vote would be for {{Reflist|2}} to translate to at least 50em, if not higher. SnottyWong ^confabulate 23:47, 22 November 2010 (UTC)

Remember that screen size is not the only factor; font size has a big role too. The bigger the font, the wider the columns. On my 1280(x960) screen, reflist|2 results in 3 columns. If I increase my font size, it reduces to 2 columns. — Edokter • Talk • 23:58, 22 November 2010 (UTC)

On modern widescreens, sidebars (in-browser or external apps) can also be quite useful while leaving plenty of room for the webpage content. I normally keep my browser window at 1024 width. With class="references-small", the 1→2 column transition here occurs at 35em, the 2→3 at 23em, and the 3→4 at 17em. If I maximize my browser (1214 width), those are 44em, 29em, and 21em. Even if I cover my dock (1280 width), I still see only 1 column at 50em (46em is the transition there). I'd oppose anything over 35em for {{reflist|2}}, and IMO 30em is fine. Anomie⚔ 01:32, 23 November 2010 (UTC)

Here I am, using a laptop with a diminutive screen, and looking at 3 columns for all reflists that were specified as 2-column lists. This might not bother me if most of the articles I fooled with were dominated by references in the form "Jones, p. 217", but I seem to get involved with pages that have numerous verbose references. Breaking them into 2 columns aids readability, but 3 columns breaks the material into tiny snippets that are hard for my eyes to scan. For example, here are some refs from List of bow tie wearers, formatted (i.e., chopped up) the way I see them in 3 columns:

^ Haberman, Clyde (March 30, 1997). "Mark
Russell's High-Wire Act With No Net". The New York
Times. . Retrieved May 8, 2010.

^ Gamarekian, Barbara. " Rummaging in
Broadcasting's Attic", The New York Times, October
8, 1988. Accessed November 17, 2008. "There is
Jimmy Durante's battered hat, Rudy Vallee's
megaphone and Dave Garroway's trademark glasses
and bow tie."

^ a b c d e f Epstein, Joseph (2001-05-04). "Fit To Be
Tied: The enemies of civilization find a new target,
just below the chin". Opinion Journal. Wall Street
Journal. Retrieved 17 March 2010. ""First, though, let me
organize a lineup of bow tie wearers to establish a
variety. The most distinguished of all, of course,
Winston Churchill, whose favorite was a fine floppy
blue job with white polka dots. Daniel Patrick
Moynihan, a tall man, often adds a giant butterfly to
his getup, which gives his appearance a light and
rakish air. Saul Bellow has taken to wearing bow ties
late in life. Former Sen. Paul Simon is a habitual bow
tie wearer, though, oddly, he seems never to have
learned to tie them properly, for the right side of his
ties never quite make it to full bow form. For
diversity's sake, it would be good to have an NFL
linebacker instead of Louis Farrakhan to round off this
roster, but Churchill, Moynihan, Bellow, Simon and
Farrakhan (a clip-on man, I surmise) perhaps provide
sufficient diversity in themselves."

--Orlady (talk) 04:03, 23 November 2010 (UTC)

That's exactly what happens on my screen as well. I think that, while this was a good idea in theory, it didn't turn out quite so well in reality, and it doesn't seem like there is a practical way to make it better. I would vote to revert the changes back to the hard-coded column numbers. Honestly, I can't see very much use for more than 2 columns anyway. Even on my fairly wide monitor, dividing a typical references section into 3 columns almost always results in some of the references getting wrapped into way too many lines (per Orlady's example above). With hard-coded columns, if an article has a lot of references, and most of them are short, they can just force 2 columns and be done with it. Otherwise, we're just left guessing what the best em value is to make sure that users with different screen resolutions and font sizes will all be equally disappointed. SnottyWong ^express 00:49, 24 November 2010 (UTC)