Template talk:Reflist/Archive 8

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 5 Archive 6 Archive 7 Archive 8 Archive 9 Archive 10 → Archive 15

Discussion of template goals, changes

My apologies for yet another section, but this discussion looks like it still could use some organization. Perhaps we can take a step back (sorry, it's in the name of progress!), think about the big picture, and separate this into distinct, sequential questions:

  1. Would features like small text and multiple columns be beneficial for some articles?
  2. If it would be beneficial, can the template be improved to support these features bug-free?
  3. If it can't be bug-free in the short-term, which is better: buggy multi-column, or bug-free single-column?

It seems to me that everyone jumped past #1 and started debating #3; these items are subtly different. My initiation here doesn't necessarily preclude discussion of the proposal above, but I hope to establish long-term consensus and action here. So—one point at a time—let's start with #1.

Question 1: Concept

Do you support or oppose the concept of multiple columns and/or small text (regardless of the current implementation and its flaws)?

Discussions about the specific number of columns or specific size of text are appropriate.

— Nightspark (talk) 11:02, 15 August 2008 (UTC)

  • Support The small text IMO looks better and makes references easier to read. Over 500,000 articles use the small font size, which to me indicates that I am not alone in this preference. I also find 2 or 3 columns easier to read, even in my typical 800x600 browser window. The vast majority of pages use 2 or fewer columns, and extremely few use more than 3. Further, both features can easily be implemented so that simple CSS gadgets can disable either or both for those users who despise them. Anomie⚔ 13:04, 15 August 2008 (UTC)
  • Oppose TBH, I strongly dislike the use of specific text sizes and multiple columns. I dislike smaller text sizes, as it's harder to see them, especailly for those with sight difficulty. I also dislike multiple column references. In an article, people tend to read down the page, left to right. With the multiple column references, you're having to scroll up and down the page to read them, and it could also be marginally difficult to find a particular ref, especially if an article has 200 refs, whereas in single-column format you read straight down and there would be no problem in finding it. In my view, multiple column references just look plain ugly, with single column references a lot more professional and easier to view. D.M.N. (talk) 13:26, 15 August 2008 (UTC)
    Note that the smaller font size currently used is not a "specific text size"; it's specified as "90% of the size of the normal text". In other words, if your normal text is 10pt the small text should be 9pt, while if your normal text is 16pt the small text should be 14.4pt. I don't know if this makes a difference to you or not. Also, FWIW, I usually find a reference by clicking on the superscripted number in the text, which takes me directly to the correct reference and highlights it. If I need to find a reference without using the indicator, I normally use my browser's search function (Ctrl-F) to locate it. The only times I've ever actually gone through all the references in an article sequentially all involved checking for websites likely to fail WP:RS. Anomie⚔ 16:46, 15 August 2008 (UTC)
    Interesting external links (interviews, reports, etc) are generally found within the references section in a high-quality article. Many people (such as myself) read through the references section looking for them. -- Quiddity 17:06, 15 August 2008 (UTC)
  • Support. The difference this makes on large-resolution / widescreen monitors is considerable, both in terms of readability (less scrolling) and presentation (far less dead air on pages). There's nothing wrong with the font size being smaller - footnotes are smaller in dead-tree publications too - because the material is only of supporting value, and is included on the page out of necessity rather than because it makes for good reading. Chris Cunningham (not at work) - talk 13:51, 15 August 2008 (UTC)
  • Support per Chris and Anomie.--Peter Andersen (talk) 15:42, 15 August 2008 (UTC)
  • It's not that simple:
    • Columns: Stereolab#Notes shows a good usage of two columns (as I pointed out back in May). But putting full-length-citations into multiple columns is almost always bad for many people's ease of reading – Hurricane Vince (2005)#References is quite easy to read, but Greater Crested Tern#Footnotes is much harder to read. (for people like me, with bad old eyes and/or bad old monitors.)
    • Size: Having ever-so-slightly-smaller text for full-length-citations can be beneficial (visual separation of content, cheaper printing); see Stereolab#References for a close-to-optimal example. It is the inconsistencies between browsers/platforms/typefaces (not to mention users) that make it complicated – what is legible to one editor is often illegible to another (that is: a slight benefit for one person, can be a big problem for the other person).
    • When small sizes are coupled with multiple columns, that exacerbates the problem of legibility. -- Quiddity 16:57, 15 August 2008 (UTC)
  • Support, with concessions for usability. Somewhere in the MoS it can be urged that two columns should not be used when the citations are long (and especially not for long unformatted URLs), but they can be encouraged for things like Harvard referencing of the sort used in Stereolab#Notes. I have yet to hear of a case where three or more columns is needed. I'm also wary of the use of "colwidth" unless testing shows it to work well for a variety of fonts/skins/screen sizes (and then, we should probably standardize on a single colwidth based on the testing, perhaps 30em). If colwidth can be shown to work better in general than a fixed number of columns, perhaps {{reflist|2}} should be deprecated in favor of {{reflist|multicol}}.
    Apparently some CSS tweaking is needed to make the reduced font size work on IE, but that should not be a problem; I'm also open to boosting the size to 92% or even 95%.--Father Goose (talk) 22:35, 15 August 2008 (UTC)
Stereolab actually uses shortened footnotes, not Harvard; I had the same misconception since I'm not real familiar with the use. I have a second round of proposals that includes adding a switch for shortened footnotes (type=short). Learned Hand and Saint-Sylvestre coup d'état also use shortened footnotes; Irish phonology uses Harvard. I'm digging through the common.css talk to figure out why ol.references is needed and why it is set to font-size: 100%. --—— Gadget850 (Ed) talk - 01:20, 16 August 2008 (UTC)
I suspect it may have something to do with how back in May 2006 someone originally set ol.references to 90% when the original discussion of a smaller font size occurred, and then it was apparently "reverted" by setting it to 100% instead of removing it outright. Also, I would personally not like 30em columns, as in my browser it results in only one column ;) 25em is the maximum that works for me, but of course that may not "work" for others. Anomie⚔ 02:08, 16 August 2008 (UTC)
  • Qualified Oppose: I oppose multi-columns on the whole, but maybe I'm missing the boat. I came to this talk page specifically to inquire: What exactly is the point of multi-column? 98% of references on 98% of the pages I've ever worked on are at minimum half a screen wide. Most are at least a screen wide, if not word wrapping onto two lines. Multi-call simply serves to split these references into 2... 4... or more lines which saves no vertical space (4 one-line references into 2 x 2 two-line references), and makes the references harder to read. The buffer between columns actually eats a bit of the space that a one-column would otherwise have as well. I'm not sure what the point is. I DO think there needs to be a solution to articles with copious reference lists (which is what wikipedia strives for, but it makes for an ugly article). I was strongly in favour of a vertical scroll box of 5 or so lines height which allowed inline citation to link (the scrollbox worked properly to scroll to the linked reference. However, it was pointed out that the scrollbox failed to accomodate printing of articles. I understand that rationale, but was disappointed that such a good space-saving solution couldn't be implimented. That said, I see no space-saving from multi-column reflists. TheHYPO (talk) 09:13, 23 August 2008 (UTC)
    There is certainly a space saving for articles that use WP:CITESHORT#short form references. There also may be a savings if two references that take two lines in 1 column only take three (instead of four) lines in 2 columns. For example, on my computer United States's references take about 11 fewer lines if I change it to 2 columns instead of 1, but only one reference (#47) is less than half a screen wide. Then there is also the matter where many prefer the appearance of two columns, just as some absolutely despise it, which has little to do with space saving per se. Regarding a scrollbox for the references, personally I find them ugly, unintuitive, and difficult to read for that purpose (besides the issues with printing). Anomie⚔ 13:56, 23 August 2008 (UTC)
    I found that the references in Seymour Reit took up less space in two columns, even though some are short and some are long. In general, though, I would ditch the use of more than two columns.--Father Goose (talk) 20:01, 23 August 2008 (UTC)
    That is why I suggested that the references section (that which is addressed by this template, whatever it is called) go to the very end of the article, after even nav boxen, then the length doesn't matter unless you are actually reading the references section. And most people jump to that from the article I believe. Rich Farmbrough, 21:33 2 September 2008 (GMT).
  • Oppose Small text. If it's "perfectly readable" put the whole of WP in it and get more on the screen. There is no point "saving space" to et more refs on a screen if it causes difficulty reading them. Saying users can set their CSS requires them to be registered users with some technical savvy. I repeat, 90% text gives me problems and I have good corrected vision.
  • Mild oppose Columns. These juts cry out for a smarter solution than coercion into a fixed number of columns. But htere are certainly cases where for most users 2 columns would be OK, possibly preferable to one. Rich Farmbrough, 21:28 2 September 2008 (GMT).
  • Strong support for two columns in terms of readability, saving white space and consistent look-and-feel. It does work on paper, as well! ;)
Fractional reduction in text size can help reinforce a visual format break, as noted above, and although I personally do prefer this it is perhaps(?) secondary to the benefits derived from simply having two columns if this were carried out on a consistent basis across articles in order to help train the eye/brain for all reflists. (Also, personally, I'd be /more/ than happy if reflist /defaulted/ to two columns across the whole of WP, if this could be rendered without technical issues, in order to produce a standard, authoritative, look-and-feel rather than having the current mishmash and pointless discussions, even, over how many references are "needed" in order to "justify" use of two columns vs. one when personal preferences can end up jumping all over anything resembling a consistent "manual of style" across all articles).
As for how much white space there is between columns, I presume readability tests could be carried out across the various screen resolutions/text sizes at which WP is typically used (the tech gurus no doubt have that all on-hand in order to number-crunch?).
Three columns is, given current presumed screen resolutions, possibly a step too far technically as well as being a bit more difficult to train the eye/brain to accept as "normal" and certainly yields diminishing returns in terms of visual format break and reduction in vertical real estate being taken up by the refs. The overarching goal of WP does however, I feel, need /not/ to come into conflict with factors discouraging extensive referencing and there is a point at which "single column only" is inevitably a liability in that regard for references; which are, after all, of no small importance even if they're not actually read by more than a small percentage of viewers. (Probably not helped by 99.9%+ of WP users having landscape-format monitors, I know... whoever came up with /that/ design? ;)
JM-02c, anyhow... Kind regards & Best wishes, David. Harami2000 (talk) 09:32, 3 September 2008 (UTC)

Sort

Had a look at the archives since this must have been a request made in the past. Unable to find any but I am sure there must be a load of objections for not implementing alpha - chronological sorting of the references. Shyamal (talk) 08:15, 10 September 2008 (UTC)

I don't see how reflist or any other template can sort the references, nor do I see any reason to sort them. References are displayed through the Cite.php extension. --—— Gadget850 (Ed) talk - 10:58, 10 September 2008 (UTC)
Interwiki links and categories seem to be sorted by some template(?). Almost any traditional publication lists references in alpha chronological order (author names and ties broken by latest publication first see Wikipedia:Citing_sources#Parenthetical_referencing) - it helps when people are searching the reference list by the author name. Shyamal (talk) 15:25, 10 September 2008 (UTC)
Neither are sorted, and if they were it would be by the MediaWiki software and not by a template on the page. Anomie⚔ 17:40, 10 September 2008 (UTC)
Alpha-chronological order is used for bibliographies, not for footnotes. Category members are already sorted alphabetically, the {{DEFAULTSORT}} template only modifies how it is sorted (i.e. last name first). —Elipongo (Talk contribs) 17:47, 10 September 2008 (UTC)
(edit conflict)Categories are sorted directly by the MediaWiki software. When parenthetical referencing is used, there is a list of notes generated by Cite.php, and a list of references that are manually placed. I'm sure you could come up with a template that would enclose the references in a sortable table, but you would probably need a separate sortkey for each entry; entries might use citation tmeplates or not, and template entries may have the fields in different orders. Regardless, that is beyond the scope of reflist. --—— Gadget850 (Ed) talk - 17:51, 10 September 2008 (UTC)
I suppose that brings up a question: was Shyamal talking about the category list at the bottom of an article (as I thought) or about the list of pages in a category (as you two seem to have thought)? The former are displayed in whatever order they are specified in the wikitext, while the latter are (of course) sorted. Anomie⚔ 23:02, 10 September 2008 (UTC)
There seems to be a greater use of reflist for reference citation rather than for foot notes (annotations with editorial comments) and Template:Harvnb does not seem to be anywhere as preferred as using reflist - although that allows control on the ordering of citations. Allowing sorting of the references (whether in the scope of reflist or elsewhere) would make the scheme of referencing better. It can be given as an option so that those using footnotes in the true style of editorial annotations (although there is a tendency to look at that as WP:OR) can keep them in the natural order of occurrence while those using it for reference citation can get the reference list in order. (Yes I was talking about the defaultsort template..) Shyamal (talk) 01:44, 11 September 2008 (UTC)
I may be missing something, but {{reflist}} doesn't have anything to do with {{defaultsort}} (i.e. categories), does it?
The right way to "sort" footnotes before citations is to use two different <references /> blocks. One as {{reflist|group=n}} (for notes) and one without the group="n" for the regular citations. Naturally, the <ref ...> tags for the notes need group="n" too. Example: here or here.
This is of course a "fixed" order. And there is no other practical way to do it because A) a template cannot differentiate between a footnote and a citation, and B) the generated list is an <ol> block, so sorting it with javascript (which is--I suspect--the only way to do it) will cause the individual lines to be re-numbered according to the new order; the first line in the list will always appear as "1.", the second as "2." and so on.
-- Fullstop (talk) 03:03, 11 September 2008 (UTC)
Need to rephrase my suggestion - and this is with full ignorance of the internal implementation and where this should go - See for instance http://www.informatics.sussex.ac.uk/department/docs/punctuation/node50.html (especially the last bit). So regardless of how it can or cannot be implemented, I was hoping that some modification may make it possible to have something like {{reflist|sort}} which would sort items alphabetically and if the items use the {{ cite journal }} template that it might be possible to sort by author / last and then by year. (All other things I mentioned earlier about categories are in error and extraneous to the wish) Shyamal (talk) 05:02, 11 September 2008 (UTC)
I think you're maybe talking about Harvard Referencing, (a system that I happen to find highly annoying), and instructions for doing it are at WP:HARV. Yilloslime (t) 05:16, 11 September 2008 (UTC)
Thanks. Yes, exactly as indicated above Harvard referencing allows the references to be listed in order but the inline citations are longer - with author surname and year - and yes, the implementation of the templates for the Harvard citation are responsible for its difficulty of use - unlike the far more usable footnoted ref tags (with cite templates) and reflist combination ! Shyamal (talk) 06:25, 11 September 2008 (UTC)
Never mind, I guess this is a mediawiki development issue. Shyamal (talk) 07:07, 11 September 2008 (UTC)

False link

In the section see also, behind {{Ref indent-end}} leads to the disamb. page Indentation rather than Indent style. I would have edited the link but it is protected and I'm not empowered the status. --Scriberius (talk) 03:22, 14 September 2008 (UTC)

I don't see any link to a dab page. The documentation section is not protected. --—— Gadget850 (Ed) talk - 11:32, 14 September 2008 (UTC)
Indentation is not a dab page, it describes "Indentation in typesetting" or "hanging indents". As opposed to Indent style (linked from "Indentation" in summary style) which is about indenting programming code. -- Quiddity (talk) 17:48, 14 September 2008 (UTC)
Indentation seems to be the better target for that link, as the link is for describing a hanging indent and not for talking about indenting programming code. Anomie⚔ 19:02, 14 September 2008 (UTC)

Q regarding refgroups

Hi.. I'm not able to ascertain from the text; is it possible to use both refgroups and named refs in a single article? e.g. <ref name="foo"><ref group=bar>blah blah blah</ref>? Prince of Canada t | c 03:09, 22 September 2008 (UTC)

You can even use names and groups in a single reference if you want: <ref name="foo" group="bar">...</ref>. Note that if you want to do nested references, you'll have to use the #tag magic word to have it come out right, e.g. {{#tag:ref|This is a footnote, with a citation.<ref>{{cite whatever}}</ref>|group=n}}. This is discussed in more detail at WP:FOOT, at least for the moment. Anomie⚔ 03:23, 22 September 2008 (UTC)
You know, if you would just provide answers to questions quickly, completely, and clearly, you would be unstoppable! ;) Thank you very, very much for the help. Prince of Canada t | c 03:25, 22 September 2008 (UTC)
Sorry, one more question: if I wish to create a 'References' section and a 'Notes' section, do I need two refgroups, or just one refgroup defined as 'Notes', with anything not specified as going in 'Notes' defaulting to {{reflist}}? Prince of Canada t | c 03:31, 22 September 2008 (UTC)
Well if I had just read the link you provided, I would have had my answer! You're sneaky.. (thank you very much) Prince of Canada t | c 03:59, 22 September 2008 (UTC)

Mini-scrollable reference section

I've noticed, and myself started propagating, the application of the following code to reference sections (e.g. 2008 baby milk scandal‎): 

<div style="height: 270px; overflow: auto; padding: 3px; border:1px solid #AAAAAA; reflist4" >
{{reflist|2}}
</div>

Shouldn't this become a template of its own? Template:Long-reflist or something? __meco (talk) 09:08, 26 September 2008 (UTC)

Ooooh. I like that. A lot. Prince of Canada t | c 09:15, 26 September 2008 (UTC)

No. Wikipedia:Templates for deletion/Log/2007 June 11#Template:Scrollref --NE2 09:32, 26 September 2008 (UTC)

And a most tenuous consensus indeed. could we have the source code of the deleted template posted, admin someone? __meco (talk) 09:46, 26 September 2008 (UTC)

I wrote it, or did a fair chunk of it. It was, at its core, little different from the suggestion above. We'd expanded it to the point where it passed the number of columns to reflist, and hoped to see it replace reflist entirely, if we'd have gotten it to the point where it didn't bother scrolling until you hit say ~50 refs. See Template:Scrollbox for more information on how this stuff works.

Unfortunately, as was said in the AfD, this breaks the printable layout. The vast majority of the comments in the TfD were either stylistic in nature and would be sated with an option to turn it off or, much more substantially, claiming that the template broke the printable layout and may or may not have caused issues for disabled readers that utilize screen-reading applications. If this code is creeping back into the wiki it should be removed immediately. That said, though, it would be cool to bring it up in deletion review if changes to the mediawiki.css and the printable css file are made that allow for more flexibility. Articles like Causes of the Civil War and United States still have enough refs to sink an oil tanker and would benefit quite a bit from scrollref's revival. Again, this depends more on our CSS skins than it does anything else. MrZaiustalk 10:00, 26 September 2008 (UTC)

The relevant guideline is Wikipedia:Citing sources#Scrolling lists. Before discussing the implementation of scrolling, collapsing or hidden references, the issues should be discussed on that talk page. --—— Gadget850 (Ed) talk - 10:02, 26 September 2008 (UTC)
Actually, now that I think about it, a bug report concerning the default Mediawiki CSS files might be a more substantive and useful first step. Surely there are other wikis that it'd be nice to use scrolling div tags on. Can't accomplish much in the way of CSS changes from a talk page about citations - The problem runs far deeper than that. MrZaiustalk 10:06, 26 September 2008 (UTC)

CSS classes for multiple columns

I suggest adding CSS classes to the reflist div when multiple columns are specified. Specifically, add references-column-count and references-column-count-N when a column count of more than 1 is specified, and references-column-width when colwidth is specified. This will allow people to easily override the column-count or column-width specifications in their user CSS, for example if 30em is too wide for some people, or if certain Safari users don't mind the bug, or if certain people want to disable multiple columns completely.

This edit would do that. If there are no objections, I will {{editprotected}} this on October 19 (if no passing admin does it earlier), or sooner if WP:SNOW applies. Anomie⚔ 19:01, 12 October 2008 (UTC)

{{editprotected}}
There have been no comments for a week. Please make this edit. Anomie⚔ 16:11, 19 October 2008 (UTC)
Done. I remember being slightly disappointed, as one of those Safari users, when columns were disabled: this option is surely useful for those who prefer ever-so-slightly-buggy multiple columns to a large single column. It's unfortunate that I didn't yet monitor this talk page, else I would have surely made this change earlier. {{Nihiltres|talk|log}} 01:30, 20 October 2008 (UTC)
So if I'm a disgruntled Safari user who wants my multiple columns, what do i do to implement them in my CSS? Der Wohltemperierte Fuchs (talk) 01:44, 20 October 2008 (UTC)
This should give you 2, 3, or 30em columns in Safari depending on what the article specifies:
.references-column-count {
    /* Default, if multi-columns are specified and the specific number isn't handled below */
    -webkit-column-count:3;
}
.references-column-count-2 {
    -webkit-column-count:2;
}
.references-column-width {
    -webkit-column-width:30em;
}
(Hopefully I got that right!). For those who hate multiple columns, this should force a single column in all cases:
.references-column-count, .references-column-width {
    column-count:1 !important;
    column-width:auto !important;
    -moz-column-count:1 !important;
    -moz-column-width:auto !important;
    /* Useless for now, but include them anyway for when Safari gets fixed */
    -webkit-column-count:1 !important;
    -webkit-column-width:auto !important;
}
If someone really wanted to, gadgets could be made out of either of those. Also if someone really wanted to, they could get appropriate styles for those classes added to MediaWiki:Common.css and then remove the inline CSS from this template; it would lose the ability for individual articles to specify a non-default colwidth and lose the ability for more than X columns (for whatever value of X is chosen) though. Anomie⚔ 03:11, 20 October 2008 (UTC)
Thanks for the code, but in terms of this stuff I'm kind of a newb. Where do I go to make these changes? Der Wohltemperierte Fuchs (talk) 12:01, 20 October 2008 (UTC)
Nvm, I figured it out. :) Der Wohltemperierte Fuchs (talk) 12:03, 20 October 2008 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Reflist/Archive_8&oldid=1091981677"