Template talk:Reflist/Archive 9

Archive 5

←

Archive 7

Archive 8

Archive 9

Archive 10

Archive 11

→

Archive 15

Safari bug

As noted, Safari has a link positioning bug when multiple columns are enabled; the problem is illustrated in Template:Reflist/Safari testcase. The testcase does not use {{reflist}}, so it will still show the problem regardless of changes to reflist.

I intend to disable mult-column support for Safari by removing -webkit-column-width:{{{colwidth}}}; and -webkit-column-count:{{{1}}};. When the Safari bug is fixed by Apple then we can restore this feature. --—— Gadget850 (Ed) ^talk - 16:43, 3 September 2008 (UTC)

If that means that when I click on a reference number I will be taken to the reference, then I am all for it. DuncanHill (talk) 16:46, 3 September 2008 (UTC)

That is exactly what it means. --—— Gadget850 (Ed) ^talk - 17:14, 3 September 2008 (UTC)

Please do this! And thanks for figuring this out! Yilloslime (t) 17:20, 3 September 2008 (UTC)

 Done If you still see multiple columns, purge the page. --—— Gadget850 (Ed) ^talk - 02:35, 6 September 2008 (UTC)

I noticed that Google Chrome is WebKit based; it has the same bug as well. --—— Gadget850 (Ed) ^talk - 03:16, 6 September 2008 (UTC)

Thanks!! ---- CharlesGillingham (talk) 20:06, 6 September 2008 (UTC)

The webkit bugs on this were reported by me over a year or so ago. I have now documented their tickets at at the testcase, so that people can track the progress on this. --TheDJ (talk • contribs) 14:14, 29 October 2008 (UTC)

Safari: Multiple columns broken

I'm using the latest release of Safari (3.1.2) on Mac OS X and reflist|2 shows only one column, same for reflist|3. See, for example, Roger Federer#References. Can anyone with my same setup test this and confirm it's not only me. Thanks. ☆ CieloEstrellado 04:10, 6 September 2008 (UTC)

I use Safari 3.1.2 on WinXP, reflist|2 is now shewing as only one column - but this is an improvement as it overcomes the broken linkage between references in the text and in the reflist, discussed at length above. DuncanHill (talk) 09:34, 6 September 2008 (UTC)

As noted just above, Safari and Chrome have a bug. To see it, open Template:Reflist/Safari testcase with either browser and click on [150]. The link takes you to the bottom of the page instead of to the reference. When the bug is resolved, we will restore this feature. --—— Gadget850 (Ed) ^talk - 12:27, 6 September 2008 (UTC)

I'm not sure this is a good compromise. Articles can get very long with a single ref column. Plus, the bug you talk about is really not that bad, as you can scroll up and down and see the highlighted reference anyway. However, if this is just temporary, then it's no big deal. ☆ CieloEstrellado 04:47, 7 September 2008 (UTC)

One cannot simply scroll up and down to find the reference - when the "a,b,c" thing is used it is impossible to get from a reference to its position in the text. DuncanHill (talk) 21:38, 14 September 2008 (UTC)

It should be temporary. That said, I really appreciate the workaround, the bug was extremely annoying to me, as I use Safari as my primary browser. Titoxd^{(?!? - cool stuff)} 08:28, 7 September 2008 (UTC)

I also found the bug very annoying (it's a real problem for articles with 100+ footnotes), and I am very glad that it is gone.---- CharlesGillingham (talk) 22:24, 7 September 2008 (UTC)

I'm still having the issue, so I'm assuming it hasn't been fixed. I don't really see why we had to disable the support for the browser for the duration, it wasn't really a critical use issue... Der Wohltemperierte Fuchs ^(talk) 15:20, 8 September 2008 (UTC)

We had a few very vocal Safari users complaining about it. At one point there was a proposal that would have allowed creation of a gadget to enable/disable the feature for anyone with an account, but no one paid any attention. Anomie⚔ 22:49, 14 September 2008 (UTC)

I for one certainly said I would welcome such a gadget. DuncanHill (talk) 22:56, 14 September 2008 (UTC)

There is another problem resulting from disabling this feature for Safari users. It means that those users are not seeing the same layout as other users. I use multiple browsers on multiple systems. When I'm on Safari, I'd much rather see the correct layout even with the footnote-jumping bug, than see a disabled one-column version.

I request that this template be restored to the prior form, while a solution to the bug is researched. The jumping-error is less of a problem than the inconsistent formatting. --Jack-A-Roe (talk) 21:34, 14 September 2008 (UTC)

IE users only ever see single columns too. The jumping problem is awful - it makes references virtually useless on some articles. DuncanHill (talk) 21:36, 14 September 2008 (UTC)

Oh, that's different. If this change is affecting all browsers, then we're all seeing the same format, that's then not a problem.

However, in that case, I recommend modifying the documentation for the template to note that the multiple column feature is temporarily disabled and that parameter has no effect. Otherwise, editors will waste time trying to figure out what's wrong. --Jack-A-Roe (talk) 21:38, 14 September 2008 (UTC)

Update: I just reviewed the documentation. It's sort of strange - it says the parameter makes multiple columns, but then it says a bunch of technical stuff that boils down to: This doesn't work on Safari, Chrome, Opera, or Internet Explorer (in other words, almost all commonly-used browsers except Firefox), and in Firefox it might "create windows" or "mangle" URLs.

It seems to me, the documentation should be changed to simply state that multiple columns currently don't work and support will be added as soon as possible. Or something to that effect. --Jack-A-Roe (talk) 21:43, 14 September 2008 (UTC)

Unfortunately there was huge resistance to such a solution from the tiny minority of users who have no display problems with the multicolumn feature, such that no consensus could be reached. The current measure was a compromise, which at least means that the most essential element works (i.e. correct linkage between a reference and its place in the text). DuncanHill (talk) 21:47, 14 September 2008 (UTC)

Why not update the documentation to reflect the actual situation then? It could say something like: For users of the following browsers: (list the ones where it works OK), references can be listed as multiple columns by using this parameter. For users of all non-listed browsers, the reflist produces one column and is not affected by this parameter. This will be improved in a future version.

The documentation should be provided so it explains clearly how to use the template, for the majority of users. As it is currently reads, to non-technical users, it's very confusing and could waste a lot of time. I recommend we make this change. Does anyone object? --Jack-A-Roe (talk) 21:54, 14 September 2008 (UTC)

Jack-A-Roe, please note that there is no requirement that everything display exactly the same in all browsers. The documentation seems clear enough IMO, you managed to figure it out easily enough. There is nothing we can do about Safari's bug except disable it for Safari (or not) and wait for Apple to get around to fixing it. Anomie⚔ 22:49, 14 September 2008 (UTC)

DuncanHill, one could say that a tiny minority came here complaining about Safari's issue and demanding the removal of the feature for all browsers, even though no other browser had issues with it. Even though we disabled the feature for Safari, that wasn't enough to satisfy them. Perhaps they would be better served by pressuring Apple to fix the bug in their browser instead? Anomie⚔ 22:49, 14 September 2008 (UTC)

Excuse me, who precisely "demanded" the removal of the feature for all browsers? I seem to recall you were unable to answer a similar question last time you made that less-than-accurate claim. "Even though we disabled the feature for Safari, that wasn't enough to satisfy them" - I don't see dissatisfaction from those who participated previously. DuncanHill (talk) 22:55, 14 September 2008 (UTC)

How quickly you forget. Anomie⚔ 23:57, 14 September 2008 (UTC)

I see that you can't answer the question. DuncanHill (talk) 00:01, 15 September 2008 (UTC)

Believe what you want, if my pointing to you saying exactly that isn't answer enough then there is no point in my continuing this conversation. Anomie⚔ 00:52, 15 September 2008 (UTC)

But you didn't link to me saying exactly that. You keep doing this Anomie, lying about what I have posted. I don't know why you do it, but it is a lousy habit for you to have got into. I am satisfied with multicolumns being disabled on Safari as a short-term fix, that's why I thanked the editor who did it. I'm also profoundly dissatisfied with your approach to discussion. DuncanHill (talk) 09:53, 15 September 2008 (UTC)

(ec) Anomie, are you saying that it does work correctly in Internet Explorer? My prior comment was based on the information on this page that it's also broken in IE. If that's correct, then it's broken in the majority of browsers, not just Safari. If Safari is the only browser it's not working, I'd not have written that second comment. Also, I'm not basing my comment on a " requirement that everything display exactly the same in all browsers", I was offering feedback from the viewpoint of a regular user. My comments are collaborative, not complaints. --Jack-A-Roe (talk) 22:57, 14 September 2008 (UTC)

It doesn't have a bug in IE like it does in Safari, hence it's not "broken". IE just doesn't honor the directive. I'm sorry I misunderstood your comment earlier regarding "It means that those users are not seeing the same layout as other users". Anomie⚔ 23:57, 14 September 2008 (UTC)

Thanks for explaining. I wrote my other comment below before I saw your reply here. I don't mean this to be an argument at all, just trying to understand the situation and find the best solution. --Jack-A-Roe (talk) 00:00, 15 September 2008 (UTC)

• For previous debate on this matter, see Template talk:Reflist/Archive 2008#Multiple columns deemed bad and pretty much the whole of the rest of that archive. DuncanHill (talk) 23:04, 14 September 2008 (UTC)

Thanks for the link. With that context this makes much more sense. After reading the archives, my impression is that the multiple-column feature only works on a small minority of browsers, according to this data copied from the this section of the archive:

Multiple columns

• FireFox (13% market share): works with caveats
• Safari: (6%): exposes a bug in Safari through 3.1.2 where the linking is mispositioned
• Internet Explorer (73%): multiple columns does not work and is not planned to be supported by IE8

If the above is accurate, that means that for 79% of users, the multicolumn feature does not work or works incorrectly, and of the remaining 21% of users, an unknown portion of the 13% who use FireFox experience "caveats" (such as "creating windows", according to the template documentation). That leaves between 21% and just a few % who see the two columns as intended, with jumping functioning properly. That's a very low rate of dependable penetration for a Wikipedia feature.

Since Wikipedia is intended for wide use, maximum browser compatibility is important. The multiple column feature should not be used until it can be used dependably and the template documentation should be changed to indicate it is deprecated so editors don't try to use something that doesn't work. Or if it's desired to use it just for browsers that support it, the short list of supporting browsers should be clearly listed in the documentation, with a prominent note at the top that for all other browsers, one column is what they will see. Just my 2 cents. --Jack-A-Roe (talk) 23:57, 14 September 2008 (UTC)

That's "widows", not "windows"; all it means is that the final line of a reference might end up at the top of the next column. The URL problem is that if someone puts a poorly-formatted reference with a very long URL (or if the URLs are shown in the printable version), that long URL might end up overflowing into the next column over. Only the WebKit renderer (used by Safari and Chrome) is truly incompatible with the feature, and fortunately we can omit the -webkit-column-count parameter to easily disable it just for those browsers. Anomie⚔ 00:52, 15 September 2008 (UTC)

> I recommend modifying the documentation

• I'm looking at that— what we have is all correct, but it could use a bit of reorganization.

> maximum browser compatibility is important

• True, but columns are purely aesthetic- the references function in the same manner regardless of the number of columns.

> poorly-formatted reference with a very long URL

• This only applies to the printable version, and is not a reference formatting issue. The printable version shows the full URL; some very long URLs do not wrap at the column.

--—— Gadget850 (Ed) ^talk - 03:05, 15 September 2008 (UTC)

I should point out a workaround for this issue is to wrap {{reflist}} in {{refbegin}} and {{refend}}, and in refbegin specify the column numbers; see for example Edward Drinker Cope. No idea what that looks like to people without the bug. Der Wohltemperierte Fuchs ^(talk) 03:35, 23 September 2008 (UTC)

Note that {{refbegin}} uses the exact same code that was just removed from this template, and thus will exhibit the same bug in Safari that prompted that removal here. Also, you should wrap <references/>, not {{reflist}}, otherwise you get excessively small fonts. Anomie⚔ 11:12, 23 September 2008 (UTC)

Eh, in Safari 1.3.2 under 10.5.5 my workaround actually does work; it jumps properly. Thanks for the references tag though, not it properly renders in the correct size. I encourage all safari uses to check it out and see if it works for them. Der Wohltemperierte Fuchs ^(talk) 11:27, 23 September 2008 (UTC)

Breaks in 3.1.2 for me, both the Windows version and an OS X version I happened to have access to this morning. Are you really using 1.3.2, or was that a typo? Anomie⚔ 12:05, 23 September 2008 (UTC)

This only appears to work because the Coper article does not have a lot of content after the references as compares to articles such as Harry S. Truman. See Template:Reflist/Safari testcase1. --—— Gadget850 (Ed) ^talk - 11:57, 23 September 2008 (UTC)

Easy enough to see even in the Coper article, at least if you size your browser to small enough that scrolling is needed. In my test, ref 49 in that article was at the top of the 3rd column, and clicking the ^[49] brought me to the bottom of the page. Anomie⚔ 12:05, 23 September 2008 (UTC)

Use HTML, not CSS

Why not switch to a non-CSS solution? It is much more likely to work in a large number of browsers. I think it's a desirable feature. SharkD (talk) 10:07, 15 September 2008 (UTC)

Reflist is merely a wrapper for <references />, which is part of mw:Extension:Cite/Cite.php. I don't know of any way to do columns in HTML that would work here. --—— Gadget850 (Ed) ^talk - 11:04, 15 September 2008 (UTC)

Furthermore, there's no negative to having it work on some browsers and fail gracefully on others, while devolving it into an HTML (or JavaScript) solution would provide little incentive for browser vendors to fix their bugs. I believe {{reflist}} is probably the most common use of CSS columsn on the Internet right now. Chris Cunningham (not at work) - talk 08:22, 16 September 2008 (UTC)

Of course there's a negative: it fails. It's like saying there's no negative when your car fails gracefully, but doesn't fail catastrophically. SharkD (talk) 08:31, 16 September 2008 (UTC)

It fails gracefully; it still presents the list to the user, it just omits some styling. I dare say that this will be fixed in WebKit sooner rather than later, which means that the only major browser where it won't work is IE, and if we have to make everything backwards-compatible with IE we'll never get anything done. Chris Cunningham (not at work) - talk 10:42, 16 September 2008 (UTC)

To do it in HTML would require combination of counting characters and counting lines, then splitting the content into two floating divs. Counting characters across multiple child elements would be rather tricky, but could be done even with JavaScript alone. SharkD (talk) 08:41, 16 September 2008 (UTC)

You are certainly welcome to work with the developers on this. I'm more of a hardware guy. --—— Gadget850 (Ed) ^talk - 09:03, 16 September 2008 (UTC)

(outdent) It is possible to have the server generate multiple columns in a portable fashion using simple divs and <ol start="n"> (btw, start="n" was deprecated in HTML 4.01 but is back in 5.0). The negative side effect of this approach is that, under certain conditions (the same conditions for which reflist's cols= should not be used), columns will not all be equally long. I can provide the necessary html if someone savvy in php is willing to write a patch. -- Fullstop (talk) 13:51, 23 September 2008 (UTC)
ps: It is not fixable by "counting characters" as not all characters are equally wide in variable-width typefaces (used by all wikis), nor in scripts that have ligatures or diacritical marks.

Why don't you provide the HTML publicly and see if anyone finds it interesting enough to write such a patch? Anomie⚔ 16:50, 23 September 2008 (UTC)

(outdent)
Done. See below. Passes (X)HTML/CSS validation just fine. -- Fullstop (talk) 11:27, 27 September 2008 (UTC)

That's what I was suspecting your "solution" might be. IMO, "any case where a ref might span more than one line" is far too restrictive to be legitimately included in the "certain conditions" under which it would break. Anomie⚔ 13:54, 27 September 2008 (UTC)

You know, its not very nice to ask for a solution when you have already mentally rejected it.

But you seem to have not considered that...

• the div solution complements the existing -moz-column-count css; it doesn't replace it. Since the existing css trick remains, anything that works for other browsers is actually less restrictive than the existing solution.
• Uneven content length is -- considering the alternative -- a lesser of two evils. Columns, even if of uneven length, are a sight better than having no columns, which is the case for the vast majority of users. If the consideration that columns could have uneven length is "far too restrictive", then what on earth is the restriction to gecko-based browsers?

But whatever. -- Fullstop (talk) 16:06, 28 September 2008 (UTC)

I could have been wrong and you had something really novel; an earlier draft of my request did say effectively "Don't bother if it's X", but I felt that was too uncivil and removed it.

It doesn't actually complement the existing column-count CSS: if you try to combine both methods of getting 2 columns, in FF3 you end up with 4 columns in an odd order (when I tried it with the US article, I got #1 at the top of the first, #102 at the top of the second, part of #62 at the top of the third, and part of #154 at the top of the fourth). If you put the column-count on the inner DIVs instead of the outer, you'd still get 4 columns instead of the desired 2 but at least they'd then be in the right order. I suppose you could use some CSS hacks to set the "width:50%;float:left" in IE and Safari while hiding it from modern browsers, but CSS hacks are by nature fragile.

The browser restriction is just a matter of the visitor using a browser that doesn't fully support the offered non-essential feature; it's not like the page is completely unusable to those users. You could as well complain that viewing of images is restricted to graphical browsers, or that collapsing of navboxes is restricted to Javascript-enabled browsers, or that non-CSS-capable browsers get a Wikipedia that is almost completely unformatted and has extraneous metadata displayed in certain places (try it some time). Anomie⚔ 18:55, 28 September 2008 (UTC)

The html I provided was an example of how to do columns using "HTML not column-count", not "HTML/column-count not column-count". The example wasn't intended to demonstrate what has already been demonstrated.

Two ways to skin the "complement existing css" cat are provided below. They work just fine. Your "2 becomes 4 columns" etc does not in fact happen. Change -moz-column-count in the examples to 2, and that is exactly what you will get (or 1 or 4 or whatever else you tell it to do).

Re: applying it to USA: you have to get the server to break up the list for you. You can't do this for <references /> after the fact. That is the whole point of needing a php patch.

Re: "The browser restriction is just a matter of the visitor using a browser that doesn't fully support the offered non-essential feature". That is not a good stance to take for two reasons:

• We aren't speaking of the tiny minority of non-graphical, non-JS, non-css browsers. We are speaking of the vast majority. I don't belong to that majority, but I'm still taking the time and effort to be considerate of it.
• But even if they were the minority: if someone was physically handicapped (and not just browser-handicapped), you still wouldn't run them off the sidewalk would you?

Incidentally, "CSS hacks are by nature fragile" had me laughing. What do you think -moz-xxx and other browser-specific stuff is? Anyway, the following examples require no more hackery other than -moz-xxx kind of hackery.

ps: please don't lump Safari with IE cruft. Webkit is very modern.

-- Fullstop (talk) 03:18, 29 September 2008 (UTC)

Point by point reply:

• I've tested your examples in IE6, IE7, FF3, and Safari. Your first example only works in IE6 and FF3; it does not work in Safari or IE7. Your second only works in FF3, failing in IE6, IE7, and Safari. That's far from working "just fine".
• I'm not sure if you're denying my report that "2 becomes 4 columns" completely, or just overlooking the fact that I specified that it was without CSS hacks or other such. If it's the latter, you should also be more careful with your writing, as you specifically stated that your original version did not replace the column-count CSS and you did not specify that CSS hacks or IE conditional comments were required.
• Are you really suggesting I'm so dumb as to put something around the <references/> to try to test your proposal? I used Firebug to manipulate the HTML in my browser; I could also have downloaded the page and edited the HTML in the local copy.
• Whether it's a majority or a minority doesn't really matter, it's still just a minor feature that improves the display for supporting browsers while having no effect (and especially no negative effect) on non-supporting browsers.
• I think "-moz-xxx" is a vendor-specific CSS extension as defined in the CSS specification. A CSS hack is something that takes advantage of parser bugs in certain implementations and may be fixed in any future version of the browser.

Ad hominem attacks are completely uncalled for. Don't expect any further reply from me in this topic. Anomie⚔ 11:52, 29 September 2008 (UTC)

• Apologies if you think that there were any ad hominems. None were intended: I did not think you would be "so dumb" to put the html around <references /> I merely supposed that you were not familiar with html/css. After all, every html newbie learns early that doing something in multiple ways is sometimes necessary to get things to appear in a uniform fashion.
  Look at it this way: If you had known better then you would have immediately known how to rewrite it so that three ols appear in columns for IE, and appear as one long ol in the rest (after which column-count can then do its bit). But since you didn't follow that up, but instead insisted that X precludes Y and supposed that "2 becomes 4 columns", it seemed obvious that html/css was not your cup of tea. The alternative to that would have been to assume that you could have figured it out yourself, but instead consciously chose not to do so (or chose not to say that/what you had figured out). But I didn't assume that. I assumed that you had a genuine interest in finding a general solution. Was I wrong to do so?
• these are "proofs of concept". The subject of this section is "html not css" and both cases demonstrate that columns can be created in html, in the second instance to show that creating columns in html does not preclude the use of column-count. That is all.
• The "just a minor feature that improves the display for supporting browsers" makes sense. But then why is it a problem when browsers running the examples show exactly the same thing they have been showing so far with reflist?
  Also, your observations on which IEs do what doesn't jive with what netrenderer returns when I simply stuffed the lot into a standalone html file and let them render it in various IEs (it returns the result as images). While you observed that the conditional html example didn't work for any IE, netrenderer shows that it works for all IEs, including 8 beta 2. I wonder why the difference. Influence from external stylesheets perhaps?
  Doesn't matter though. The fact is that "improving the display for supporting browsers" does not preclude that one should at least try to also find a way to support other browsers. Not unlike the 'pedia finding a way to "improve the display" for (older) IEs that have incomplete .png support.
• Using css to create columns is not a resort to "parser bugs". The use of floats to create columns is standard practice and works for every browser that understands 'float' at all. The rest, e.g. Netscape 4 and IE 4, see it as a long list, just as reflist does now.
• How the "columns" are presented is even irrelevant to the subject at hand, which is identify what a .php patch would need to do. The patch would of course simply make <references /> return chunks instead of a long list. For example, <references chunk="1/3" [class="foo"] /> to get the ol for the first of three columns. This is the only piece of "html" related to the question of a .php patch. The returned lists would then be arranged as columns (or whatever) on the wiki side. Servers do not (should not) do presentation; that is a wiki-side issue.
• The greater issue (see all talk preceding this) is general availability of columns. If there is interest in providing columns, then we (everyone!) can together find a general solution for it. The foregoing discussion seems to indicate that general support of columns would be a good thing. If this is not the case then of course there is no point in discussing it either. -- Fullstop (talk) 21:28, 30 September 2008 (UTC)

HTML not CSS example

What follows is a simple 3x3 column example. Resize the browser window to see reflow.
In both examples...

• the columns are are css generated for Gecko and other browsers that support column-count
• the columns are html generated for Trident
• the rest see only one column

A "how it works" is provided in inline html at the top of each section.

Example 1, using conditional CSS

1. Polybius, Histories 10.27.11.
2. Arrian, Anabasis of Alexander 7.14.
3. Pliny, Natural History 6.35.

4. Tacitus, Annals 3.62.
5. Strabo, Geographica 16.1.18.
6. Cicero, Pro Lege Manilia 9.23.

7. Strabo, Geographica XI 8.4, XV 3.15.
8. Pliny, Natural History 33.82-83.
9. Pausanias, Description of Greece 7.27.5.

---

Example 2, using conditional HTML

1. Polybius, Histories 10.27.11.
2. Arrian, Anabasis of Alexander 7.14.
3. Pliny, Natural History 6.35.
4. Tacitus, Annals 3.62.
5. Strabo, Geographica 16.1.18.
6. Cicero, Pro Lege Manilia 9.23.
7. Strabo, Geographica XI 8.4, XV 3.15.
8. Pliny, Natural History 33.82-83.
9. Pausanias, Description of Greece 7.27.5.