Last modified: 2010-11-14 10:51:56 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T12212, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 10212 - TOC/section edit display preferences should be marked as requiring CSS
TOC/section edit display preferences should be marked as requiring CSS
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
User preferences (Other open bugs)
1.11.x
All All
: Lowest trivial (vote)
: ---
Assigned To: Nobody - You can work on this!
: accessibility
Depends on:
Blocks: css
  Show dependency treegraph
 
Reported: 2007-06-10 23:20 UTC by Dan Jacobson
Modified: 2010-11-14 10:51 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Dan Jacobson 2007-06-10 23:20:08 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.
Comment 1 Rob Church 2007-06-10 23:31:18 UTC
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
Comment 2 Dan Jacobson 2007-06-11 00:28:31 UTC
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.
Comment 3 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-06-11 01:40:53 UTC
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 . . .
Comment 4 Rob Church 2007-06-11 04:48:27 UTC
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.
Comment 5 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-06-11 04:54:05 UTC
The preference appears to work for me correctly, irrespective of JavaScript.  I tested on enwiki with [[Cougar]].
Comment 6 Rob Church 2007-06-11 04:59:13 UTC
Yes, I, er, ran into a private caching issue...*cough*.
Comment 7 Dan Jacobson 2007-06-12 02:48:03 UTC
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?
Comment 8 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-06-12 23:17:51 UTC
Oh dear.  You're correct, quite sorry.  It's hiding it via CSS.  Let me see about fixing that.
Comment 9 Platonides 2007-06-13 14:00:02 UTC
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> ?
Comment 10 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-06-13 18:25:04 UTC
Oh, hmm.  I see the point, yes.
Comment 11 Dan Jacobson 2007-06-13 23:29:07 UTC
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.
Comment 12 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-06-14 01:27:42 UTC
(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.
Comment 13 Dan Jacobson 2007-06-14 23:47:01 UTC
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!


Comment 14 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-06-14 23:55:31 UTC
(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.
Comment 15 Dan Jacobson 2009-03-30 00:53:54 UTC
Today I'm adding the accessibility tag to several bugs... though not checking the details, stylesheets are for style. Content should be via HTML..
Comment 16 Antoine "hashar" Musso (WMF) 2010-10-28 19:06:52 UTC
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.
Comment 17 Dan Jacobson 2010-11-11 00:11:15 UTC
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.
Comment 18 Max Semenik 2010-11-14 08:10:10 UTC
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.
Comment 19 Antoine "hashar" Musso (WMF) 2010-11-14 10:51:56 UTC
Following Aryeh, Platonides & Max Semenik, I am now closing this bug report as WONTFIX.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links