Jump to content

Template talk:Reflist/Archive 17

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 10←Archive 15Archive 16Archive 17Archive 18Archive 19Archive 20

Add parameter standardisation aliases

Proposal: expand {{reflist}} so that {{reflist|narrowcolumns}} and {{reflist|standardcolumns}} define column widths in words people can understand, with the advantage that we're not hardcoding a specific width meaning, as we are with eg "30em". That would be easier to understand, better for standardisation, and helpful for any future changes. It doesn't conflict with existing uses, and doesn't require anybody to do anything. In terms of values, I'd suggest that narrowcolumns be initially set as an alias of colwidth=20em (can be debated and/or changed later) and standardcolumns as 40em (ditto). As to why specifying maximum minimum column width (which is what colwidth does) is better than specifying a fixed number of columns (which is what eg reflist|2 does): with appropriate values it works better for a wider of screen sizes, whilst being much the same on standard screens. Rd232 talk 00:39, 20 December 2010 (UTC)

I think that it is much better to put arbitrarily-chosen numbers like "20em" and "30em" inside the template. The whole point of the template is to be able to keep these things standardized rather than having to edit every article when we make a style change. So I agree with the proposal. — Carl (CBM · talk) 00:47, 20 December 2010 (UTC)
I Oppose. We tried this with "2" meaning "30em" and editors were not pleased. I expect the same may be true for these parameters. They can mislead people to believe that "narrowcolumns" is ment for small screens, resulting in a single long reference being splattered over 10+ lines, unless we educate editors really well. Also, this is the single most used template on wikipedia, and it needs as little bloat as possible; every parameter needing evaluation adds to the job queue with each article edited. Having to poll for these parameters wil at least double the codebase of this template, and I just finished making it loose considerable weight. (PS. I corrected a misunderstanding.) — Edokter • Talk — 01:05, 20 December 2010 (UTC)
between appropriate parameter naming, documentation, and experience, I don't think we need to overly worry about greater misuse of these than any other parameters. Rd232 talk 01:18, 20 December 2010 (UTC)
I think that changing established articles to use the parameters is a separate issue from having them: established articles should generally be left alone anyway. Is there a significant benefit to having simpler code for this template? — Carl (CBM · talk) 01:12, 20 December 2010 (UTC)
(edit conflict) {{Reflist|2}} to {{Reflist|30em}} failed because {{Reflist|30em}} does not suit every article. A lot of people use two colums on articles with 10 refs or fewer. In those cases, four or more columns (as produced by {{Reflist|30em}} on large screens) oftentimes destroy the references, splitting them over two or more columns and stuff like that. —bender235 (talk) 01:14, 20 December 2010 (UTC)
@Rd232: I actually support your proposal, but the definition of {{Reflist|standard}} and {{Reflist|narrow}} (I suggest these short variants, btw) leads us back to the question what the "standard" width should be. I'd prefer 20em for narrow and 30em for standard, but I don't know whether that is consensus. —bender235 (talk) 01:14, 20 December 2010 (UTC)
Well the advantage is that can always be changed. The shorter form you suggest is unfortunately probably too ambiguous;as per my reply to Edokter above, the naming matters to avoid ambiguity. Rd232 talk 01:18, 20 December 2010 (UTC)
No, changing it later won't work. Assume we'd have 20em for narrowcolumns now, that would fit those references here perfectly, and someone might have implemented it just because it did fit that good. But if we later change that to say 30em, those references don't look good anymore. Which means we need to have some sort of consitency here, and that means we should discuss the ideal values for narrowcolumns and standardcolumns first. —bender235 (talk) 01:29, 20 December 2010 (UTC)
I believe I made a similar proposal some time back: standard for a regular reference list and shortened for a shortened reference list. Chaco Culture National Historical Park#Citations uses {{reflist|colwidth=20em}} for a shortened reference list, which neatly shows four columns. However, 1965 South Vietnamese coup#Notes uses a mix, so it only looks good with two columns. Perhaps we should ask for column support to be directly added to the Cite extension, but I am not enough of a programmer to know the feasibility. ---— Gadget850 (Ed) talk 03:03, 20 December 2010 (UTC)

Other proposal: go user preferences

How about having user choice added to the user preferences, either width, or column amount, like the thumbnail size is user customizable? Issue I see with this are that it will require some work behind the scenes and that, I believe, there is no way to detect how many references there are so articles with just a couple of references will look silly, but I guess a parameter to overrule the user setting can still be in place for these cases, much like you can still define the thumbnail size and overrule the user settings. Xeworlebi (talk) 12:41, 21 December 2010 (UTC)

Larger font

Where was this change agreed to? It's a fairly major change that affects most articles (and an unpleasant one, at that). All Hallow's Wraith (talk) 13:58, 21 December 2010 (UTC)

It seems it was decided on Wikipedia:Village pump (proposals). Another major template change that was not sufficiently documented and discussed, if you ask me. E.g. has there been any notice on this talk page? Apart from that, the proposal and consensus over there was to adjust <references/> to the small font size of {{Reflist}}, not the other way round! De728631 (talk) 14:24, 21 December 2010 (UTC)
Bypass your cache. Otherwise it can take up to 30 days for your browser to get the newest version of MediaWiki:Common.css with the new style rules. Anomie⚔ 14:26, 21 December 2010 (UTC)
(ECx2) See Wikipedia:Village pump (proposals)#styling <references /> like Reflist. That proposal resulted in all references use the same font-size as {{reflist}}. If you see a bigger font-size, bypass your cache, as Common.css needs to catch up to this change. Also, this has been discussed twice on proposals, the last one being an RFC and linked to from the Central Discussion box; both times with resulting in overwhelming support. — Edokter • Talk — 14:29, 21 December 2010 (UTC)
Ah, alright. Thanks for the info. De728631 (talk) 14:44, 21 December 2010 (UTC)
So that means that all articles will now have the smaller font? Excellent! Talk about bad news turning to good. All Hallow's Wraith (talk) 15:06, 21 December 2010 (UTC)
Seconded. I was quite unhappy for a minute there.  ⊂| Mr.choppers |⊃  (talk) 17:22, 21 December 2010 (UTC)
Is it just me or did the edit have the result that {{Reflist|colwidth=30em}} no-longer function with all 3 columns? Not sure how many people use browsers with this capability but think this should be addressed.Moxy (talk) 17:51, 21 December 2010 (UTC)
That works fine over at WikiLeaks for me using Firefox 3.6.13 SmartSE (talk) 17:55, 21 December 2010 (UTC)
Whether {{Reflist|colwidth=30em}} produces three columns, more, or less, depends on your screen size. —bender235 (talk) 18:39, 21 December 2010 (UTC)
I am looking at Canada, Canadians and History of Canada etc.... were it seems to be forcing 2 columns (no matter what size my browser is its still 2 columns). This would be the opposite of what this coding should do. I am wondering if the people that voted on implementation of this were aware of the outcome it would have on this coding - for those of us that use other browser besides IE (this option is the main reason i stop using IE).Moxy (talk) 18:02, 21 December 2010 (UTC)
(←) Columns should not be affected by this change. It may trigger less columns due to the fontsize from common.css not getting through yet, in which case, do what Bender235 says below and bypass your cache. — Edokter • Talk — 18:43, 21 December 2010 (UTC)
If, like me, you've come here wondering why references suddenly got bigger, follow the instructions here to bypass your browser's cache and get them back to normal. SmartSE (talk) 17:53, 21 December 2010 (UTC)
The references are still larger for me, even after clearing my browser cache. Could this please be changed back? What is the benefit of this anyway? It is a lot harder to read than before. Could someone please revert this change? Toshio Yamaguchi (talk) 18:58, 21 December 2010 (UTC)
Have a little patience please... Others have no problems. We're not going to revert for a minor issue. Just try clearing your cache again. — Edokter • Talk — 19:05, 21 December 2010 (UTC)
Ok cleared my browser cache again and this time it worked. I hope it will stay small. Toshio Yamaguchi (talk) 19:19, 21 December 2010 (UTC)
There should be no need to clear your cache. Changes to template should wait until the caching has expired. —TheDJ (talk • contribs) 19:30, 21 December 2010 (UTC)
Retaining references-small runs the risk of double styling, resulting in too small a font-size (many have it in their personal CSS). Better too big then too small, so I don't quite approve of retaining that class in the template. — Edokter • Talk — 20:06, 21 December 2010 (UTC)

Small font

This has been a bugbear for years. Finally it was disposed of and now it's back? It's a real black eye for accessibility. WP is not paper. Rich Farmbrough, 01:18, 22 December 2010 (UTC).

Highlighting

After the recent changes, I noticed that (in Firefox) clicking on a reference number in the text no longer makes the long-form reference in the reflist get highlighted when you're taken down there, as it used to. I'm not sure if the difference is due to a change in the CSS or a change in this template (although as far as I can tell the only thing that's been changed in the template is which CSS it points to). It was a nice feature, though, and I didn't notice anything in the VPP discussion about people wanting it removed. rʨanaɢ (talk) 00:39, 23 December 201:

Highlighting is not a feature of this template. You are correct in that highlighting is broken. See MediaWiki talk:Common.css. ---— Gadget850 (Ed) talk 00:56, 23 December 2010 (UTC)
Fixed in Common.css. — Edokter • Talk — 01:09, 23 December 2010 (UTC)

Recent changes affecting layout

The recent changes seem to have introduced a line break in some of the articles (see List_of_snooker_player_nicknames#References). It looks bad, any chance of sorting it out? Betty Logan (talk) 13:27, 24 December 2010 (UTC)

That is not because of recent changes. Its because that article uses bare URLs, which it shouldn't. —bender235 (talk) 14:26, 24 December 2010 (UTC)
That's not true at all, those are all fully fledged references with authors, titles, publisher, dates etc—in fact they are comprehensive references that all conform to Wikipedia referencing policy. The layout changed when the reference code was revised and it needs to be addressed. Betty Logan (talk) 14:46, 24 December 2010 (UTC)
Fixed it at the article, didn't have anything to do with this template, don't put EOL's in references. But I have to agree with Bender235, these refs are, while extensively info'd not really well formatted, these have bare URL's, a bare URL has nothing to do with having info it's the difference between http://wiki.riteme.site/wiki/Main_Page (bare) and Wikipedia, the free encyclopedia (not bare). Try using one of the cite templates like {{Cite web}} or {{Cite news}}. Xeworlebi (talk) 17:00, 24 December 2010 (UTC)
Wikipedia is the encyclopedia anyone can edit using any consistent style they desire. The extra newlines were the problem. ---— Gadget850 (Ed) talk 17:04, 24 December 2010 (UTC)
No, you're wrong. If someone decides to consistently color all titles pink, they can't, because it violates Wikipedia style guides. Same goes with bare URLs. One should not use them. —bender235 (talk) 20:02, 24 December 2010 (UTC)
Thanks for sorting it out, but the problem certainly occurred after the template edits because that page was fine beforehand. Also, you are misunderstanding what constitutes a "bare link". A bare link is simply a url without any accompanying reference information which isn't the case here. These references are full references that just explictly give the url (this is not discourage by any Wikipedia policy I know of). That article uses the Harvard reference format, which explicitly provide the url as part of the reference so the reference information is retained if transferred to a hardcopy. While I agree that the citation templates are a terrific idea to encourage editors to add complete reference information, they are still a distant second best to internationally recognized reference standards, which should really be preferred to an "in house" standard. Betty Logan (talk) 17:30, 24 December 2010 (UTC)
The only extra break that I saw was in reference 1. I just copied the whole article to the Spanish Wikipedia which does not have the recent changes and it had the same effect. ---— Gadget850 (Ed) talk 18:08, 24 December 2010 (UTC)
I've tested the old template in the sandbox and the same problem is occurring, so you are right it is not this template. I've edited the article on and off throughout the year, so I would have noticed it at some point, since it caught my eye straightaway today. The article hasn't changed since the start of the month either (and I've tried it in two browsers) so it must be one of the templates this template utilises that caused the problem. Betty Logan (talk) 18:30, 24 December 2010 (UTC)
The "in house" styles are based on other reference styles (not sure which ones), calling them "second best" is more POV than anything else. There is a {{Harvard citation}} template, but it is barely used (2584) compared to {{Cite web}} (788233) or {{Cite new}} (222986). Using a citation template is in my opinion aways the preferred way to go because it severely limits the issue of typos or other inconsistencies. WP:BURLS has the following to say about exposed URL's "Secondary problems with bare URLs are that —unless a readable text is used — they are ugly, and can affect the display of a page. For example, this bare URL with no readable text causes page widening", followed by an example. Xeworlebi (talk) 18:01, 24 December 2010 (UTC)
This part of the discussion is beyond the scope of the template. ---— Gadget850 (Ed) talk 18:08, 24 December 2010 (UTC)
Here is a another way to test:
  • Replace {{Reflist|2|refs= with <references>
  • Replace the final }} with </references>
This directly uses the Cite tags and will show that the styling applied by {{reflist}} or its sub-templates are not the issue. There have been a few CSS changes at MediaWiki:Common.css. I don't see they could have had this effect, but it is why I checked on another wiki that did not have those changes. ---— Gadget850 (Ed) talk 18:50, 24 December 2010 (UTC)
I've tried that and it's the same effect. I guess it doesn't matter that much since it literally takes all of 1 second to fix, and there is no urgency to address it so I'll just sort it out on the affected articles when I next edit them. I think it must have started happening after December 12 when there was a lot of snooker article activity, because when I add references I always check to see that they're rendered correctly so I would have noticed if it was happening then. Anyway, thanks for your assistance. Betty Logan (talk) 19:04, 24 December 2010 (UTC)
I think it does matter that this gets fixed. Many editors prefer parameters on separate lines. Also, if you copy a template with parameters from (for instance) Template:Citation, it has a pile of line breaks, presumably encouraging editors to use that format. I tried Gadget850s suggestion on Kyoto Municipal Zoo and the problem persists (and removing line breaks fixes it). Using Gadget850s own logic, "this directly uses the Cite tags and will show that the styling applied by {{reflist}} or its sub-templates are the issue" (Italics mine). The Kyoto Zoo article was fine when I last looked (on 11/20). If you look here you will see that the problem now exists in the 11/20 version, showing that it was not an edit someone made that caused the problem, but something in the template or CSS. Obviously we can all go in and fix this issue in hundreds of articles, but we should not need to do this. Donlammers (talk) 17:18, 27 December 2010 (UTC)

Ok, I think I've figured it out. It has nothing to do with this template, or with the css. The culprit is this edit to MediaWiki:Cite references prefix combined with MediaWiki's use of HTML Tidy.

The problem only occurs on the first reference in the references list, and only when that reference has linebreaks after the <ref> and before the </ref>, like this: 

<ref>
Citation goes here.
</ref>

Previously, the output HTML for the references list looked something like this: 

<ol><li>^
Citation goes here.
</li></ol>
  1. ^ Citation goes here.

With {{reflist}}, it looked something like this: 

<div>
<ol><li>^
Citation goes here.
</li></ol>
</div>
  1. ^ Citation goes here.

Everything was good. Now, however, as a result of the edit mentioned above, the output (before HTML Tidy) looks something like this: 

<div><ol><li>^
Citation goes here.
</li></ol></div>
  1. ^

    Citation goes here.

Or with {{reflist}}: 

<div>
<div><ol><li>^
Citation goes here.
</li></ol></div>
</div>
  1. ^

    Citation goes here.

As you can see, the bug now occurs. My best guess is that the <div> on the same line as the <li> for the start of the first reference is making tidy decide that it needs to paragraphize the remaining lines of the content of the <li>. For whatever reason tidy doesn't do this if that <div> isn't on the same line, which is why {{reflist}} never triggered it before despite using an almost-identical setup: {{reflist}} has a linebreak between the div and the references list.

So the solution requested by Donlammers seems to be simple: edit MediaWiki:Cite references prefix to put a linebreak between the <div> and the <ol>, and for good measure do the equivalent to MediaWiki:Cite references suffix. Anomie⚔ 20:07, 27 December 2010 (UTC)

Agreed, and done. —TheDJ (talk • contribs) 20:39, 27 December 2010 (UTC)
Thanks Anomie, it is nice to know what is causing the bug. Now the cause is isolated hopefully it will be sorted out! Betty Logan (talk) 20:43, 27 December 2010 (UTC)
I would not have guessed tidy was to blame. That program can be a real pain sometimes. — Edokter • Talk — 21:12, 27 December 2010 (UTC)
I thought HTML Tidy was not enabled for the MediaWiki namespace. ---— Gadget850 (Ed) talk 22:28, 27 December 2010 (UTC)

Thank you. I have checked a few articles I knew that should have had the problem, verified that they had either a space before {{, or a line break after }} (or both), and they are fine now. It looks like the problem is solved and we don't need to go back and try correcting individual articles. Having said that, I will probably try to avoid the circumstances in any future editing I do (which, of course, guarantees that next time it will be something else). Donlammers (talk) 00:37, 28 December 2010 (UTC)

3 column parameter

The documentation currently says, "Three-column lists may be inaccessible to users with smaller/laptop monitors and should be avoided." That leaves the question whether existing uses of the parameter should be left in place or removed. If the goal is that the parameter shouldn't be used at all, why is it in the template? If the goal is to leave existing uses, the documentation should say so. — Carl (CBM · talk) 12:53, 30 November 2010 (UTC)

That sentence has been there for ages, but I feel it is out of scope in the template documentation. It entirely depends in what context reflist is used. I'll remove it. — Edokter • Talk • 13:09, 30 November 2010 (UTC)
I think I brought this up fairly recently. Three columns are quite applicable to shortened footnotes. ---— Gadget850 (Ed) talk 13:40, 30 November 2010 (UTC)
That's what I thought, but I have seen people change an article from 3 to 2 based on the unilateral recommendation here that 3 columns "should be avoided". — Carl (CBM · talk) 13:45, 30 November 2010 (UTC)

I'd like to reopen this. I'm one of those who change from 3 to 2 for the above reason. I was about to again when I went looking for the anti-3 authority to cite and found this. So I tested both layouts in my browser (Firefox 3.0.4) narrowed to about half the screen width, thus about 500 pixels (from normally 1024x768), which I think will be normal for many users, including netbook users and probably large-monitor users who have many windows open at once and thus prefer them smaller, and probably cell phone users are even more a concern. The 3-column layout makes columns of mostly single words. The 2-column layout is more readable. In both cases, some linked texts run longer and overlap into the next column, reducing readability further, or force horizontal scrolling, which is unpopular (per useit.com). I don't usually see footnotes that are so short that they'd occupy only one line each in a 3-column layout at 500 pixels wide. I usually work at full window width, so 3 columns are fine for me, but so are 2 columns, and other users should benefit from readability, too. Is there a strong enough rationale for 3? Thanks. Nick Levinson (talk) 05:35, 30 December 2010 (UTC)

Three columns works very nicely for pure shortened footnotes; see Chaco Culture National Historical Park#Citations. It does not work as well when long and shortened footnotes are mixed. ---— Gadget850 (Ed) talk 13:39, 30 December 2010 (UTC)

No column support

Under the subsection No column support; please could an administrator add AOL, as there is no difference between {{Reflist}} and {{Reflist|2}} when viewed on AOL. Obscurasky (talk) 23:16, 28 December 2010 (UTC)

AOL uses Internet Explorer under the hood, which does not support columns. We only list the major browser families; listing them all individually would take an inordinate ammount of space. — Edokter • Talk — 00:52, 29 December 2010 (UTC)
OK, thanks anyway Obscurasky (talk) 01:17, 29 December 2010 (UTC)
Now that I look at the latest report, I don't see AOL listed at all, but it could show as IE.[1] I am going to agree— any browser with less than 1% traffic is not a major concern. ---— Gadget850 (Ed) talk 02:45, 29 December 2010 (UTC)

Include section title

Should we have a version of this template that includes a section title? I predict that >99% of the time, "== References ==" (or, equivalently, "==References==") precedes "{{Reflist}}"--Elvey (talk) 19:17, 9 January 2011 (UTC)

No. The edit link will then open the template for editing, not the article. You can create a heading using HTML, but then the edit link does not appear. Either way you would have to edit the entire article to change the reflist parameters. And the section title may be Notes, Bibliography, Works or other titles. ---— Gadget850 (Ed) talk 20:04, 9 January 2011 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Template_talk:Reflist/Archive_17&oldid=1179467632"