Template talk:Reflist/Archive 16

Archive 10

←

Archive 14

Archive 15

Archive 16

Archive 17

Archive 18

→

Archive 20

Changing syntax

I noticed an editor is changing invocations of {{reflist|2}} to {{reflist|colwidth=30em}}. At the moment these invocations do exactly the same thing, so the change has no effect. But it seems like a bad change, because:

• We might change the default width for 2 columns to 25em or 35em, and the hard-coded invocations wouldn't be updated
• We might even turn off the em-based widths, if people don't like them. The hardcoded ones would again not change back.

The whole point of having a template is so that a single change can affect all the relevant pages; that's why we don't subst this template. So I think that hard-coding the column width should be avoided. In fact, it seems like a good idea to me for a one-time bot job to change all the 30em ones to "2", so that they will fall back into the default style. I'd like to hear what other people think. — Carl (CBM · talk) 02:31, 23 November 2010 (UTC)

I don't know that I'd go as far as having a bot change existing 30em instances, but certainly that editor should probably stop. Anomie⚔ 04:35, 23 November 2010 (UTC)

Reflist template proposal

Editors who watch this page may be interested in Wikipedia:Village_pump_(proposals)#Change_to_template:reflist_fontsize_wiki-wide?. Please leave any comments on the village pump page. — Carl (CBM · talk) 20:30, 29 November 2010 (UTC)

Consistency of presentation

This article uses an odd mishmash of {{reflist}} and {{Reflist}}, {{refbegin}} and {{Refbegin}}. Could we please pick a favourite style and use it consistently throughout?
Thanks, Varlaam (talk) 23:33, 30 November 2010 (UTC)

YDone. SnottyWong ^babble 00:51, 1 December 2010 (UTC)

Thank you. That was very fast. Varlaam (talk) 01:05, 1 December 2010 (UTC)

Anomalous behaviour

On Paul Nelson (creationist), a {{Reflist|2}} template is resulting in the references being displayed in 4 columns (ugly!) on my 1920-wide screen. Is it possible that there's a bug in the scripting for this template? Hrafn^Talk_Stalk^(P) 05:14, 29 November 2010 (UTC)

The template parameters have changed. If you look at the Columns heading on the template page, you can see that the parameters produce a scalable width now. You can force a two-column display using the "colcount" parameter, but it's not recommended because of users who might have small screens. --Andy Walsh (talk) 05:23, 29 November 2010 (UTC)

Okay, I'm not entirely sure exactly how X en translates to Y columns on Z screenwidth (although I can recognise the general relationship), but I cannot help but thinking that 30em may be too low as the lowest non-set-to-an-explicit-single-column standard (just-a-number) parameter. Larger screen resolutions are becoming increasingly the norm (a quick check on a price-comparison site I use turned up only 2% of current models with resolution of only 1024x768 or less), so I don't think it's too unreasonable to give some thought to them. Hrafn^Talk_Stalk^(P) 06:05, 29 November 2010 (UTC)

This valid point seems to be getting brought up over and over again by different editors, but it is largely being ignored by the editor(s) who have the access and knowledge to fix the problem. What's the next step here? Do we need to start some sort of official discussion to find out if there's a consensus to either revert the recent changes to this template (which is my personal preference) or to increase the em values? The recent changes to this template are not working adequately, and they need to be either reverted or modified. The editor(s) who made these changes need to take responsibility for fixing the perceived problems that have been introduced. SnottyWong ^speak 07:05, 29 November 2010 (UTC)

I don't have any preference one way or the other. The question is how to balance some users' desire to automatically have wider screens get more columns with other users' desire not to do that. The original RFC above, which was announced on the village pump as well, showed at least preliminary support for making the column count more flexible (see "Proposal to change implementation" above).

I'd say: make some screenshots of the actual effects of the new code, and then start another RFC. We can announce that on the village pump as well. If there is consensus to stick with the hard-coded column counts, it won't be hard to go back to that. — Carl (CBM · talk) 12:02, 29 November 2010 (UTC)

The problem as I see it: Some users are concerned about accessibility of fixed column counts on small devices, so they push for flexible columns based on width. But then users on extremely large devices complain because basing it on width gives them more columns than they prefer, and increasing the width for them causes users on mid-sized devices to complain that they then don't get any columns.

It may be that we can revamp the CSS classes (again) so people can override "references-columns-2", "references-columns-3", and so on to suit their preferences. But I wouldn't be extremely surprised if that just moves the dispute from "what should the width be?" to "what should the default width be?". Anomie⚔ 16:26, 29 November 2010 (UTC)

Yes, I think that's what would happen. Also, editors of a specific article have no real way to measure what the width should be apart from looking at whether they use short footnotes or long footnotes. There's no reason to think that the average reader of one article has a different screen than the average reader of another article, so tweaking the column width by a few ems from one article to another doesn't make sense. — Carl (CBM · talk) 20:54, 29 November 2010 (UTC)

Visual comparison

I'll repost what I posted earlier at Wikipedia talk:WikiProject Usability#Ideal column width for references:

This is 20em.

This is 25em.

This is 30em.

This is 35em.

This is 40em.

This is 45em.

This is 50em.

These are the basic renditions using the default font-size. As you know, using 'em' as a measure depends on the font-size. Since references use a smaller font of 90% (when using {{reflist}}, and also dependent on browser settings and personal CSS settings), this will affect the column-size as well, but will by defention contain the same ammount of text on a line.

This is 20em.

This is 25em.

This is 30em.

This is 35em.

This is 40em.

This is 45em.

This is 50em.

The column-width CSS property is also the minimum column-size. In other words: columns will never be smaller then the given value, and can be up to twice the given width. Here are columns with the given values:

• This is 20em.
• This is 20em.
• This is 20em.
• This is 20em.
• This is 20em.
• This is 20em.
• This is 20em.
• This is 20em.
• This is 20em.
• This is 20em.
• This is 20em.
• This is 20em.

• This is 25em.
• This is 25em.
• This is 25em.
• This is 25em.
• This is 25em.
• This is 25em.
• This is 25em.
• This is 25em.
• This is 25em.
• This is 25em.
• This is 25em.
• This is 25em.

• This is 30em.
• This is 30em.
• This is 30em.
• This is 30em.
• This is 30em.
• This is 30em.
• This is 30em.
• This is 30em.
• This is 30em.
• This is 30em.

• This is 35em.
• This is 35em.
• This is 35em.
• This is 35em.
• This is 35em.
• This is 35em.
• This is 35em.
• This is 35em.
• This is 35em.
• This is 35em.

• This is 40em.
• This is 40em.
• This is 40em.
• This is 40em.
• This is 40em.
• This is 40em.
• This is 40em.
• This is 40em.
• This is 40em.
• This is 40em.

• This is 45em.
• This is 45em.
• This is 45em.
• This is 45em.
• This is 45em.
• This is 45em.
• This is 45em.
• This is 45em.

• This is 50em.
• This is 50em.
• This is 50em.
• This is 50em.
• This is 50em.
• This is 50em.
• This is 50em.
• This is 50em.

What I see on my screen (1280 wide and default font settings on Windows) is 25em and 30em displaying 3 columns, 40em giving 2 columns, and 50em results in only one column. But this can be different for other users, depending on their own browser font settings and personal CSS. — Edokter • Talk • 12:17, 29 November 2010 (UTC)

• On a 1920-wide screen (default Firefox font size) for the final ("Here are columns with the given values") grouping, 30em is identical to 35em, 40 em is identical to 45 em, and the final (rightmost) column on the first 6 widths (50em is the exception) are twice the width of the previous columns. (Excluding the final double-width columns), the column widths are: 20em: 1/7th of the screen, 25em 1/5th, 30/35em 1/4, 40/45em 1/3, 50em 1/2.Hrafn^Talk_Stalk^(P) 13:01, 29 November 2010 (UTC)
  • There is only one situation where columns would display non-uniform; when both column-count and column-width are specified. Do you have any column CSS code in your vector.css that overrides the template's CSS? — Edokter • Talk • 13:33, 29 November 2010 (UTC)
  • Scrap that; it seems Firefox does act a little quirky because it tries to distribute the material evenly to fil the columns. How does it look now? — Edokter • Talk • 13:40, 29 November 2010 (UTC)
    • Better. Columns are now all of even width. However 30em is still the same as 35em & 40em still the same as 45em -- but I suspect that is WAD (working as designed). I would suggest having the widest 'basic' columning (i.e. {{Reflist|2}} ) no narrower than 40em. If people want narrower footnotes, they can always plug in a higher number (is there any hard limit that means we can't extend the numbers up to a {{Reflist|5}} say, to still do 20em?). Hrafn^Talk_Stalk^(P) 14:24, 29 November 2010 (UTC)
      • 40em would result in no columns on smaller screens (including 1024x768), so 2=35em would be my preference. On the other hand, I have been playing with the sandbox, doing away with the auto-calculating columns so reflist|2 would result in two columns again. Added bonus is that parameter names are no longer needed; you can use {{reflist|2}} or simply {{reflist|30em}}. — Edokter • Talk • 15:26, 29 November 2010 (UTC)
        • If we switch back to a hard-coded column count, we need to update the documentation to be very clear that articles that already specify a fixed columnn count should be left that way, not changed to a flexible count just for the sake of it. — Carl (CBM · talk) 15:35, 29 November 2010 (UTC)
        • (edit conflict)From Andy Walsh's comment in the section above, I thought the problem was too many columns for low-res screens, not too few. I do however really like your version that takes a number or an en-number as parameter -- being able to get whichever you like without having to plug colcount= or colwidth= parameter-titles would mean that everybody should be able to get the columning they want with minimal fuss. Hrafn^Talk_Stalk^(P) 15:38, 29 November 2010 (UTC)
          • My main question is whether there is any preference towards flexible column counts. It doesn't help much if we have separate parameters but people change them en masse from one type to another. If there is really a preference towards flexible columns, then it makes sense for "2" to be an abbreviation for some particular column width. If there is no such preference, then "2" should mean "2 columns, regardless", and people should avoid replacing that with a width-based parameter. — Carl (CBM · talk) 15:48, 29 November 2010 (UTC)
• (←) Perhaps we better get back to the fixed column count. As it is now, people come in complaining that there are too many columns (on wide screens), or no columns at all (on small screens). So while the idea was good, the best default behaviour should be a fixed column count. — Edokter • Talk • 16:28, 29 November 2010 (UTC)

• I tend to agree that going back to fixed columns is the best solution in the short term. It would be ideal if we could figure out how to get rid of hard-coded columns in such a way that small resolution monitors would default to 1 column instead of zero columns while large monitors wouldn't routinely be looking at 4+ columns with a lot of wrapped text. SnottyWong ^chatter 17:32, 29 November 2010 (UTC)

• I support reverting the implementation of {{Reflist|2}} and relatives as a fixed number of columns, but I oppose CBM's initiative against |colwidth in general and his misinterpretation of this conversation as consensus against the use of it, as at Wikipedia:Administrators' noticeboard/Incidents#User:CBM, a case of WP:WIKIHOUNDING —chaos5023 (talk) 20:32, 29 November 2010 (UTC)

• • Perhaps you're confused about my goal. I don't care which style is used, but I want to either establish a consensus that we should switch pages to flexible columns, or that we should not switch pages to flexible columns. A month ago, I started the the section "2/3 column format" above to seek consensus about that, and the initial consensus was to switch to flexible columns. However, if it turns out that a broader consensus is not to switch, that's fine too. Either way, we should be able to decide which one is actually the desired behavior for the template to have, and update the template documentation to say which set of parameters should be used. That's my understanding of the goal of these threads. — Carl (CBM · talk) 20:41, 29 November 2010 (UTC)

• I must now support reverting the recent changes. I didn't realize the effects of it (which I myself experience) when I supported the initial change. /ƒETCHCOMMS/ 01:58, 30 November 2010 (UTC)

• Support reversion to the number parameter indicating columns (e.g. {{reflist|2}} = 2 columns), but also support Edokter's {{reflist|30em}} implementation -- I see no problem with this as long as editors on a given article explicitly decide on this, and know what they're doing. I think a Darwinian approach is a good idea -- let editors experiment (as opposed to having experiments imposed upon them without them knowing), and see what WP:CONSENSUS develops as to what's most readable on the widest range of screens. Hrafn^Talk_Stalk^(P) 02:21, 30 November 2010 (UTC)
  • Can you explain what you mean by "experiment"? On one hand, before the change, some editors were changing articles en masse to the colwidth-style formatting. That wasn't an experiment, the change was made just for its own sake. Just reverting the changes to the template won't help that, we'll just end up with all the articles manually changed. On the other hand, given the wide variation in what users see, how could one or two users sensibly decide that one version is better than another for all readers of a particular article? — Carl (CBM · talk) 03:05, 30 November 2010 (UTC)
    • I mean the normal process of somebody deciding that the formatting looks ugly & WP:BOLDly changing it to one that they think looks better. Potentially with others disagreeing and reaching a compromise WP:CONSENSUS on article talk. I would not however consider "changing articles en masse" to be part of such an experimental process -- as it would seem to indicate an ex ante dogmatic view rather than an ex post experimental one. Hrafn^Talk_Stalk^(P) 03:54, 30 November 2010 (UTC)
      • How would a few editors on a specific page know what looks good for the majority of readers (who won't comment on the talk page if the article looks bad)? Even in this thread we see that different users can have widely different experiences with the same pages. — Carl (CBM · talk) 04:11, 30 November 2010 (UTC)
        • We do the exact same thing we do with every single other presentation issue — we go by what looks good to us, with the working assumption that our experience generalizes to some degree, and if others find otherwise, they change it, then we talk about it, get more people into it (and so inherently increase the statistical validity of the sample we represent), incorporate policy and guidelines, etc etc. These are the tools we have. Shall we contrariwise begin commissioning a usability study every time somebody wants to move an image from the left to the right? —chaos5023 (talk) 04:28, 30 November 2010 (UTC)
          • But the trend here is that the reference appearance does not generalize very well. We have editors complaining they have too many columns with their 1900px wide displays and editors with too few columns on a 1024px display. Apart from that, we have historically strongly discouraged editors from tweaking reference formatting based on what they think looks better. It opens a can of worms (and leads to a lot of unproductive discussions) if many editors go around changing articles based on what they personally feel looks better. Of course editors could already experiment by just replacing the template with hard-coded formatting, I guess. — Carl (CBM · talk) 04:48, 30 November 2010 (UTC)
            • Because letting the small number of editors, who (in the absence of {{Reflist}} doing funny things, bringing more editors here) are the regulars on this template talk, decide what (theoretically) should look good on all articles, under all resolutions has turned out so well? Not only do screen resolutions vary widely, but so too do footnoting styles. Some articles have very terse footnotes, others (particularly more controversial articles) tend more to verbose footnotes, often with quotations, and sometimes with bullet-pointed lists of citations within them -- with the latter generally needing wider columning than the former. One size does not fit all. I do not think a 'centralised planning' approach works particularly well for this -- and such centralisation would appear to be against the general Wikipedia ethos. Hrafn^Talk_Stalk^(P) 05:07, 30 November 2010 (UTC)
              • • I would be perfectly fine if we clarified in this template documentation that the formatting of an article should be decided by the regular editors of the article. The difficulty is how to write documentation to encourage that while discouraging people from also imposing their preferences on articles they are not regular editors of. There are always editors who are happy to "experiment" with every article they see, regardless whether they will ever look at it again. — Carl (CBM · talk) 05:26, 30 November 2010 (UTC)
                  • I"m not opposed to a "centralized" approach to the visual appearance of references, however I think this little experiment proves that we do not possess the tools to do so correctly. In my opinion, we would need:
                    1. A way to determine the quantity and average length of citations in an article. If an article has a lot of short citations, then split them into 2 or 3 columns. Under any other circumstances (i.e. only a small number of citations of whatever length, or the existence of some citations which are quite long) would result in 1 column.
                    2. A way to determine the reader's screen resolution and adjust the columns accordingly.
                  • Without these tools, we are unable to determine the correct format of the references section in an automated way for every article. Therefore, until we do have the tools, we must leave it up to the individual article authors to decide what looks best. SnottyWong ^express 15:29, 30 November 2010 (UTC)

Point 2 (determining screen resolution and adjusting columns accordingly) might be doable in Javascript. That would be better than one-size fits all. Rd232 ^talk 19:24, 1 December 2010 (UTC)

It seems clear that dynamic column widths did not quite work as expected, and the consensus is to revert back to using fixed column counts. I have done so, and in the process added the possibility to use {{reflist|XXem}} (without the need for colwidth=). — Edokter • Talk • 12:34, 30 November 2010 (UTC)

I agree with User:Hrafn 100%. If you enter {{Reflist|2}} this template should produce a fixed number of two columns, period. If you enter {{Reflist|colwidth=30em}} it should produce a varying number of 30 em wide columns. It still puzzles me how User:CBM got us into this experiment. —bender235 (talk) 19:27, 1 December 2010 (UTC)

I made the original proposal one month ago because the usability project seemed to be claiming that we should switch from the fixed-count method to the width-based method quite generally. However, there is no way to tell whether there was actually broad consensus for that sort of change. It seemed at first like there was consensus, so the change was made. That led to more feedback, and more it is now clear that there is not consensus for any large-scale switch to width-based formatting. Given that fact, it stands to reason that articles that use a fixed-count format should not be changed en masse to the width-based method, because (despite what the usability project thinks) there is not consensus that a width-based format is an improvement. — Carl (CBM · talk) 21:08, 1 December 2010 (UTC)

Yeah, this is the sort of reasoning that raises my hackles with you. A clear consensus that {{Reflist}} should not misrepresent its behavior by taking a specification for a fixed number of columns and turning that into a width-based columnization is absolutely not the same thing as a consensus that width-based columns are not an improvement over fixed column counts. —chaos5023 (talk) 21:11, 1 December 2010 (UTC)

The complaints were not about the syntax of the template. The post above reads, "On Paul Nelson (creationist), a {{Reflist|2}} template is resulting in the references being displayed in 4 columns (ugly!) on my 1920-wide screen. " The issue there is that 4 columns was not desired, regardless of the template syntax. The issue was not that someone forgot to change the template to {{reflist|4}}. If someone edits the article to make it say {{reflist|30em}}, it will still have the same actual problem, which is that the article had 4 columns on that person's monitor. — Carl (CBM · talk) 21:28, 1 December 2010 (UTC)

Someone else wrote, "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." That person was not complaining about syntax, they complained because 3 columns looks awful to them. If the syntax changed to 30em, it will still look awful to them - the issue isn't the syntax. — Carl (CBM · talk) 21:31, 1 December 2010 (UTC)

Deprecate colwidth=

Since the template now auto-detects wether a coloumn count or width is passed, we really do not need the colwidth= parameter name anymore. A search shows that 22,194 articles still uses the parameter. Would it be a good idea to rent a bot to remove those, so I can remove the extranious code from the template? — Edokter • Talk • 18:31, 14 December 2010 (UTC)

It doesn't seem like it's worth a bot job of that size just to simplify the template a little. We could ask the AWB people to make it a general fix if their code allows. It's pretty harmless to have the parameter, though. — Carl (CBM · talk) 18:47, 14 December 2010 (UTC)

We might as well remove the feature as a whole, because thanks to CBM, no one is allowed to implement it on any article. I suggest we should start a poll on whether to ban "colwidth", because why have it if we can't implement it anywhere? —bender235 (talk) 23:06, 14 December 2010 (UTC)

Just because a feature is there, doesn't mean we must use it in all articles. The colwidth feature has appropriate uses, particularely when listing short references and footnotes, but not for references in general. — Edokter • Talk • 00:45, 15 December 2010 (UTC)

Of course not. But according to CBM, WP:CITEHOW simply prohibits anyone from changing the established style of the reference list. From now on, no one is allowed to implement {{Reflist|colwidth=...}} on any article that didn't originally use this feature. So we might as well delete the feature. —bender235 (talk) 00:49, 15 December 2010 (UTC)

Wrong. There is nothing wrong with changing the style, provided it is appropriate for that article. Mass-converting all references to use colwidth however, is contra-productive, as it goes against a standing consensus for an established format. More specifically, many have objected to colwidth=30em, simply because it results in the columns being too narrow. So it is not suprising that people ask you to stop changing all the references. That is all. — Edokter • Talk • 01:28, 15 December 2010 (UTC)

Wait a second, "mass-converting"? Among my last 1,000 edits, I added "colwidth=30em" to no more than 13 articles [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13]. Please tell me in which of these cases it was not appropriate. I'd like to know to avoid future irritation. —bender235 (talk) 01:39, 15 December 2010 (UTC)

Of those above, only [4], [11] and [12] are appropriate. The other are too narrow; the references take up too many lines. And as Carl said, I only proposed to deprecated the named parameter, as you can now directly pass the width. — Edokter • Talk • 13:06, 15 December 2010 (UTC)

Okay, thanks. Feel free to revert my edits where ever you don't consider them appropriate. Or you could just widen the columns where they are too narrow. I'd like to do that on my own, but I'm afraid I'm not allowed to. —bender235 (talk) 22:43, 15 December 2010 (UTC)

Addendum: I've now widened the columns to 45em on each of these articles, except those where you considered it appropiate to use 30em. —bender235 (talk) 15:04, 17 December 2010 (UTC)

You can always use colwidth on new articles that you create. Or if editors want to switch to it during a period of heavy editing, e.g. during an FA review, that could be OK. The thing that editors should not do is go around changing from one optional style to another on articles that they don't otherwise have any intention of editing. — Carl (CBM · talk) 02:54, 15 December 2010 (UTC)

I think you've misunderstood the proposal; it's not to remove the fixed-column-width feature from the template, which can now be accessed by {{Reflist|30em}}, just the named parameter. Rd232 ^talk 08:42, 15 December 2010 (UTC)

There is now a somewhat related discussion Wikipedia:Village_pump_(proposals)#Recommending_columns_in_reference_lists_longer_than_20_entries. Rd232 ^talk 08:42, 15 December 2010 (UTC)