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
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
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.
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?
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.
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 . . .
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.
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  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?
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
need to be rephrased
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!
Wait, you guys are surely the bloat professionals:
all that "onclick" stuff should be in a separate .js file
(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
> 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
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.