Template talk:Reflist/Archive 4

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

Archive 6

→

Archive 10

Broken

The template now appears to be broken. Looking at the history shows it hasn't been changed since last year so it looks like one of the templates it uses has been changed and broken. Could someone who knows how these templates work have a look? --JD554 (talk) 12:57, 8 April 2008 (UTC)

In what way is it broken? It looks fine to me. What browser and platform are you using? Verisimilus T 13:28, 8 April 2008 (UTC)

I just noticed the same thing. Check on Bradley Davies, for example. It's showing:

Cite error: Invalid <references group="" /> tag; group name "" not defined in <ref>

Weird. — HelloAnnyong ^{(say whaaat?!)} 13:30, 8 April 2008 (UTC)

The problem means it is an "error" with the <ref> module, not this template. And the error message is appearing on that article because it doesn't contain any references! Verisimilus T 13:45, 8 April 2008 (UTC)

It didn't in this past. Alot of users go back and add to new articles with particular references at a later date. Any ideas on a fix.Londo06 13:55, 8 April 2008 (UTC)

Aye, it didn't. Has something changed in the preprocessor or something? — HelloAnnyong ^{(say whaaat?!)} 14:03, 8 April 2008 (UTC)

{{reflist}} uses <references/>. The change is in <references/> which now produces an error message if there are no earlier references on the page. Are there other known changes than this? PrimeHunter (talk) 14:40, 8 April 2008 (UTC)

bugzilla entry of this issue. --TheDJ (talk • contribs) 15:06, 8 April 2008 (UTC)

Could someone point to an article with this issue? I checked a few articles and couldn't find it. Does this have anything to do with the "group" parameter? I didn't see a formal announcement about the code changes adding the "group" parameter to ref tags, so any articles which used it "early" might have been tripped up by some code fixes. Gimmetrow 20:06, 8 April 2008 (UTC)

The error message has changed to the more informative "Cite error: No <ref> tags found". It's still on Bradley Davies and you can make it yourself by just placing <references/> on any page without <ref> and preview. PrimeHunter (talk) 20:49, 8 April 2008 (UTC)

OK, that's clearly a change in cite.php or dependent code. Gimmetrow 20:50, 8 April 2008 (UTC)

Apparently changes here. The template is indeed broken, as it falsely shows an error when no references are available. It should show no references when none are available, but it's not an error, it's there to encourage editors to add references and also make it show when references are added, as many pages are discovered with references that don't show up because no {{reflist}}/reference in called in Reference section. SunCreator (talk) 14:30, 9 April 2008 (UTC)

Self-reference also has this problem now, with a big ugly Cite error: No <ref> tags found in red. I don't see the point with that message unless it's very bad if the template is there without any references? It would be nice if someone could remove the error? :) --Apis O-tang (talk) 00:11, 10 April 2008 (UTC)

Actually removed it from that page, can't see it in history either anymore so maybe it got fixed?--Apis O-tang (talk) 00:16, 10 April 2008 (UTC)

Yes, it was fixed: [1]. PrimeHunter (talk) 02:28, 10 April 2008 (UTC)

Still Broken

Found on Heavy.com. SunCreator (talk) 14:07, 10 April 2008 (UTC). Found that article to have issues with references. SunCreator (talk) 12:33, 11 April 2008 (UTC)

Font size

Why has the font size of references generated through use of this template, in conjunction with <ref> tags, suddenly become much smaller? Black Falcon ^(Talk) 03:56, 30 April 2008 (UTC)

Because of this edit to MediaWiki:Common.css.

I'd thought we were using 92% everywhere, as a standard minimum for "small" text? Ah yes, {{FootnotesSmall}}. See also, the threads MediaWiki talk:Common.css/Archive 3#.references-small -> 92% and MediaWiki talk:Common.css/Archive 2#Please revert "resizing of footnotes by CSS".

I keep coming across instances of unreadably small text, and was trying to find a WP:FONT or WP:TYPOG page without luck, last week. Both WikiProject Accessibility and WikiProject Usability are pretty quiet, but perhaps they could come up with a set of recommendations?

Can someone else poke at fixing this? I have no time currently. -- Quiddity (talk) 06:16, 30 April 2008 (UTC)

Thank you for the links. I've started a thread at MediaWiki talk:Common.css#Font size reduction. Black Falcon ^(Talk) 20:38, 30 April 2008 (UTC)

found a bug in the template

{{editprotected}}

I am writing an offline parser which keeps stumbling over a typo in this template. It isn't noticeable on Wikipedia as it is removed in the HtmlTidy stage but it is still technically there and is stopping my output from validating. If an administrator could make the change that would be much appreciated.

At the end of the line, after the text column-count:, the end-braces }};" need to be moved outside of the quotes ;"}} so that the style attribute is closed inside the template.

Thanks in advance,

CosmicBen (talk) 11:32, 30 April 2008 (UTC)

 Done That was some very odd code, and I don't like relying on the html tidy feature to fix errors on such a high use template. Thanks for noticing it. --CapitalR (talk) 16:08, 30 April 2008 (UTC)

Parser / reflist interaction bug?

There seems to be a problem with putting a template parameter between <ref> tags.

For example:

{{User:Pee Tern/Sandbox/Template/reflistparambug
|parameter = test data
}}
{{Reflist}}

Produces:

Parameter value: test data.

As a reference: .

AND !!

Parameter value: test data.

As a reference: <ref>test data</ref>.
{{Reflist}}

Then produces:

Parameter value: test data.

As a reference: .

Reflist being messed up altogether by the earlier template call !!

Or have I missed the obvious somewhere ?

Peet Ern (talk) 02:09, 1 May 2008 (UTC)

The parser usually doesn't touch the contents of XML-like tags of extensions, in terms of template parameters. As a workaround, you can use the #tag magic word instead: see Wikipedia:FOOTNOTE#Known bugs. Gracenotes^T § 04:10, 1 May 2008 (UTC)

Thanks Gracenotes. Peet Ern (talk) 04:26, 1 May 2008 (UTC)

Resolved

Request for wrapper element

I'm running some experiments to create print-quality PDF documents from Wikipedia. I've run into a problem in the list of references; the current template adds visible markers (^, a, b etc.) to allow users to click their way back to the source of the reference. In print, however, these markers should not be visible. Given the current markup, it's impossible to remove the markers by way of CSS as there is no wrapper element around them. I therefore suggest adding a "span" element with a class name of "to-reference" or something.

Howcome (talk) —Preceding comment was added at 12:56, 1 May 2008 (UTC)

Well this template adds a div around the references with a class="references-small", which you could use to disable references. As for pages that use references in the <references /> format instead of the {{reflist}} format, they envelop the references in a tag with class="references". So, you should be able to use some CSS to disable those two classes to accomplish what you are looking for (actually, you probably only need to disable class="references" to make this work). --CapitalR (talk) 06:00, 6 May 2008 (UTC)

Thanks for replying. I don't want to disable references, just hide the upward links (shown as ^, a, b etc.) since they don't make any sense when printed. But perhaps this is the wrong place to ask; which template defines the behavior of the <references /> element? Howcome (talk) 19:08, 15 May 2008 (UTC)

Bug with 3 or more columns on Firefox

There appears to a bug when one uses Firefox 2.0.0.14 to view an article using reflist with 3 or more columns. One can safely right-click on the links in the first and last column. However, if one right-clicks on any links in the middle columns, the second and subsequent columns "refreshes" and re-numbers the references. The ordering of the references then becomes broken. Jappalang (talk) 01:57, 13 May 2008 (UTC)

Use of reflist

There used to be a guideline that articles with less than X cites "should" use <references/>, while articles with more than X cites "should" use {{reflist}}. Some people removed that guideline a while back. Others used bots to convert multiple instances to {{reflist}}. Those edits probably should have been reverted at the time, but they weren't. We now have a few people going around, mostly in good faith seeking "uniformity", converting every instance of <references/> to {{reflist}}, so that even in articles which have one or two notes the notes are in a smaller font. We need to reestablish a guideline or some editors are going to start getting blocked. Gimmetrow 04:08, 16 June 2008 (UTC)

I agree. I don't know why it was removed as it was a good guideline. I much prefer the less than X (it was 10, I believe) for <references/> and more than 10 {{reflist}} (and maybe add a guide for when {{reflist}} becomes {{reflist|2}} (I've been using 20 as the level myself). -- AnmaFinotera (talk · contribs) 04:15, 16 June 2008 (UTC)

One thing I agree on is that a guideline is definitely necessary. I'd prefer simply junking out "references" and retaining just "reflist" for all articles. Of course, an editor who wants to put in "reflist" could always add something like 9 references in order to reach that "10 point". All Hallow's Wraith (talk) 04:20, 16 June 2008 (UTC)

And because of that, I'm not sure a simple X=10 will work anymore. Maybe X=25 might fly. As for multicolumn, discussion above is largely against it. From my experience, unless the article uses "shortnotes", using two columns doesn't usually save much vertical space, and can make them harder to read (over one-column small font). Gimmetrow 04:29, 16 June 2008 (UTC)

I would go for x = 0. I rarely encounter "references/" anymore - it seems to be an increasingly less popular template (the majority of articles linked at http://en.wiki.x.io/wiki/Main_Page use "reflist" regardless of how many references are included). Restoring this "if x number of references" system would cause a lot of confusion, not to mention nitpicking over the number of references. I say just send "<references/>" to wherever "<div class="references-small"><references /></div>" went. If the issue is that "reflist"'s font is too small, well, the refs' font is still going to be too small whether there are 5 or 50 references. And if the size isn't the issue, then what is? All Hallow's Wraith (talk) 04:43, 16 June 2008 (UTC)

I think the correct place for the guideline is WP:CITE, and I agree it's needed. The smaller font of reflist should only be employed when there is a long list of citations, to make the ref list easier on the eyesight when the list is short. Use the smaller font only when really needed. SandyGeorgia (Talk) 06:14, 16 June 2008 (UTC)

Multiple columns deemed bad

Howzat for a provocative headline, eh?

It seems that long, multicolumn reference lists slow down page loading. (q.v.) This is to be expected, since you need to know how long the reference list is before splitting it in two. (and just knowing the number of entries or the number of characters won't help) I don't know what the solution is, but please be aware that this is an issue with long, multicolumn reference lists. superluser_tc 2008 February 27, 04:46 (UTC)

Ya, and they don't work on my browser (Safari 3.0.4) and I can't be the only one experiencing problems. (By "don't work" I mean that in articles with {{reflist|2}}-formatted references, if I click on the footnote in the article, and if the reference is in the second column, then my browser jumps to the wrong place.) Can this be fixed? Yilloslime (t) 00:37, 7 March 2008 (UTC)

Update: I've switched laptops, upgraded to Mac OS 10.5.2 and Safari 3.1 and {{reflist|2}} still doesn't "work." However if I use Firefox 2.0.0.13 on the same computer, then it seems to work fine.Yilloslime (t) 22:41, 11 April 2008 (UTC)

Don't work in Safari 3.1, bloody annoying, fix or deprecate multiple columns please. DuncanHill (talk) 20:35, 8 April 2008 (UTC)

By "work", do you mean the anchor links? Do other archor links "work" in Safari? Gimmetrow 20:41, 8 April 2008 (UTC)

I mean if I click on a footnote in the text, it doesn't take me to the reference in the reflist, but to where it would be if it was in a single column, and likewise the little letters don't shew up in the right place in the reflist. (I have no idea what an anchor link is). If the reflist is a single column then there is no problem. DuncanHill (talk) 20:44, 8 April 2008 (UTC)

You can see what I mean on this screenshot Safariscreenshot. DuncanHill (talk) 20:47, 8 April 2008 (UTC)

The a and b from reference 7 appear overwriting one of the external links. DuncanHill (talk) 17:19, 9 April 2008 (UTC)

Opinion, I don't see the point of multiple columns as they don't even save any space. --Millbrooky (talk) 17:17, 9 April 2008 (UTC)

I'm also concerned about multiple columns, especially since they don't render nicely on smaller screens. Typically flow into each other, become very narrow and hard to read. I think they should be removed for now. Example with two columns, try making the page narrower. --Apis O-tang (talk) 00:00, 10 April 2008 (UTC)

Permian–Triassic extinction event#References does also have two columns, try making page narrower, the columns will overlap and be to narrow to read. --Apis O-tang (talk) 17:35, 10 April 2008 (UTC)

I think this has reached something of a critical mass. I'm going to check to see if it's a Wikipedia problem, or a problem with every CSS3 browser, and make appropriate requests. superluser_tc 2008 April 10, 20:18 (UTC)

I strongly agree that multicolumn layout is a Bad Bad Thing for reference lists. Quite independent of any speed or browser compatibility issues, they cause a lot of problems with narrow screens, printing, line wrapping, and output of long items such as URLs -- which are really common in reference lists! Just say no to multicolumn. :) --brion (talk) 19:15, 11 April 2008 (UTC)

Strong ditto against multicolumns, per all above, plus negative comments from a few friends. It makes most references harder to read, on top of the already small font size. (especially at 1024x768 and below.) -- Quiddity (talk) 07:16, 25 April 2008 (UTC)

See Stereolab#Notes for a recent FA/example that shows a good and legitimate use for 2 column layout; but the "References" section underneath is much better as a single column. -- Quiddity (talk) 19:45, 1 May 2008 (UTC)

I've done some experiments with multi-column formatting for Wikipedia content. My conclusion is that multi-column layout is quite pleasant. However, in order to create those nice PDF files, I actually have to ignore the multi-column settings on the refereces. Otherwise, i would end up with multi-column layouts within a multi-column layout. So, I suggest that references are not given a different multi-column setting than other layouts. Howcome (talk) 09:37, 2 May 2008 (UTC)

My 2 cents... I've seen many {{reflist}} -> {{reflist|2}} edits and not once has the page been rendered differently. What is the point of these edits if nothing happens? In fact, on pages I have watchlisted, such edits case my attention to be drawn to them creating extra work for me.

FWIW, even if the page was rendered with 2 columns, I would brobably revert the edit anyway because I would imagine it would be pretty ugly on the page and of no benefit to the reader.

Astronaut (talk) 15:05, 4 May 2008 (UTC)

I've just read through this post again. Is there anyone who speaks in favour of multicolumn references? Astronaut (talk) 15:07, 4 May 2008 (UTC)

I have noticed that some are using this discussion as a consensus for removing multiple columns. I see your point. However... is it possible to get Safari fixed? 2. There is no vote here. 3. Should the vote be in a more public place? If this is not changed into a policy then you guys will be just pushing back the tide. Sure it loads slower, but some like the way it looks. If you want to change the policy then change the policy. There are two many articles unless you want to devote your life to changing them. Thx 4 listening. Victuallers (talk) 18:38, 6 May 2008 (UTC)

Someone could start a discussion at the WP:VP. I noticed no one is in favour here there is also disapproval on Wikipedia:Accessibility discussion but the Wikipedia:Featured_articles are now almost entirely multi-column. SunCreator (talk) 01:53, 7 May 2008 (UTC)

Alright, I'll try to get some attention from wp:vp, wp:mos and wp:wai.
—– Apis (talk) 21:29, 15 May 2008 (UTC)

We at Wikipedia:WikiProject Scouting had decided to use one column reflist as a standard over a year ago. Just to many issues with multiple columns. --— Gadget850 (Ed)talk 01:53, 16 May 2008 (UTC)

Discussion so far

This is an attempt to summarize the above discussion.

There have been some discussion whether to remove multicolumn support from {{reflist}}. Multiple columns cause several problems:

• Makes references unreadable on narrow screens
• Breaks some browsers (and there is poor browser support)
• Poorly formatted references (URLs) will cause columns to overlap
• Might save some vertical space if you have a wide screen, however, then the article column will look bad (be too wide) so you would have to change window size when reading references.

Clarification of last point: Lets say you adjust your browser window to your optimally preffered width, x, then the columnwidth for the reference and fotnotes section would be x/y, where y is the number of columns. If you have 2 columns that would mean half the optimal width, 3 means a third and so on. So both the article and the reflist can never be at optimal width at the same time.

Reasons for keeping multi column support:

• Aesthetics
• A long list of really short references (e.g. "ABC xyz 123") could fit inside a narrow column, and having multiple columns in this case would save vertical space on the page. See Queluz National Palace for an example.

The simple solution would be to remove support for it in the reflist template, however some users suggested it might be better to have a policy change? (I'm guessing the right place would be Wikipedia:Manual of Style).
— Apis (talk) 21:29, 15 May 2008 (UTC)

This isn't the right process to change long-standing principles of layout; a few guys with technical expertise can't outvote thousands of editors who have created and approved that "look". If we can pull in a lot of discussion to this page, then I can support the process. — comment added by Dank55 (talk)(mistakes) 14:28, 16 May 2008 (UTC)

That's why I mentioned it on wp:vp, wp:mos and wp:wai. Is there anywhere else it should be mentioned?
— Apis (talk) 15:39, 16 May 2008 (UTC)

Right...you did good, and if it works, it works. But don't ignore the fact that consensus, as expressed by thousands of editors making decisions about what they want their reflist to look like, is against this proposal, until and unless we can pull in enough people here to overcome that consensus. Btw, specifiying column width, as was suggested recently, might be a nice way around the problem of accommodating narrower windows, of keeping both sides happy; is it? - Dan Dank55 (talk)(mistakes) 17:51, 16 May 2008 (UTC)

No reasons for keeping? Just to play devil's advocate, off the top of my head: Asthetics, appearance of tidiness, economy of space, less scrolling. This may not, of course, outweigh the problems. The question is, are the problems mentioned fixable? Has anyone made an effort to contact those who might be able to to do so, or who might have the technical savvy to say yay or nay? If it can't be fixed to work better in some browsers, can it be coded so that it only displays for users using the correct browser configuration and would simply display for other in normal, single column form? If feasible, this seems to me a good compromise.--Fuhghettaboutit (talk) 01:10, 16 May 2008 (UTC)

I've mentioned this discussion on wp:vp, wp:mos and wp:wai. Feel free to bring it to attention elsewhere. I consider myself somewhat technically knowledgeable in this field at least, and it might be able to limit it to some specific browsers, but that typically requires rather ugly hacks (on the other hand it's done quite often). My main concern is that the idea to use multiple columns here is fundamentally flawed though. If we want the references to be accessible they should preferably have about the same column width as the article itself. Then there are the other problems as well.

Why is there need to save scrolling or (vertical) space? it's not paper after all. And beauty lies in the eye of the beholder :) (I added 'aesthetics' to the list above though).
— Apis (talk) 02:10, 16 May 2008 (UTC)

It depends on the format of the footnotes; if all the footnotes are in the format "Elkins, p. 137.", it should be no problem to have multiple columns even on the smallest screens; if two columns of this won't fit, neither will some English words. By the same token, if this format is used, the list can be very long and very difficult to page through (to get, for instance, to the external links.

This is a perfect example of something we can decide page by page; if you have a problem reading article X, go to its talk page and explain. Most editors will be reasonable. This means that the articles where multicolumn is useful and causes no problem will be left alone. Septentrionalis PMAnderson 05:13, 16 May 2008 (UTC)

There are also the technical issues, but alright, technical issues aside: if there is a long reflist consisting of only very short references (e.g. "Elkins, p. 137") then they would probably fit within multiple paragraphs. Unfortunately that kind of reference (which as far as I know are only used inline in the text) requires a bibliography section with a description of what author and what work (e.g. which "Elkins" and what book by him/her) we are referring to (i.e. what most reflists are used for now). (I added that to the list of benefits though).

I've been around Wikipedia for a while now and I have never seen a reference list where multiple columns would have been a good idea. It would be nice to see some examples? Sure, I guess we could go through the more than 2,374,000 articles manually, only to provide for the off chance that it might actually be useful somewhere.

I really think the benefits would outweigh the possible negative effects in this case.
— Apis (talk) 14:09, 16 May 2008 (UTC)

Queluz National Palace for example. If the benefits are so clear then why are multiple columns used in almost all FACs? I just checked the 10 first articles on the FAC list and all of them used multiple columns. There's no need to take the possibility of multiple columns out of this template. if there are cases where it is a bad idea to use multiple columns it can be decided on a page by page basis.--Peter Andersen (talk) 14:23, 16 May 2008 (UTC)

OK, that is a great example. (They used four(!) columns though, which makes even those short notes wrap on a smaller screen. I have changed it to two columns now). There are other elements of that page that require a lot of horizontal space (images placed side by side), which might be a problem on small screens. However that is another topic,and the problem seems to be to much space between adjacent images indicating a css problem easy to fix. (Possibly only a problem with my own CSS, I have to check that on another computer). Anyway, there apparently exist pages where multiple column reference lists are used sensibly. But there is obvious abuse of this as well.
— Apis (talk) 15:22, 16 May 2008 (UTC)

It would be nice if the style pages and their talk pages reflected preferences, but they often don't; the best (if tedious) way to find out what people want to do in articles is to look at the articles. I've seen a lot of articles that use two columns for references, including articles that had vigorous review. That means a lot of people have "voted" that it's okay; how many people have said that it's not okay, and where did they say it? - Dan Dank55 (talk)(mistakes) 14:19, 16 May 2008 (UTC)

Hmm, I don't agree with that, not complaining doesn't mean they "voted" for it. My guess is that most people use common browsers and have relatively high resolution monitors most of the time. Then there is plenty horizontal space available for nice, wide, multiple columns. They don't see the problems it cause.

If you look at this talkpage, many appear to have problems with this, and noone have tried to defend multiple columns since this was brought up in February. I mentioned it on the village pump and MoS pages so that everyone that is interested could participate in the discussion (as suggested above).
— Apis (talk) 15:22, 16 May 2008 (UTC)

Ahh, Internet Explorer (75.47% usage share) doesn't support this! so it's not visible at all for many users.
— Apis (talk) 19:27, 16 May 2008 (UTC)

In my opinion, the multiple columns are very useful in articles that have a lot of references. For example, PlayStation 3 currently has 200 inline citations. In IE7, which for some reason does not recognize the multiple columns feature, the references section accounts for nearly half of the total article length, while in FF, it accounts for less than one quarter. Also, just an idea, would it be possible to write a gadget or something that would allow users to turn the multiple columns feature on and off regardless of whether it is present or not? Although I am personally not sure how to write said gadget, it doesn't seem like it would be a difficult project to disable something. Just an idea. Thingg^⊕⊗ 15:07, 16 May 2008 (UTC)

I think PlayStation 3 is a great example of when multiple columns are really bad. They are unreadable as it is (three columns) and it doesn't save space unless you have a wide screen.
— Apis (talk) 15:32, 16 May 2008 (UTC)

It seems to me that the smaller font size typically used for references necessitates a smaller column width (for readability). Since that can result in an excess of right-side whitespace, using two columns seems the most efficient option in most cases. Powers ^T 15:43, 16 May 2008 (UTC)

The reflist is indented (since it's a numbered list), so it is already narrower than the rest of the article.
— Apis (talk) 15:57, 16 May 2008 (UTC)

Yes, trivially. =) Powers ^T 15:59, 16 May 2008 (UTC)

Hmmm, yes, I hadn't noticed how much smaller the textsize have gotten in the default css.
— Apis (talk) 19:27, 16 May 2008 (UTC)

It's worth keeping in mind that you can specify the width of the columns rather than their number, e.g. {{reflist|colwidth=25em}}, so on narrow displays it'll become a single column.
—WWoods (talk) 17:44, 16 May 2008 (UTC)

Well, to throw in my take on the arguments here:

• "Unreadable on small screens" - I usually keep my browser at 800px wide, and 2 columns are not even close to unreadable. Or by "small screens" do you mean "the size of an iPhone"?
• "Poor browser support" - If by that you mean "It doesn't work in IE7", so what? Just because IE sucks isn't a reason to remove all columns.
• "Breaks some browsers" - By this I guess you mean Safari. Does Safari still ignore 'column-count' in favor of '-webkit-column-count'? If so, just force '-webkit-column-count=1' until they fix their bug. There's also one person complaining that multiple columns crashes Firefox (it doesn't even slow it down on my computer, BTW), but if it were a widespread problem I suspect we'd have heard much more about it.
• "Poorly formatted references cause columns to overlap" - This is a reason to fix said references, not to eliminate columns. There should never be a bare URL in a reference, IMO.
• "Might save blah blah too wide blah blah" - Is that supposed to even make sense?
• "Aesthetics" - IMO, two columns looks better.
• "A long list of really short references ..." - Agreed, and it may happen oftener than you think. Any article that uses a book or two (or any source with multiple pages) is a candidate for that style.
• Some people use ridiculous numbers of columns - Agreed, but 2 isn't ridiculous.
• Accessibility - I find two columns of references are actually easier to read than just one. YMMV.
• Used in most passing FACs - If columns were really that awful the FA denizens would probably have said something about it. Why not post your message at WT:FAC to get explicit opinions?

All in all, I personally see nothing like consensus to remove column support. Anomie⚔ 17:58, 16 May 2008 (UTC)

The list above was an attempt to reflect the discussion so far. (The technical issues refer to what is discussed above and below.) Let me try to explain the part you didn't understand ("Might save ..."): Lets say you adjust your browser window to your optimally preffered width, x, then the columnwidth for the reference and fotnotes section would be x/y, where y is the number of columns. If you have 2 columns that would mean half the optimal width, 3 means a third and so on. So both the article and the reflist can never be at optimal width at the same time.

I just realized that my version of the monobook.css that I made some time ago is a bit outdated, the fontsize is much smaller than I was aware of. The, now (in firefox at least, bigger in IE), tiny textsize fits (barely) in two columns at 800px, and at this width and size they would be too long for good readability. Sorry for not checking this more carefully. Now the discussion below also makes more sense to me.

I think the reason it is used in many passing FACs might be because: a) many users have wide screens, it looks ok then. b) many users use IE (75% usage share), a browser that doesn't support multiple columns so it's not even visible to them. But I would be happy to bring it up there as well.

Anyhow, I'm somewhat convinced that more than one column in a reflist is useful in a few cases (e.g. Queluz National Palace, I don't know how common this practice is though). WWoods makes a really good point: specifying a minimum/specific width makes a lot more sense than specifying the number of columns to use! (e.g. {{reflist|colwidth=25em}}). Only using that solution would eliminate my concerns at least (although there would still be the technical problems).
— Apis (talk) 19:27, 16 May 2008 (UTC)

Okay, I think it would be much easier to sell editors on this than on completely disallowing two columns for references. Can changes be made to the template so that editors who typically use a fullscreen window won't even notice a change? - Dan Dank55 (talk)(mistakes) 19:35, 16 May 2008 (UTC)

But would this fix the current problem of two or more columns breaking the links between references and the reference number in the text? Whichis what brought me here in the first place. DuncanHill (talk) 19:42, 16 May 2008 (UTC)

Probably not. Maybe there is some way of disabling this for browsers that have poor support for multiple columns?
— Apis (talk) 20:58, 16 May 2008 (UTC)

I agree with Anomie's point that multi-column referencing increases accessibility, it should be added to the list of points in favour. Because references often consist of short sections of text and numbers (rather than whole sentences like the text in the article itself), they are easier to read if they are horizontally compressed. This is probably one of the reasons that academic journals use multiple columns for referencing. Multiple-column references are also much more attractive, which is perhaps why they're used in so many featured articles. Presumably if a lot of people found them less attractive, they'd have been removed. Ryan Paddy (talk) 22:36, 4 June 2008 (UTC)

Suggestion

Maybe something like this an acceptable solution:

1. If there are no parameters, render as usual. (i.e. {{reflist}} → no change).
2. If there is a colwidth parameter, use that as usual. (i.e. {{reflist|colwidth=25em}} → no change).
3. If there is a number of columns parameter larger than 1 then (regardless of how many columns specified) render as {{reflist|colwidth=25em}} or some other default value. (e.g. {{reflist|3}} → {{reflist|colwidth=25em}})?

There would still be the problems with other browsers than firefox (safari?). Maybe it's possible to disable multiple columns for some browsers?
— Apis (talk) 20:58, 16 May 2008 (UTC)

The 'colwidth=#em' solution has the additional bonus of working as intended if the user changes textsize in his (her) browser (firefox: ctrl +/- and ctrl 0 to reset) or if he uses another textsize specified in his CSS.
— Apis (talk) 21:05, 16 May 2008 (UTC)

I liked the idea, proposed above, of a "gadget" that you can set so that your browser renders multi-column reflists with a single column. That way, those of us using such obsolete technology as Sarafi would have the option of turning off multi-column formatting. Yilloslime (t) 21:59, 16 May 2008 (UTC)

I'll accept anything as long as I still have an option to show the references in columns, even if it is off by default. Gary King (talk) 00:39, 17 May 2008 (UTC)

I don't think there is any problem with reflist except for a few users who caused the problems themselves by editing monobook.css or who are using what appears to be a buggy or obscure browsers or ridiculously tiny monitors. For the claim that most people supporting have "widescreens" I'm calling BS. I work on a regular laptop and two desktops, with 14-15" monitors. Two cols look fine in 800x600 and 1024x780 resolutions, which are STANDARD resolutions, and the most well used across the net at over 75% of users having one or the other. There is a limit to catering to the lowest common denominator, and removing the two column format for a. The two column format works beautifully in the browsers that support them, and degrades fine for others browsers. In long, I strongly oppose removing the reflist|2 option or in trying to change it to use column width. I would, however, support updating the instructions to be more specific to note that two column should not be used unless an article has more than 20 well formatted refs (that number is just the one I currently use as a guide for changing, and I'd support something higher...people doing 2 cols for 3 refs is just silly), and I would also support 3 being the absolutely limit and only for use in extreme situations (300+ refs). AnmaFinotera (talk) 01:36, 17 May 2008 (UTC)

What is wrong with {{reflist|colwidth=25em}}?
— Apis (talk) 01:44, 17 May 2008 (UTC)

There is no point to it, and its forcing a width regardless of browser resolution. As far as I know, the system currently does a percentage based split depending on the number of columns, not a forced size regardless of the requested columns (which effectively is another way of removing the option to do 2 or 3 columns)AnmaFinotera (talk) 01:51, 17 May 2008 (UTC)

Hmm, no it's not a fixed width regardless of resolution. 25em means the browser will try to set the width relative to the font and fontsize. If you have a different stylesheet or change textsize (e.g. because you have problem reading the small font), the browser will adjust the column width. The browser will also adjust columnwidth to fit with the resolution (screenwidth). I think that is what's used on this page now: PlayStation 3.
— Apis (talk) 02:22, 17 May 2008 (UTC)

Your suggestion still effectively removes the 2 and 3 column options, which is not acceptable. If the editors an article want to use the width option instead of a column count, let them, but don't take the choice away from the vast majority using the # column options. AnmaFinotera (talk) 02:27, 17 May 2008 (UTC)

Yes, the whole point was to remove the # column option. Why is # columns better than colwidth?
— Apis (talk) 03:06, 17 May 2008 (UTC)

And my whole point is that it shouldn't be removed period. AnmaFinotera (talk) 03:18, 17 May 2008 (UTC)

Well, some people feel it's necessary, and some people have problem with it because it causes bugs in their browsers... and most people don't even know it's there because their browser dosn't display it.
— Apis (talk) 11:52, 17 May 2008 (UTC)

A small minority feel its "necessary" doesn't make it so. And Wikipedia isn't responsible for fixing a user's buggy browser. As for not displaying the columns at all, that's fine. If it degrades well, as it does in IE, it doesn't matter. AnmaFinotera (talk) 12:33, 17 May 2008 (UTC)

I don't think you understand the problem. What makes you think it's a small minority? I think it's a small minority that wants to keep them. I agree about IE not causing problem, I just wanted to point out that a lot of people isn't even aware of the existence of multicolumn reflists (IE has a user share of more than 75%), that fact in itself makes those who want to keep them "a small minority". The buggy browsers appear to be safari (I don't know if there are other, some have had problems with firefox as well). It obviously does not degrade well in safari. The "I don't care your browser suck" mentality isn't helpful. And there is accessibility problems with having the # columns option since that does not degrade well on different screen resolutions / fontsizes, whereas the colwidth option would. People that have problems reading small text change their fontsize, ignoring their problems is pretty arrogant. This solution would solve part of the problem at least, while still allowing the use of multiple columns. By doing this small change hardly anyone would even notice (the number of columns they see might change but most likely to a more sensible number). Although the problem with buggy browsers would have to be solved somehow.
— Apis (talk) 14:08, 17 May 2008 (UTC)

I think its arrogant to expect Wikipedia's current reflists to be completely overhauled because Safari is buggy, instead of demanding Safari fix your browser. A vocal minority is still a minority. Most people don't watch list this page. And don't blame me because Safari released a buggy browser. I use both Firefox and IE equally and have no issues with either. AnmaFinotera (talk) 17:48, 17 May 2008 (UTC)

It seems to me you don't understand the nature of the suggested change. It's certainly not a major overhaul. And the supporters are also a vocal minority. It's been mentioned on this page for several months while no one has shown any support for multi columns, and finally, this have been mentioned on four different big forums (not counting this page): WP:Village pump (proposals), WP:Manual of Style, WP:Accessibility and now also WP:Featured article candidates. What do you expect, flashing red text on the main page? And your only reason for not even considering this (tiny change most people won't even notice) is "There is no point to it", when many users have complained about problems. I realize it wouldn't affect you the slightest, but it might make other peoples day a bit easier.
— Apis (talk) 20:40, 17 May 2008 (UTC)

And if you bothered to read the discussion you would have noticed that the suggested fix for safari users (and others with troublesome browsers) have been to either: a) disable the feature only for safari, or b) have an option (gadget) to turn it off with.
— Apis (talk) 20:43, 17 May 2008 (UTC)

Oh yes. Please junk the multicolumn display for "normal" references ("normal" being non-{{harvnb}}). Those multi-column scrunches are not only useless, they are painful to read, and have flow problems as well. (check out this FA!) -- Fullstop (talk) 07:29, 21 May 2008 (UTC)

(Indeed. I've fixed it on that page now though (using colwidth) and updated link in above message to point to the intended version. / Apis (talk) 14:41, 21 May 2008 (UTC))

Make multiple columns a user preferences item

I also find the multiple columns formatting of references a bother. (For reasons indicated above - slow loading, columns overlap, harder to read short lines.) Use of the colwidth might help, but I would rather have the option of indicating in my preferences whether I do or don't want multiple columns. Then users who don't want them for whatever reason (compatibility, aesthetics, accessibility, whatever) could turn then off in one place, and users who do want them can have them.

The simplest thing would be a multi-column yes/no to just turn them off. Alternatively maybe some form of setting for display multiple columns if they are so wide (which would then interact with the colwidth setting in the template). (i.e. the page editor indicates what a reasonable width for the columns on this page is, and the user indicates that if the column width is less than so much, display multiple columns, otherwise leave them single column).

This could be set in either the user's preferences panel, or some way of customizing one's individual browser settings to adjust columns (for users who sometimes browse from wide screen devices, and sometimes from smaller screens).

It is rendering, so should be adjustable by the browser/user, not set by the editors. Making it a user preference should cut down on editorial discussions on individual pages. Zodon (talk) 06:55, 20 June 2008 (UTC)

Examples

Mike Huckabee: This is an example of inline references with raw links at three columns. Yes, this would be much better with citation templates, but it is going to be a chore. --—— Gadget850 (Ed) ^talk - 15:14, 21 May 2008 (UTC)