Template talk:Reflist/Archive 10

This is an archive of past discussions about Template:Reflist. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 5

←

Archive 8

→

Columns bug

Okay, I'm at the limit of my knowledge on this one, so could use some help... At Qutuz, the reflist was getting pretty long, so I attempted to put it in a two-column format: {{reflist|2}} instead of {{reflist}}. When I preview it (in Firefox 3.0.3), it looks fine. However, when I save it, the resulting page looks truncated, and though the Notes/reflist section is still there, the Reference and External links sections vanish. It's not a caching or purge problem, because if I make other changes to the page they show up fine. And, here's what's really weird, is that when I step through with diffs, the page looks fine,[1] but then when I try to look at it as just a normal article, it's truncated again. Anyone know what might be going on here? Could there be a malformed ref somewhere in the page that's causing this? I do note that of the 63 refs, #63 shows up in the left column instead of the right one, so the lefthand column shows up as 1-26, and 63, and then the righthand column is 27-62.

When I look at the page in IE, all sections appear normally, though of course the notes are in a single column.

Any ideas? --El on ka 06:15, 22 October 2008 (UTC)

I'm running FF3 and it looks fine. You can enable refTools through Special:Preferences → Gadgets. This adds a Cite button to the edit toolbar that now has an error check feature. There are no fatal reference errors in the article. Try purging the page. --—— Gadget850 (Ed) ^talk - 09:11, 22 October 2008 (UTC)

Here's another one: 2 June 2006 Forest Gate raid#References. There are 33 references in the article, but only 31 are showing up in the columned list. But click on the "edit" tab and preview the page, and all references show up normally. This is definitely not a caching problem, since I had never been to that page before someone alerted me to it. --El on ka 14:22, 30 October 2008 (UTC)

Looks fine with FF3. There have been no recent edits that would have fixed anything. --—— Gadget850 (Ed) ^talk - 15:48, 30 October 2008 (UTC)

I've looked at this on two different computers, both using FF3. On one computer, it looks fine. On the other, the reflist is mangled. However, it's only mangled when looking at the live page -- in preview it works fine. I'm at a complete loss as to why it would be doing this on some computers and not others, while using the same browser. Any suggestions? --El on ka 17:27, 30 October 2008 (UTC)

Have you tried a purge and then bypass your cache. --—— Gadget850 (Ed) ^talk - 17:36, 30 October 2008 (UTC)

I was unable to reproduce this problem in lynx. MrZaius^talk 06:32, 31 October 2008 (UTC)

I found another one that's showing the same bug: Neil Peart. Again, this is the first time I've viewed this page, so it's not a caching issue. When I look at the live article, it goes down to ref 57 and then I lose everything after that, including the categories. However, if I edit the page and click "preview", it displays perfectly (with 59 refs). It's just the live page that doesn't look right. The common factor in all of these is that I seem to lose 1 or 2 of the bottom refs, only in 2-column reflist format, only in Firefox. --El on ka 22:28, 31 October 2008 (UTC)

Okay, I did some playing with it, and I still can't figure out what's going on, but in case it's useful to anyone:

Neal Peart:
- Truncated after ref #57
- Shift-refresh: Page appears perfectly
Qutuz: Displaying ref #63 in the lefthand column
- Shift-refresh: Same (63 in the left column)
- Normal refresh: Displays clean
- Shift-refresh: Broken (63 in the left column)
Neil Peart: Mostly okay, but ref #58 is now in the lefthand column
- Shift-refresh: Clean
- Go to another article, then back to Peart: It goes down to #57 and everything else is truncated

Or in other words, I don't know what the heck is going on. :) Let me know if I can provide any other data, --El on ka 22:41, 31 October 2008 (UTC)

Howdy, folks. Elonka and I happened to be chatting and she mentioned this issue. I did some testing. I am running Win XP Pro SP2, and originally had Firefox 3.0.1. I couldn't reproduce the issue with 3.0.1. I just updated this PC to 3.0.3, and now I'm seeing the issue. That could just be coincidence, but I suspect we've stumbled across a browser rendering bug introduced in 3.0.2/3.0.3. Here's what I've seen:

Installed 3.0.3. Went to Qutuz. Looked okay.
Made a dummy edit. Preview looked okay. Saved.
Items 61 and 62 appear in the left column. 60 and 63 appear on the right. Screen capture.
Tried resizing the browser window. On first resize, everything reflowed and now problem has gone away.

I will update as I discover more. —DragonHawk (talk|hist) 00:28, 1 November 2008 (UTC)

More: I can confirm seeing the "page truncated" symptom as well. Screen cap. Notice how the vertical scroll bar in the browser window is all the way at the bottom, indicating page is at bottom of canvas. But the categories, external links, etc., are missing.

I caused this symptom to manifest simply by resizing my browser window width. No need to edit the page, refresh, or anything else; just a client-side resize, triggering a reflow of the page layout. Indeed, I can make it go away and come back, seemingly at random, just by repeatedly resizing the window. No pattern that I can discern, but fairly reproducible. In particular, resizing wider one "notch", then narrower again, doesn't necessarily make the symptom go away and then come right back. So it's apparently not a particular size that does it.

(For those looking to test, a tip: Resize using the keyboard. On Windows, Press [ALT]+[SPACE], then [S] (for Size), then right arrow key (select right border), then use left and right arrow keys to resize. This gives fine grain control.)

Hope this helps! —DragonHawk (talk|hist) 01:02, 1 November 2008 (UTC)

Interesting! I wasn't able to get the browser resizing to duplicate that bug on the previous articles, but I ran into another one where it happens, Infinite monkey theorem, and it acted exactly as you described: When I noticed that the bottom of the page after the references was truncated, I just resized my browser, and poof! everything was fixed. Then I maximized my browser, and it was broken again. Interesting bug... --El on ka 06:50, 1 November 2008 (UTC)

I've been able to reproduce the page truncation symptom by resizing my window, for both Firefox 3.0.1 and 3.0.3, on Fedora Linux 8. I doubt the Windows build of Firefox is that different, so I suspect I just got lucky with my brief testing with 3.0.1 before (that was before I discovered resizing could produce symptoms). The CSS markup on Wikipedia can be pretty complicated (beyond my understanding, anyway), so I suppose this could be an "undefined" construct on Wikipedia causing the problem. Or it could just be a bug in Firefox. I tried searching the Mozilla bug tracker and didn't find anything, but I don't really know what to look for. · I'm out of ideas. If there's anything more I can do to help, leave a message on my talk page. —DragonHawk (talk|hist) 01:49, 2 November 2008 (UTC)

Another article with the bug: Jesse James. When I first viewed it, I saw only down to ref #49. My browser was at "max" setting, filling the screen. I clicked it to get it to resize, and the article viewed properly just with that, correctly showing all 50 refs and the templates and categories. I tried various other settings for the browser size: Max, narrower, wider, but the article continued to display normally after that. The common theme though, is that the bug only shows up on articles that are in "reflist-2" format, and it always affects the bottom one or two refs on the righthand column. I'm trying to think if the problem always starts when I have a "max" browser, so I'll try browsing with a smaller window size and see if the bug ever shows up that way. --El on ka 16:05, 2 November 2008 (UTC)

Probably the bug can occur on any article that uses -moz-column-count or -moz-column-width; I've seen it a few times on this page, due to the example a few sections above. I also managed to make it stop occurring at one point by blanking my monobook.js; has anyone ever observed it while logged out? Does hitting tab on the page fix it for anyone else, or just me? Anyway, the best thing to do would be to report the bug at https://bugzilla.mozilla.org/ and hope they fix it. Anomie ⚔ 16:33, 2 November 2008 (UTC)

Not sure where to ask this…

I'm not sure if this is the right place to ask this or not, but when using the "group" functionality, is it possible for there to be a non-breaking space between whatever the group is called and the number generated? I was working on an article and using the word Note as a group name. In the body of the text the opening bracket and the word Note were on one line and the note number and the closing bracket were on the next line. This is, from my experience, not a big problem, but it certainly looks strange for the note indicator to be split by a line break. — Bellhalla (talk) 16:02, 19 November 2008 (UTC)

I see the issue. We could ask the developers to use a non-breaking space. You can fix this by putting the ref inside of {{nowrap}}. --—— Gadget850 (Ed) ^talk - 17:23, 19 November 2008 (UTC)

True, {{nowrap}} would fix it. The likelihood of someone having the same browser/monitor/resolution/font size/etc. combination seems like it would hardly be worth the effort. How would one go about notifying the developers on something like this? — Bellhalla (talk) 17:45, 19 November 2008 (UTC)

OK, let's get the devs to use non-breaking spaces. In the meantime, I added "sup.reference a {white-space: nowrap;}" to MediaWiki:Common.css, which should solve the problem for now. Having non-breaking spaces is a better solution, but this should be a nice quick fix. {{Nihiltres|talk|log}} 19:21, 19 November 2008 (UTC)

That works. You need to purge MediaWiki:Common.css then purge the article to see the change. --—— Gadget850 (Ed) ^talk - 19:40, 19 November 2008 (UTC)

You should only need to clear your cache to see the changes; try that first before purging Common.css please :) {{Nihiltres|talk|log}} 22:05, 19 November 2008 (UTC)

When is it appropriate to use more than 2 collumns?

Right now we are working on List of One Piece characters and as of right now there are 118 references and the number is only expected to grow as we go down the list and as of yet, a recent merge was done because many of the characters lacked enough citable real-word impact to have a separate article and given the characters we are referencing now, i doubt they will have enough either.じんない 20:33, 1 December 2008 (UTC)

In my opinion, only when using shortened footnotes. Remember that multiple columns only work for the 25% or so of readers using FireFox, so don't get hung up on columns. --—— Gadget850 (Ed) ^talk - 21:09, 1 December 2008 (UTC)

If you ask me you shouldn't be using 2 columns even. It's not like the article is going to run out of space and cramming the references into narrow columns just makes them hard to read.
—Apis (talk) 21:46, 1 December 2008 (UTC)

We're not about the standard number of references which number in the tens, but rather it would be in the hundreds.じんない 22:43, 1 December 2008 (UTC)

Is it not possible to consolidate your references somewhat? Are there no sources that talk about multiple characters? //roux editor review 22:45, 1 December 2008 (UTC)

In a neutral encyclopedia anyone can edit, complicated subjects will often demand many notes. The Featured Article Campaign history of the Roman military is a good example.

I suspect the interest in multiple columns comes about because these days many people have wide screens, and putting everything in a single column tends to cause an excess of whitespace. That's irritating to many. So for some non-trivial number of people, two columns is "easier to read". This is a case where the Right Thing will vary by OS, browser, screen size, font, and personal taste. I'd say the ideal solution would be something that allows the browser to choose the number of columns dynamically, but I don't think that exists. Given human nature, I'm guessing we'll have lots of disagreement over this for the foreseeable future. —DragonHawk (talk|hist) 23:02, 1 December 2008 (UTC)

Look into the colwidth parameter. Anomie ⚔ 00:39, 2 December 2008 (UTC)

So in order to make it less annoying to those people with wide screens it's fine to make it unreadable to the rest? Besides there is one flaw in this reasoning in that the main text is going to be in a single column. If you have a wide screen the text is unreadable unless you change the width of your browser window to something narrower. And once you do that the references become unreadable instead.

What you suggest exist and is even supported by the template, try {{reflist|colwidth=25em}}. It's been suggested that the default of using fixed number of columns should be changed to colwidth before, which I think would be a great improvement. Unfortunately there wasn't much interest last time it was suggested and you have to be an admin to change the template, so nothing happened.
—Apis (talk) 07:43, 2 December 2008 (UTC)

Unfortunately because of the complexities caused by 2 dubs instead of the usual 1, we can't use the main page for the article we'd normally cite in such a situation that lists production staff since a lot of them do not say which staff they work for.じんない 23:07, 1 December 2008 (UTC)

Columns fail gracefully in browsers which don't support them. There is no reason at all not to use columns if there is reason to believe that a referenc list would be shortened by their inclusion. Chris Cunningham (not at work) - talk 01:19, 2 December 2008 (UTC)

We are currently using 2 columns in the article. However because of the number of references, which is likely to only increase, I am wondering if we should bump it up to 3?じんない 02:21, 2 December 2008 (UTC)

Chris Cunningham: Please note that the people complaining about multiple columns all seem to be seeing the multiple columns just fine. Indeed, that's the problem. Their complaint is that multicol is "hard to read" for them. Obviously, you find that the multicol layout "looks better". I don't see any objective way of calling either POV "right". —DragonHawk (talk|hist) 07:08, 2 December 2008 (UTC)

A reference list will not be shortened in this case, and having more columns will not assist having more refs. If its unreadable with two columns, it will be even less readable with three. But perhaps that's the point?

But to answer the top poster's question... Its it affects legibility don't do it! There are some cases where it is in fact legitimate (e.g. harvnb usage) but that's not the case here. Chris Cunningham's if there is reason to believe that a referenc list would be shortened by their inclusion is a perfectly objective way of determining when it appropriate to use more columns. -- Fullstop (talk) 07:40, 2 December 2008 (UTC)

(ec) The point is that using more columns won't make the references any smaller, just harder to read. Besides, there is no reason to make them smaller, they are an important part of the article. It's not like there is a lack of space on the web page and they are at the end of the page anyway.

There are cases when it's reasonable to use multiple columns, and that is what Gadget850 mentioned above (i.e. shortened footnotes).

If you still really, really, want to use more than one column you could try {{reflist|colwidth=25em}} which is a better alternative than using a fixed number of columns at least. Still it's generally a bad idea IMHO.
—Apis (talk) 07:43, 2 December 2008 (UTC)

I should point out a couple of things. Firstly, I said "shorter" and not "smaller". The area occupied by the reference text may not be reduced, but in the case where a great many very short references are included this normally means a lot of dead air on the right hand side. Secondly, I find it difficult to believe that so many are arguing that it is difficult to read small text in short columns; most of us do it on a daily basis. Chris Cunningham (not at work) - talk 13:01, 2 December 2008 (UTC)

I've added instructions to the template documentation on how anyone can turn off multiple columns for their account. I doubt it'll stop the ... "concerned Wikipedians" ... who like to crusade against the feature though. They'll just insist that unregistered readers all share their reading disability. Anomie ⚔ 13:27, 2 December 2008 (UTC)

If you go back and read whats been said previously really carefully you'll notice that everyone said that "a great many very short references" is an example when it's perfectly fine to use multiple columns. But that's not the case here.

You might also be surprised to hear that a whole lot of people have trouble reading newspapers. Newspapers have to consider printing costs and the limited area in which they have to fit the text. Neither is a limitation on Wikipedia.
—Apis (talk) 15:30, 2 December 2008 (UTC)

I'd be very surprised indeed if someone provided evidence that columns of short lines were more difficult to read than long ones, yes. That's because it's the opposite of reality. Newspapers do not publish articles in columns simply because of "printing costs". Chris Cunningham (not at work) - talk 20:19, 2 December 2008 (UTC)

If you believe most books on typography, the ideal line length is 55-65 characters per line, including space and punctuations. (In English books they usually recommend 9-10 words, which for English is equivalent to 54-60 since the average word is 5 letters long (plus the trailing space). As a rule of thumb, line length should not be less than 40 or longer than 70.

So if you adjust your browser window so that the body text in the article is 60 characters per line (optimal) the references will also be 60 characters per line!
If you have split the references into two columns then the references is on average less than 30 characters per line.
If you have divided the references section into three columns the average line width will be less than 20!

~~Often the reference section contains URIs that are much longer than 40 characters, and they wont wrap at all. Instead they overlap the text in the column next to it, making things even worse.~~

Someone has made the font in the reference section smaller than that in the rest of the article, which also is really bad, but in this case it makes things a little better.

Newspapers use a small font in order to fit a lot of text onto as few pages as possible. They use multiple columns for practical reasons, it makes it easier to fit in many different length articles and images on the same page without causing an excess amount of unnecessary whitespace. If you don't think newspapers care about printing costs you are pretty naive. Newspapers aren't charity, they want to make money.

So, unless your references are on average much shorter than 70 characters, using more than one column is pointless, it will only make them harder to read.
—Apis (talk) 06:18, 3 December 2008 (UTC)

Actually most templates now convert urls into text hyperlinks, thus bypassing the problem of long urls that won't wrap.じんない 06:34, 3 December 2008 (UTC)

Nice, I hadn't noticed that. :)
—Apis (talk) 06:51, 3 December 2008 (UTC)

|2 is always shorter than |3

I've measured this time and time again: reflist|2 takes about 7/8ths as much vertical space as reflist|3 does on both Firefox and Google Chrome at a variety of widths. Can we make 2 the maximum, with anything larger clamped to 2? GetLinkPrimitiveParams (talk) 12:12, 2 January 2009 (UTC)

What's the point? Remove the capacity for doing the current default of one and force 2 throughout. Might as well take the standardization all the way. As an alternative, you might automatically go to two whenever more than 10 refs are present, if it's possible to detect. It may be better to fix this with a tweak to the CSS or MediaWiki code than a tweak to the template itself, allowing for support in astandard/substandard proprietary browsers. MrZaius^talk 13:03, 2 January 2009 (UTC)

Yes, it is possible to limit columns to a certain number. In my opinion, references using footnote or parenthetical (Harvard) style should limit to two columns and references with shortened notes to three. See Irish phonology for an example of parenthetical and Learned Hand for an example of shortened notes. In my opinion, gaining consensus on this is going to be difficult and frustrating; see the archives for previous discussions. My preference would be to do away with the width and column parameters, default the columns to two and add a parameter for shortened notes (short=yes). Logged in editors who dislike columns would be able to override this in their CSS. --—— Gadget850 (Ed) ^talk - 15:58, 2 January 2009 (UTC)

Re the original post, it may be shorter for you and in the cases you tested, but it is certainly not true always. Or is this example really 7/8 shorter for you?

^ Smith (2001), p. 432.
^ Smith (2001), p. 433.
^ Smith (2001), p. 434.
^ Smith (2001), p. 435.
^ Smith (2001), p. 436.
^ Smith (2001), p. 437.

^ Smith (2001), p. 432.
^ Smith (2001), p. 433.
^ Smith (2001), p. 434.
^ Smith (2001), p. 435.
^ Smith (2001), p. 436.
^ Smith (2001), p. 437.

Regarding forcing 2 columns for all uses, good luck getting consensus to change the 400000+ articles using reflist with a single column. I could support making the maximum 2 or 3; if you want to go that route, I suggest getting appropriate CSS rules added to MediaWiki:Common.css (let me know and I can write them), then after the requisite 30 days remove the corresponding style parameters from this template. If you also want to force colwidth to a specific value when used, we could get rid of the inline styles completely. Anomie ⚔ 18:11, 2 January 2009 (UTC)

Glitch with list syntax?

I just updated the U2 3D article and noticed there is something funny about the reflist generated in the article. Apparently any of the Wikified links in the citation tags were replaced with Wikified links from the article (look at U2 3D#References and you'll see what I mean). The issue is apparent with both Firefox and Internet Explorer. All citation templates appare to be effected so it cannot be the individual templates with the problem. I have no idea where the source of the glitch is, but hopefully someone here can figure out the issue. –Dream out loud (talk) 21:29, 2 February 2009 (UTC)

See this. D.M.N. (talk) 21:33, 2 February 2009 (UTC)

Ref list on page 'Eucalypt"

A minor spelling mistake in the name of ref 2 - it should be Costermans, L. Administrator please amend.

Hashlete (talk) 17:56, 15 February 2009 (UTC)

I've fixed it for you. DuncanHill (talk) 18:03, 15 February 2009 (UTC)