Last modified: 2011-02-08 21:57:19 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 T28266, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 26266 - Add .allpagesredirect, .redirect-in-category to standard CSS
Add .allpagesredirect, .redirect-in-category to standard CSS
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Redirects (Other open bugs)
1.17.x
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
http://lists.wikimedia.org/pipermail/...
: accessibility
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-12-06 12:22 UTC by Dan Jacobson
Modified: 2011-02-08 21:57 UTC (History)
3 users (show)

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


Attachments

Description Dan Jacobson 2010-12-06 12:22:48 UTC
Why in the world isn't the .allpagesredirect, .redirect-in-category
stuff mentioned in the above URL part of the standard CSS?

Why must administrators have to add it for their own wiki?

If there are some cases where it causes problems then they must be the
minority, and those administrators can customize it back out.

Searching for allpagesredirect and redirect-in-category here in
bugzilla shows many reports... Too many to add to depends/blocks today for me. Now most of the work that those reports requested is done except for
the very last piece, adding them to the standard distribution stylesheets,
please!

Why is it good for Wikimedia but not for Mediawiki?

Are there other cases like this where something was implemented for Wikipedia/Wikimedia, then forgotten about for Mediawiki?

By the way, as mentioned in a second article,
http://lists.wikimedia.org/pipermail/mediawiki-l/2010-December/036064.html ,
Why isn't this implemented with <em> so it works in text browsers too?
Why is accessibility usually respected but not here? Thanks.
Comment 1 Ilmari Karonen 2010-12-11 16:46:11 UTC
Using <em> doesn't really seem semantically appropriate: we don't want to _emphasize_ those redirects; if anything, we want to make them easier to gloss over.  Using <i> would be better, since it at least doesn't come with inappropriate semantic baggage.  (That's the same reason we use <i> instead of <em> for ''italics'': the parser can't know if the editor meant the italics to signify emphasis or something else.)

I suspect the reason allpagesredirect was originally made into an unstyled span was to avoid complaints from users about an unexpected interface change.  Certainly that was one reason I did the same when I later added redirect-in-category (although mostly I was just following precedent).  In some ways, that's [[Parkinson's Law of Triviality]] at work: rewrite an interface completely, and people will shrug and adapt to it, but if you just change a tiny detail like italicizing some links, many folks will go "Hey, we had it looking just right before, why did you have to mess it up?!?"
Comment 2 Dan Jacobson 2010-12-12 01:47:23 UTC
Yes, please use <i>. I will pull via SVN the minute I hear you have made this change. Thanks.

As for all the others out there, I will try and do something about them via this thread http://lists.wikimedia.org/pipermail/wikitech-l/2010-December/050618.html .
Comment 3 Dan Jacobson 2010-12-15 01:31:04 UTC
Can this (<i>) be implemented soon? Taiwan counties are being merged on 2010/12/25 causing a ton of redirects for me, and I would like to avoid just fixing it for myself, to be later forgotten for the rest of the MediaWiki community. Should I post in wikitech-l to see if there are any objections?
Comment 4 Krinkle 2010-12-22 03:02:47 UTC
I object!

Please just add the css-line to the standard styles (be it common or skin-specific css) in SVN.
That way scripts looking for spans with that class won't brake and everything stays in sync.

CSS classes are made exactly for that reason, right ? To use them.
The classes are already implemented, so we only have to add a single line to the default MediaWiki styling (as has been done before for certain styles that make sense by default)
Comment 5 Dan Jacobson 2010-12-22 03:12:56 UTC
Why can't you make it work for both text and non-text browsers, like MediaWiki already does here:

<div class="mw-specialpages-notes">
<hr />
<ul><li> Normal special pages.
</li><li> <strong class="mw-specialpagerestricted">Restricted special pages.
Comment 6 Krinkle 2010-12-22 03:20:05 UTC
imho
* because using <em> or <strong> has a special meaning which we dont intend to trigger and <i> is going towards deprecation because CSS should be used.
* because replacing markup causees a selector like $(context).find("span.allpagesredirect") or CSS "span.allpagesredirect { color:green }" will no longer work if the element gets a different tagname.
* because using CSS is what Wikipedia has done for years and what people are copying to their websites.

And about text/non-text browsers... can you elaborate on that ? I'm now sure I follow, MediaWiki currently supports down to IE6. Anything older is not fully supported and failure or degration will occur in places.
Comment 7 Dan Jacobson 2010-12-22 03:29:55 UTC
All I can say is there are a lot of us
http://www.google.com/search?q=text+browser
users out there and we're not going away.

If <em> is bad, then use <i>. If <i> is not allowed, then remove it
forthwith from all MediaWiki code, and don't talk about accessibility
anymore during funding drives, etc.
Comment 8 Krinkle 2010-12-22 03:31:05 UTC
I refuse to take part of this discussion again. 
Have a nice day.
Comment 9 Dan Jacobson 2010-12-22 03:33:45 UTC
That is unfortunate.
Use any tag you like, just make sure it is HTML, not just CSS.
Comment 10 Dan Jacobson 2010-12-24 13:59:16 UTC
How about <DEL>?

Ilmari, mail does not get to you.
Comment 11 Krinkle 2010-12-24 15:08:35 UTC
Default styling added to the CSS in r78964 (as the bug requested).

If you think the HTML markup should be changed, please open a seperate bug.
The issue raised in the mailinglist thread is fixed.
Comment 12 Dan Jacobson 2010-12-24 15:44:50 UTC
OK, I added Bug 26415. Thanks.

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


Navigation
Links