robchur wrote:

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.

ayg wrote:

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 . . .

robchur wrote:

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.

ayg wrote:

The preference appears to work for me correctly, irrespective of JavaScript. I tested on enwiki with [[Cougar]].

robchur wrote:

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?

ayg wrote:

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> ?

ayg wrote:

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.

ayg wrote:

(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!

ayg wrote:

(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.