Last modified: 2010-11-14 10:51:56 UTC
In special:Preferences we see [ ] Show table of contents (for pages with more than 3 headings) However, many browser users will wonder "why doesn't it work for me?" "wikipedia has always been fair to me, even though I don't use "IE", what went wrong now?" "Do I not use their recommended browser or something?" Therefore mention (requires JavaScript ( or requires stylesheets or whatever it requires)) right there on the choice (respect for disabled users --I'm not asking you to rewrite the software, just make clear what will go wrong right there on Special:Preferences.) Same with some other choices on Special:Preferences. And perhaps group them into "requires JavaScript" "requires ..."... or if this seems too fuddy duddy, then at least add the warning (requires ...) to each... you indeed do so already for some, but not all the ones that have such hidden requirements to work right.
Tables of Content don't require JavaScript in order to be rendered on a page; JavaScript is required for the hide/show functionality, but not the basics of having one on a page. I'm not aware of any *functionality* that requires "stylesheets", since we treat CSS like it's supposed to be treated - for decoration and aesthetics. Finally, your implied assertion that we're all a bunch of IE-loving Windows users is, frankly, offensive. We've got a pretty good grasp of web standards and accessibility issues, and this patronising tone in your bug reports is not at all helpful
No matter how you set your preferneces you are not going to get rid of the TOC in lynx, w3m, etc. Can you make the TOC dissapear in lynx? Tried on http://wikimania2007.wikimedia.org/wiki/Team_and_Volunteers Therefore some note should be added to Special:Preferences at the TOC choice, mentioning why it won't work in some browsers. Also one sees WARNING: Your browser is not unicode compliant. A workaround is in place to allow you to safely edit articles: non-ASCII characters will appear in the edit box as hexadecimal codes. With User-Agent: Lynx/2.8.7dev.5 libwww-FM/2.14 SSL-MM/1.4.1 GNUTLS/1.6.2 even though it is not on $wgBrowserBlackList.
The TOC is displayed or not completely server-side and should display fine in Lynx. Unfortunately it's rather tricky to test on Wikipedia when you have to fill out a captcha to log in . . .
Er, the preference seems to be broken, full stop. With it disabled (i.e. indicating no table of contents), I still see a table of contents; this is the same with JavaScript or without it. There's no reference to a "table of contents" user preference in User::getPageRenderingHash(), so I'm thinking that, assuming I'm not seeing things, the preference has been ignored for some considerable time.
The preference appears to work for me correctly, irrespective of JavaScript. I tested on enwiki with [[Cougar]].
Yes, I, er, ran into a private caching issue...*cough*.
Let's take http://en.wikipedia.org/wiki/Wikipedia:Bypass_your_cache for example. Can you manage to get the server to send a copy of it to your browser, no matter which brand, yes, logged in, without containing table id="toc" class="toc" summary="Contents" in the HTML of that page?
Oh dear. You're correct, quite sorry. It's hiding it via CSS. Let me see about fixing that.
Same goes with "Enable section editing via [edit] links" The server generates the pages with the most options-out, hiding the undesired ones with CSS, so the page code can be cached, no matter what the user options are. I'm inclined to wontfix it. Maybe add to these options <span style="display: none">CSS is disabled, setting will always be shown</span> ?
Oh, hmm. I see the point, yes.
Regarding: "Maybe add to these options <span style="display: none">CSS is disabled, setting will always be shown</span> ?" Are you saying add some stylesheet stuff to Prefernces, assuming that they will be using the same browser to edit preferences as the one they will be using to view pages days later? Bad. Therefore add hard coded HTML in Preferences: "requires sytlesheets", "requires javascript", etc. Do the above now, and perhaps later one day move this perhaps overdependence of .css and .js into real HTML, as you still have the user's name personalized into the page so can't cache that part at least.
(In reply to comment #11) > Do the above now, and perhaps later one day move this perhaps overdependence of > .css and .js into real HTML, as you still have the user's name personalized > into the page so can't cache that part at least. That's not part of the parsed page, which is what we try to cache as aggressively as possible given our atrociously slow parser. There are other user preferences that invalidate parser cache, but there's no point in adding new ones when the existing ones work for the 99.8% of our users not using Lynx.
By the way things like "Show edit toolbar (JavaScript)" need to be rephrased "Hide edit toolbar (requires Javascript)" Same for the many of the rest of the items. P.S., clicking on the linked word "toolbar" causes the box to be checked as a side effect! Also drat: no way to get all those greek etc. characters out of the user's browser unless he consents to javascript. Having lots of weird characters sent to ones browser is not necessarily enjoyable or thrifty. Wait, you guys are surely the bloat professionals: all that "onclick" stuff should be in a separate .js file called in if javascript is enabled in the first place!
(In reply to comment #13) > P.S., clicking on the linked word "toolbar" causes the box to be checked as a > side effect! Not sure if that's avoidable. Open a new bug for that if you want. > Also drat: no way to get all those greek etc. characters out of the user's > browser unless he consents to javascript. Having lots of weird characters sent > to ones browser is not necessarily enjoyable or thrifty. > > Wait, you guys are surely the bloat professionals: > all that "onclick" stuff should be in a separate .js file > called in if javascript is enabled in the first place! I believe that's a site-specific issue, isn't it? enwiki has that really poorly configured (although the Charinsert extension does promote such configuration, admittedly). If this occurs in an uncustomized version of MediaWiki, please open another bug about it.
Today I'm adding the accessibility tag to several bugs... though not checking the details, stylesheets are for style. Content should be via HTML..
The only way to hide the TOC for lynx user would be to not insert in the HTML output. That would disable page cache for those users something we want to avoid. This impact a really small number of people and does not cause any trouble to actually read the content. I am inclined to wontfix this bug report.
I'm just saying that there should be something saying why this won't work in some browsers (text browsers), visible there to a person about to click this preference. You could even hide that something in some CSS so it will only be visible in those browsers affected.
Every feature doesn't work in this or that browser. We don't want to overload users with loads of useless information because, for example, TOC hiding works for 99.99% of them.
Following Aryeh, Platonides & Max Semenik, I am now closing this bug report as WONTFIX.
