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.
For reflist 30em is generally an accepted standard for splitting into multiple columns based on the screen height and specifications. I am not a tecnical person but I found while working on multiple terminals on multiple setups (varying between 12" netbook, 15" desktop, 14" laptop and 15" laptop screens; some running windows xp while others running windows 7 with or without specific drivers installed), that the 30em code does not do the work correctly ending up in displaying the references in only a single column. I have experimented and found that 25-29em works perfectly. I do not know the cause of the discrepancy. But may I suggest experienced users to look deeper into topic and decide if 25em should be revised to be the standard. DiptanshuTalk14:05, 5 November 2013 (UTC)
30em is not ment to force columns; the template will split into columns if each column has a minimum of 30em width available. This means theat 30em can result in widths of 30-59.9em. — Edokter (talk) — 17:18, 5 November 2013 (UTC)
It's not critical; it's been discussed before, the last time was less than six months ago, there have been others before that. If I'm using Shortened footnotes, I start off with 20em, and if a large number of entries wrap to two lines, I increase to 25em, and so on. See NBR 224 and 420 Classes#Notes for an example of a reflist having columns 20em wide - on my monitor (1280 pixels wide), I see four columns here, and none are wrapped onto a second line. I believe that it drops to three columns for a monitor less than about 1152 wide. If the refs are a mixture of short and full-length, I may start at 30em and increase if the wrapping is excessive. --Redrose64 (talk) 00:27, 6 November 2013 (UTC)
Its a standard practice to break the references into two columns and I have found that it becomes easier to track the references rather than following it throughout the entire length of a line. Unless too small, most screens have the capacity to display a two column layout and for wider screens a three or four column might also be fine if it is that much wide, but I feel that it looks shabby unless at least a two column layout is displayed on a page with several references. My experiements suggest that a 25em or even 29em code works good to serve the purpose. For people with wider screens it hardly makes a difference but for people with slighly smaller screens, it works perfectly to split the number of columns to two (from one). Most editors use {{reflist|30em}}} not knowing that their purpose is not being served for 13.75% users (of 1024px screen width) as on Global browser statistics in an attempt to benefit 19.73% users of higher screen resoulution. But using {{reflist|25em}}} they could have well benefitted 13.75% + 19.73% users achieve the same task satisfactorily. I insist that the text on the reflist template documentation page be modified to replace 30em with 25em and also insist to popularise its use.DiptanshuTalk10:01, 7 November 2013 (UTC)
I really do. I have mentioned the justification that I have. I have also gone through the contents of the discussions in Archive 20 and Archive 21 and am sure than the points I that I mentioned have been inadvertently missed. You can see the references columns of Shwachman–Bodian–Diamond syndrome which I have set as 28em (anything between 25 and 29 should be good)) and I hope it works no lesser than 30em though it renders better for many. I think if other editors do not oppose, a consensus can be thought to have been reached. DiptanshuTalk09:24, 8 November 2013 (UTC)
Oppose. Editor Diptanshu has not provided any evidence that the currently recommended 30em column width is unsuitable for the majority of users. Insistence on a change without supporting evidence merely hardens my opposition.
What you see on your screen is not the same as what other people see. The em unit relies on a lot of properties, of which screen width is only one. Font, fontsize, zoom level, browser metrics, to name a few, are also influencing column widths. So you cannot rely on just what you see on your screen. 30em is a good base width to guarantee enough text can be displayed in a column for normal references. — Edokter (talk) — 21:34, 8 November 2013 (UTC)
Ok. Let me go point by point. Firstly, what Trappist the monk is asking for is proof of superiority but what needs to be established first is non-inferiority which means that what I propose is at least equally effective if not more effective. I have not found any evidence that it would be any less effective. If any of you find any evidence that it works in an inferior manner, I would definitely like to withdraw my proposal. Opinion is welcome about how 25em or 28em can be inferior to 30em so that methods of finding evidence can be devised accordingly. In lack of evidence non-inferiority of the proposal can be assumed and I do not think people should debate on a non-inferior intervention because it automatically assumes the capacity of an equal. Now regarding the second part about the comment by Edokter which relates to universality of my observations: Since I am not a technical person, I automatically assume that I am not the right person to comment on what exactly can be considered as a valid evidence of the universality of my findings. In my initial post, I have already mentioned that my findings are not limited to a single setup and involves observations on multiple setups varying between 12" netbook, 15" desktop, 14" laptop and 15" laptop screens; some running windows xp while others running windows 7 with or without specific drivers installed. So what exactly is being asked of me? Would screenshots of the respective setups be considered valid? I invite opinions on which evidences could be considered as valid evidence to back up my simple proposal. Sorry for writing long answers but I was not sure if shorter ones could satisfy. Sorry if I sound rude but I do not intend to. I was merely presenting scientific dictums and methodology that I know of.DiptanshuTalk08:28, 9 November 2013 (UTC)
No further suggestions or comments! Would this equal be therefore considered a consensus (due to non availability of better suggestions or lack of people interested in adhering to scientific methodology or lack of interest in a seemingly less important topic)? DiptanshuTalk15:56, 11 November 2013 (UTC)
Consensus is expressed through supportive comments, never by absense of any opposing comments (which there are). So there definitely is no consensus to implement your suggestion. — Edokter (talk) — 16:20, 11 November 2013 (UTC)
This has been discussed before. The reason that two formats are allowed is that it is not clear that the 30 format is better on most pages. It is worse on mine -- forces one column. Better on mine therefore is the forced 2 column split. As with date formats, where more than one is acceptable, don't edit war for the one you prefer -- go, as we do with dates -- with the prior format. If you want to force the project to prefer your approach, do that at MOS.--Epeefleche (talk) 02:32, 22 November 2013 (UTC)
With this discussion, five editors have already expressed (some through discussion, others implicitly through their edits) that 30em is the preferred format. So the "no consensus" or the "it's been discussed before" arguments simply don't wash. Therefore, any reversions back to the {{reflist|2}} format demonstrates an WP:ICANTHEARYOU and WP:IDONTLIKEIT attitude, which is purely disruptive and gets us no where. And please don't tell us not to "edit war for the one you prefer," because you used the statement 30em "is worse on [yours]" as the reasoning behind reverting my edits in Ian Kinsler. An RFC may be the way to solve this. —Bloom6132 (talk) 03:32, 22 November 2013 (UTC)
Older Internet Explorers don't support the columning feature, but many version of Chrome do support it. Different aspect ratio screens output the columns differently, 1280x1024 (NS) vs 1920x1200 (WS), but I don't have any issues with it. 30 format is probably better than 2 column split, especially on higher pixel wider screens. • Sbmeirow • Talk • 09:15, 22 November 2013 (UTC)
The fun part is that the consensus has been reached by battling on the wrong topic. Right after the initial part of the discussion, I had accepted that the em system is supposed to be an improvement over the |2 format for fixed two columns. What I had been suggesting is a step further. I had observed that instead of doing its job, 30em gives a worse performance in certain scenarios and Epeefleche justifies my statement. (Has anybody cared to brainstorm how to provide a remedy to the problem?) I further observed that instead of using 30em, if anything between 25-29em is used, it not only serves the purpose that 30em does, rather it remains effective in the scenarios where 30em gives a worse performance. So the consensus was supposed to decide whether 30em or 28em should be used as a standard basis for multiple columns. It is really upsetting that users deciding on the consensus do not even care to go through the original statements in detail. I would request them to go through it again, especially the one that I have made bold, so that they can comment on the methodical approach that I had taken. Please note that the point of 28em and 30em has not been discussed before. DiptanshuTalk17:39, 22 November 2013 (UTC)
Even the first choice on this template states: "Using {{Reflist|2}} will create a two-column reference list, and {{Reflist|3}} will create a three-column list, and so on. Choose the number of columns that is appropriate for the average width of the references on the page." If someone wishes to reach Project-wide consensus requiring that reflist|2 be deprecated, overturning its acceptance since I've been on the Project, the place to do it is at the MOS page. Not only has it been accepted, it has been required in GA reviews such as this one. It's the same as date formats -- we have more than one accepted practice. Because different formats look better to different users. If someone wants to deprecate one of the formats, there is a proper place and manner to do it (which is not to have the discussion among half a dozen editors on a non-MOS page). Until then, the same as with date formats where two are acceptable, it is silly to edit war and try to delete the long-standing format input in an article, which MOS accepts, because an editor prefers another. --Epeefleche (talk) 18:48, 22 November 2013 (UTC)
@Diptanshu.D:: Boldfacing your previous comments will not help to get your point across. Also please note that the column widths that work best for you in one specific article do not necessarily work best for me in the same article, and might not even be the best widths for you in a different article. As previously noted, I use 20em 25em or 30em (even 35em on one occasion) depending on circumstances; but I do try out each of these at different resolutions. --Redrose64 (talk) 20:32, 22 November 2013 (UTC)
@Epeefleche:: Earlier in the discussion you mentioned it is not clear that the 30 format is better on most pages. It is worse on mine -- forces one column. This is the original problem that I too had been facing. I assumed that other than the two of us, others too might be facing the same problem and was trying to solve the problem. I have no intentions of going into an edit war. A fight started brewing over my use of fixed column formats which was my initial and simple intervention to get columns using 30em code. When I understood that em system was better, I still searching for a better solution using the em code. Do you think that others too are facing such a problem? I would also request you to go for an experiment and share your results. Go to a random page using 30em but displays as one column on your screen > change it to 29em or 28em and see if it now renders as two columns at least. If it does, perhaps there is some justification in what I said. I would leave it upon others then to decide.
@Redrose64:: You mention having experimented with 20em 25em or 30em (even 35em on one occasion) depending on circumstances Can you please share your insights on this. Could you express your views on the differences between 29 and 30em. In my case 29em gives satisfactory results though 30em does not. Might be that the differences are subjective but I am not using any customised settings. DiptanshuTalk12:56, 23 November 2013 (UTC)
@Redrose64:: I did not say that you had tried 29em, I just asked for your opinion on how 29em could significantly worse and on what parameters. I have asked you this question since you have experimented on the subject and the exact match with your values might not be an issue. Furthermore, you could give us insights on the findings till now. It would be additionally beneficial if you could go a step further and make some sandbox experiments with 29em and let others know about your findings. DiptanshuTalk15:15, 23 November 2013 (UTC)
I don't see the point when no single specific width is better than any other. Each article has to be judged on its own merits. But you can judge approximately how wide a column will be using HTML code like this:
That line is 29em wide at the font size of a reflist, and is indented by the same amount as the text (not the numbers) of a reflist. --Redrose64 (talk) 15:46, 23 November 2013 (UTC)
30em wide
29em wide
28em wide
25em wide
That lines here vary between 30em and 25em at the font size of a reflist. You can well observe the difference of 1em that I am fighting for (since it 30em does not render properly on screen of certain users like me and Epeefleche but 29em does). Do you think that it would grossly affect the aesthetics of Wikipedia?
I think that it is generally accepted -- and if we looked for the history we could find it -- that over a certain number of refs (10?) it is a good think to have more than one column. The reason is that otherwise there is a good deal of white space to the right -- the result is that it takes more scrolls to get through the information.
Something as significant as forcing people to no longer use the forced two column approach -- which, as distinct from 30em, etc., results in two columns rather than one on my browser -- should probably only be an approach taken after an RFC. See wp:RFC. That's what we've done with dates, for example. It will impact too high a percentage of the articles at the Project for such a change from the existing approach to be made based on the views on this talkpage by half a dozen editors.
Also, as mentioned, the approach with dates, by analogy, where there are two acceptable formats is to avoid edit warring by retaining the existing format. See WP:DATERET. "The date format chosen by the first major contributor in the early stages of an article should continue to be used, unless there is reason to change it ..." The same approach is used by MOS with two agreeable spellings -- see here.--Epeefleche (talk) 17:04, 24 November 2013 (UTC)
What I mean is, multiple columns can harm readability when they’re too narrow. That, I think, is the whole idea behind using em constraints instead. With a minimum column width of 30 em, a page width of 59 em would be considered too narrow for multiple columns (and in my opinion, splitting at ~60 characters per line seems usually reasonable). So then the question is, should 59 em be considered too narrow in most cases? Or should it be wider? Or narrower? —Frungi (talk) 00:31, 25 November 2013 (UTC)
@Frungi:Use of {{refbegin|28em}} in 'Further reading' section of CD20 containing 19 references.Use of {{reflist|28em}} in 'References' section of CD20 containing 15 references. Sorry for being unable to reply directly to you last time. My professional engagements often limit my availability on Wikipedia for editing leaving me to limit rations for more important tasks only. Please find two screenshots attached. Along with other you, other users would also be able to decide if the screenshots look shabby on use of two columns where 30em renders only one column. In case you cannot visualise if one single column looks shabby, I can upload a screenshot for that too. According to (at least) metwo columns at this browser size is preferred. Epeefleche has already indicated his/her stand. Let others comment. DiptanshuTalk05:37, 25 November 2013 (UTC)
A lot of those references take up three, four, or five lines when displayed in two columns. Wasn’t the rationale behind using columns that it reduces horizontal whitespace? It looks like that’s not even close to a concern in your examples—there wouldn’t be any. So how do columns benefit the reader here? —Frungi (talk) 21:56, 25 November 2013 (UTC)
IMHO 30em works fine for mostly partially completed refs, lacking author, publisher(where work/journal/magazine is specified), or accessdate. For fully completed and/or archived refs, I'd like the flexibility to choose 40em for appearance's sake, to reduce the number of lines occupied per ref (to 2 or 3). If I really don't have that flexibility, I'd like the design element rationale to be unambiguously declared somewhere, and linked to in the docs for this template, to reduce argument. I've had my attempts at readability (40em) thwarted by 30em absolutists, and would like a little relief. --Lexein (talk) 14:10, 25 November 2013 (UTC)
I think there is more to splitting into multiple columns than the fact that it reduces horizontal whitespace. I think that ease of reading is an important factor where justification also plays an important role as compared to ragged right. Read this study and also the section 2.1 for Fitts's law.
I feel that text can be of two formats. 1) Smooth flowing page-wide long block of text conveying something in an essay type manner 2) Small blocks of texts describing some isolated points as in a list or bibliography where the text does not essentially flow into the next line. In case of the latter continuing over a long line may reduce the speed of reading or may make us lose track. If you look at the space-disparity created by the difference of length of ref.6 and ref.9 of Fitts's law#Notes, you would perhaps notice that the smoothness of reading is affected. Breaking into two columns makes both of them equal though the latter now spans over multiple lines. But following Fitts' law, it adds to the ease of reading by reducing the distance between point of starting of reading and the centre of the text block.
Articles like History of the Soviet Union (1927–53) use as high as 64em for reflist which means that for two columns to be rendered, the page width must be at least 128em; still higher for three or four columns which does not constitute majority at least. Similar is the case of 40em columns where at least 80em page width is required for minimum effectivity. Had the page used 30em, the area under curve would have been higher, even more if 28em had been used. I am suggesting just that (it varies on where you set the cut-off line as in case of an improper integral). DiptanshuTalk09:22, 26 November 2013 (UTC)
I'm afraid I don't see what either Fitts's law or that study have to do with reading in multiple columns. Anyway, I understand that you prefer long citations to be in multiple columns at relatively small browser sizes; I just don't see a consensus agreeing with this (but rather, a consensus against), and it seems to me highly subjective. Personally, I think the best solution would be a setting in Wikipedia's user preferences (that didn't require manually configuring CSS) to let each user set the preferred number/width of columns himself. —Frungi (talk) 17:11, 27 November 2013 (UTC)
IMHO I propose that the justification of multiple columns and the associated criteria be listed somewhere in the template documentation so that people do not have doubts. I am probably not the rightest person to be asked about the same. I have listed points as I have understood. I had interpreted that Fitts's law can relate to human eye movement over the screen; pardon me if I am wrong. But long back, somebody or a consensus on Wikipedia has already already thought it to be justified to use two columns and hence |2 code was introduced; later still em system was an improvement over it. Please do not ask me why these were done in the first place. I have my own justifications and I do not know whether I align with them. I thought other people think the same as evident in this source mentioning Consider using two columns per page with right-justification as this is easier to read. What I had understood is that if the output of a double column on a 1024px wide screen is not non-inferior, it can be accepted alongside the existing standards for higher resolutions. When I provided the screenshots, I thought I was able to prove that even on that screen-size the utility of multiple columns could be used for which a lowering of 1 or 2 em from existing 30em was required. Frungi mentioned the new pretext of white space. But before that please care to define the standard length of a reference (which I think is absurd and cannot be defined) as any length above or below it will give rise to some whitespace. I assume that the people reading the discussion have the intellect to understand that for a whitespace could be starting right from the beginning of a line or just before the end, leaving the mean at half-the-page; use of multiple columns naturally divides it proportionately, thus reducing it and not increasing it. So, I think that the logic mentioned by Frungi is invalid. While Frungi compared the results to be inferior to that on the higher resolution, that was simply not in the question; the question was whether it was inferior to that on the so-called lower resolution screen size(s). I am growing increasingly tired over this fight with absolutists and would drop on this topic soon. But before that I would once again request inclusion of the justification of the logic behind the existing use of multiple columns into the template documentation. DiptanshuTalk04:32, 28 November 2013 (UTC)
“New pretext of white space”? Epeefleche mentioned it a day before I did: “over a certain number of refs (10?) it is a good thing to have more than one column. The reason is that otherwise there is a good deal of white space to the right”—whitespace that could otherwise contain a second (or third, etc.) column. Whitespace that isn’t there if most references are long enough to span multiple full-width lines, so adding a column wouldn’t save much if any space, assuming that’s a primary concern. Anyway, I’m sorry if I came across as an absolutist; I never meant to imply that any arbitrary number of ems was superior to an equally arbitrary number. I only meant to suggest that perhaps there’s a reason (other than the admittedly pleasing nature of round numbers) that anything below 30em was apparently deemed too narrow for a typical ref list, and that perhaps a personal preference shouldn’t override that. Of course, that’s assuming the reason for the recommended 30em isn’t a personal preference itself. I have my own thoughts on the criteria for optimal min column sizes, but I’ll keep them to myself in hopes that someone behind the 30em recommendation will explain. —Frungi (talk) 06:47, 28 November 2013 (UTC)
@Frungi: Thanks for the politeness. And, by the use of term 'absolutists' I had pointed my finger also to the ones before and not merely you. Pardon me if I was wrong. May be I have mixed things up a bit. Using multiple columns is known to reduce the white space, but if I am not mistaken, you were the one to point out that there still are white spaces at the end of the references in the ref list in the images that I provided. I would humbly inform that there can be no length than can be defined as standard length of a reference and so some white space would always remain. I am glad that you acknowledged about the arbitrariness involved in the numbers in question, but the numbers that I provided are the ones that I got by a hit and trial method when I found that though 30 did not work in a given setup, 29 and lower ones did; amongst them I chose 28 randomly as it was even and not prime. I would be really glad if somebody justifies the use of 30 in the first place. I would also be glad if somebody takes the care to point out whether the columns in the images that I provided (please view in actual size) look too narrow to be used. If not, it can perhaps be deemed fit for use so that the benefits of multiple columns can be extended to them too through use of 29em or lower which would perhaps hardly bother the ones comfortable with use of 30em. DiptanshuTalk08:46, 28 November 2013 (UTC)
It's a fine summary of common usage, without any strong reccomendation. I would support adding some wording encouraging seeking consensus before changing XXem values in article {{reflist}} templates. It seems to me there's no consensus for 30em as a single standard - I oppose such a single standard. I would oppose adding any long rationale(s) to the template documentation, but would support putting the rationales presented here in an essay (or essays), linked in ==See also==. --Lexein (talk) 11:49, 28 November 2013 (UTC)
I agree to Lexein about the documentation. But I also request keeping in consideration that 30em does not serve the purpose of rendering multiple columns on a 1024px wide screen which demands a reduction by a mere 1px or more. If that is done, the vast majority of screens are covered. DiptanshuTalk13:11, 28 November 2013 (UTC)
The 'references' section using 20em for reflist tag and 'further reading' section using 30em for refbegin on CD20 preview mode on a 1024x600 screen using Google Chrome v31 default settings on Windows 7 netbook
On a second thought, I would still like to justify the use of 28 or 29em since I assume that the 59em width is for a 15" desktop. I have experiemented on a different and compliant setting where 30em renders 2 columns (on a 1024x600 screen using Google Chrome v.31 with visual drivers loaded netbook running Windows 7). This is what I found in the preview mode on the CD20 article where 30em rendered 2 columns which is exactly as expected, but 20em now renders 3 columns on the compliant screen. In the same setting 28 or 29em would have rendered 2 columns. I hope this helps. DiptanshuTalk13:54, 28 November 2013 (UTC)
I have always used 30em as its the one used in our tools like Reflinks. If there were any change in the norm we would have to change all the editing tools. -- Moxy (talk) 18:38, 28 November 2013 (UTC)
I’d just like to point out that the physical size of the screen (15″) means nothing; there is no difference between 1024x768 on a 12″ screen and 1024x768 on a 70″ TV (which I wouldn’t recommend). Also, I’m fairly certain the majority of displays are over 1024 pixels wide; W3Schools reports only 10% at that size and under, for instance, and about 20% (including mobile) according to W3Counter. And unless I missed it, I still haven’t seen an explanation why two skinny columns would be an objective benefit on displays that are already pretty narrow. —Frungi (talk) 19:04, 28 November 2013 (UTC)
I'm in agreement with RedRose64 as as above, and with the stepwise approach to selecting em width.
25, 28, 29 as an offered option? I don't see consensus here going that way at all. But I think that local consensus at particular article(s) could go that way. Until that happens, I don't think 29 belongs in the docs here until the essay is written, and consensus is seen at several articles.
IMHO, don't worry about "norms". There are at least four commonly used ref column widths, per the docs, plus editor's choice. We know full well that no matter what -em size is selected (or |2 or |3 for that matter), browsers, fonts, and zoom levels will conspire to produce odd-looking (ugly, even) layout in some cases.
Reflinks and the like aren't intended to mandate reference column width; it's a suggestion based on broad and rough consensus for XXem and not going against the editor's-choice option listed in the documentation here. 30em might not be best everywhere (very short refs, or very long refs, as I've mentioned #above), but some variant (20em, even 40em) might very well be "best" per local consensus, and as seen in Redrose64's rationale.
If any changes are to be made to the docs for now, I propose putting XXem column-width first, and fixed-columns |2 and |3 last, as deprecated, since Wikipedia itself is highly adaptable to display parameters, so ref lists should be too. (I get that this might need a somewhat wider RFC). --Lexein (talk) 21:46, 28 November 2013 (UTC)
I am happy that the topic has finally received constructive criticism, courtesy Lexein, Redrose64, Frungi and few others, in contrast to the initial parts of the discussion. I think whatever you people come up with as solutions to the problems that I pointed out, would be acceptable. DiptanshuTalk08:24, 29 November 2013 (UTC)
The numbers I documented are practices, i.e. the numbers that seem to work for a majority of editors. The appearance is dependent on the screen resolution and browser width. The references render at different columns depending on whether I view it on my 20" monitor (16w x 12h) at 1280x1024 or 24" (20.5w x 11.5h) 1920x1080. This issue has come up time and again, and these numbers consistently work for the majority of readers. Tweaking to try to work for a particular reader is not a good practice. There may be some personal CSS you could use to adjust columns. --Gadget850talk15:56, 1 December 2013 (UTC)
I'm also against optimizing for reader/browser/screen. But are you opposed to adjustments like RedRose64's and mine, which are based solely on width of rendered refs (short, medium, long, very long)? IMHO that's the only reason to adjust em width, but it is a quite good one. --Lexein (talk) 17:41, 1 December 2013 (UTC)
Just a note to add. I have enabled the new beta feature Typography refresh and that seems to take care of the entire situation. Even on the relatively smaller screens of 1024px width that I had mentioned, 30em now renders two columns. So some simple change in the css could have taken care of the entire situation that I had been discussing. And yet, the discussion kept dragging this long. DiptanshuTalk13:23, 13 December 2013 (UTC)
