Last modified: 2011-10-14 22:06:04 UTC
Please change everybody's [ ] Show hidden categories to [*] Hide hidden categories (CSS) Reason: this is the only browser independent solution. Otherwise you assume nobody uses text browsers, whose users scratch their head and wonder why they still see the hidden categories. Also just like you say JavaScript in [ ] Edit pages on double click (JavaScript) you should say CSS here. Actually you should say "requires CSS" etc. (I would say to also link [[CSS]] but most wikis don't have a [[CSS]] article.) Anyway, I bet there are lots of such preferences that assume everybody uses IE or Firefox and don't mention their requirements that exceed HTML.
There is no reason why a text browser could not support CSS, at least partially. I'm not sure we want to bother the majority of users with details they don't care about. There could perhaps be a message shown only to users that don't have CSS enabled.
The text browsers (and search engine spiders) I know of don't support CSS, and one often turns it off in browsers that do if one doesn't want the visual clutter or extra traffic. Yes, please make the words "(CSS)" disappear only when you CSS users browse Preferences, or else other folks using various devices or screen readers will think something is broken.
Allow me to redefine this bug. Styleshees are for changing style. Here you are making _information_ depend on stylesheets. That is crossing the boundary and a clear violation of accessibility principles. The hidden categories should appear, or _disappear_, from the HTML, not via the sytlesheet! Sure, you could say most users don't need accessibility, but why throw it away for nothing?
How is accessibility relevant in this case when all information is there and accessible?
But you are unfair to text browser users: there is no way for them to turn them off! That's right, the so-called Hidden Categories will never be hidden for text browser users! Personally I like seeing the Hidden Categories here in my text browser, and often read via unlogged-in WWWOFFLE, etc. So maybe only have the hidden categories disappear if the user is logged in and has hiding turned on (default=hide) in preferences. I.e., the question is should unlogged in programs like search engines see them? Currently the answer is yes and probably should stay so. And remember stylesheets are for style, not for content, and here we are very much talking about content, and we text browser users and search engines don't know what you are hiding...
Doing it by any means other than CSS would cause unnecessary cache fragmentation, concerns for which far outweigh accessibility, as they affect a tiny minority of users.
I don't get it: if they are logged in you already say "Bob's contributions", "Bob's user page" etc. custom stuff. Well, you can also _not_ say the Hidden Category stuff in the HTML you send, if that's what they have checked in preferences, which of course should be the default for that preference.
(In reply to comment #7) > I don't get it: if they are logged in you already say "Bob's > contributions", "Bob's user page" etc. custom stuff. > Well, you can also _not_ say the Hidden Category stuff in the HTML you > send, if that's what they have checked in preferences, which of course > should be the default for that preference. > Because the HTML generated from wikitext is pulled from cache, not the entire HTML page. Also, decent text browsers should understand basic CSS along the lines of display: none; . I believe Lynx does.
> Because the HTML generated from wikitext is pulled from cache, not the entire > HTML page. So then when you build the cache, instead of just throwing the hidden categories into the same element as the rest, just put them into a separate element, and then when the time comes you can easily just not use that second element if not desired. Or something like that. > Also, decent text browsers should understand basic CSS along the lines of > display: none; . I believe Lynx does. $ lynx -dump -nolist http://en.wikipedia.org/wiki/Phoridae | grep Hidden Hidden categories: All articles with unsourced statements | Articles Thinking you can change _content_ via _style_sheets is misguided. There is no boundary in you guys' minds where content ends, and style begins. Are you trying to hide the text from people, but show it to searchengines?
The good thing about using CSS rather than HTML to hide items is that if the user changes their preferences, then even pages in the browser cache will reflect that change immediately. What is the problem here? Just change [ ] Show hidden categories to [*] Hide hidden categories (requires CSS) in the preferences page. The words "hidden categories" on the preferences page, and the words "Hidden category" or "Hidden categories" on pages that are members of hidden categories, can be made into links that point to an explanation of hidden categories.
> Just change... Just like in comment #1, but better.
Did I say comment #1? I meant comment #0.
It gracefully degrades in text-only browsers. It is accessible. Very large portions of mediawiki (inc. other preferences) depend on CSS in order to work properly. The right 'fix' is to document that mediawiki depends on CSS, but degrades gracefully in most cases. A report bugs where it does degrade badly.
Bug seams to have been closed hastily without an understanding of the issue. We do rely on css to hide the hidden categories, but this is not documented in the prefs. So we 'should' either add that info to prefs or 'fix' the issue. I don't particularly see a reason to put categories that are hidden in the markup when we're just going to hide them: - catlinks is generated by the skin not from cache, anons all have the same prefs, and users aren't targeted by squid caches, so catlinks should be in a spot where we don't have an issue with server caches. - Search engines generally don't need to see hidden categories. They generally have other ways to find things on the wiki. Tbh, categories are generally hidden because there is no need for people to be browsing them, likewise search engines don't need to bother. We shouldn't be basing whether we insert parts of the ui based on what search engines need anyways. - Brian's comment on browser caches doesn't really matter. If that's relevant then there are likely other preferences we have which will be affected the same way which we don't do css for so that's nothing new. Anyways such an issue would be fixed when we deal with bug 31639 since a user_touched based ETag would change when a user changes their preferences thus invalidating their caches and making them see the new ui.
