Template talk:Reflist/Archive 4

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, the end-braces   need to be moved outside of the quotes   so that the   attribute is closed inside the template.

Thanks in advance,

CosmicBen (talk) 11:32, 30 April 2008 (UTC)
 * ✅ 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 tags.

AND !!
Parameter value: test data.

As a reference:.

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 FOOTNOTE. Grace notes T § 04:10, 1 May 2008 (UTC)
 * Thanks Gracenotes. Peet Ern (talk) 04:26, 1 May 2008 (UTC)

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) —WWoods (talk) 17:44, 16 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, so on narrow displays it'll become a single column.

Well, to throw in my take on the arguments here: All in all, I personally see nothing like consensus to remove column support. Anomie⚔ 17:58, 16 May 2008 (UTC)
 * "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?


 * 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.

— Apis (talk ) 19:27, 16 May 2008 (UTC)''
 * 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. ). Only using that solution would eliminate my concerns at least (although there would still be the technical problems). ''


 * 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)

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

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: 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)
 * 1) If there are no parameters, render as usual. (i.e.  → no change).
 * 2) If there is a colwidth parameter, use that as usual. (i.e.  → no change).
 * 3) If there is a number of columns parameter larger than 1 then (regardless of how many columns specified) render as  or some other default value. (e.g.   →  )?

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)

— Apis (talk ) 01:44, 17 May 2008 (UTC)''
 * What is wrong with ? ''


 * 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)

— Apis (talk ) 02:22, 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. ''

— <span style="color: rgb(5, 85, 5);">Apis (<span style="color: rgb(5, 85, 5);">talk ) 03:06, 17 May 2008 (UTC)'' — <span style="color: rgb(5, 85, 5);">Apis (<span style="color: rgb(5, 85, 5);">talk ) 11:52, 17 May 2008 (UTC)'' — <span style="color: rgb(5, 85, 5);">Apis (<span style="color: rgb(5, 85, 5);">talk ) 14:08, 17 May 2008 (UTC)'' — <span style="color: rgb(5, 85, 5);">Apis (<span style="color: rgb(5, 85, 5);">talk ) 20:40, 17 May 2008 (UTC)'' — <span style="color: rgb(5, 85, 5);">Apis (<span style="color: rgb(5, 85, 5);">talk ) 20:43, 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? ''
 * 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. ''
 * 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. ''
 * 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. ''
 * 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. ''
 * 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. / <span style="color: rgb(5, 85, 5);">Apis (<span style="color: rgb(5, 85, 5);">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)  <sup style="color:darkblue;">talk  -  15:14, 21 May 2008 (UTC)