Page MenuHomePhabricator

add <I> to AllPages redirects
Closed, DeclinedPublic

Description

Thank you for fixing Bug 26266.
One indeed can now distinguish redirects on AllPages finally...
(But only if one has good eyes, see the above URL.)
However for text browser accessibility, one still needs an HTML tag.
(Just like you implement <strong class="mw-specialpagerestricted"> as a paired CSS and HTML solution.)
So I propose <DEL> to be added to the Bug 26266 fixes. Thanks.


Version: 1.18.x
Severity: normal
URL: http://radioscanningtw.jidanni.org/index.php?title=%E7%89%B9%E6%AE%8A:%E6%89%80%E6%9C%89%E9%A0%81%E9%9D%A2

Details

Reference
bz26415

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 21 2014, 11:15 PM
bzimport set Reference to bz26415.
bzimport added a subscriber: Unknown Object (MLST).

In Mozilla/5.0 (X11; Linux i686; rv:2.0b8) Gecko/20101219 Firefox/4.0b8 Iceweasel/4.0b8 the slanted text is minimally visually detectible.

In Midori 0.2.7 GTK+ 2.20.1, WebKitGTK+ 1.2.3 there is no difference to the two fonts.

I'm not saying that we should chase down each browser's peculiarities, I'm just saying adding an additional <DEL> would fix it for even text browsers too.

<del> means "deleted" not "this is a (perfectly valid) redirect"

How about <I> as mentioned in Bug 26266.

By the way, I see bugzilla uses a <del> type style for the above closed bug. My point is with only a handful of tags to choose from, there is no way one can always find the perfect match.

happy.melon.wiki wrote:

(In reply to comment #4)

By the way, I see bugzilla uses a <del> type style for the above closed bug.

The fact that bugzilla is arguably wrong doesn't mean we should follow them in being unquestionably wrong. A redirect is a perfectly valid page which happens to have a special property; it is not "deleted" therefore it should not be marked as deleted (arguably, the <del> tag would be more appropriate for redlinks). You've basically decided that you want the redirects to stand out in some fashion, and are now cherry-picking the tag that you think will stand out the most without consideration for what that emphasis is supposed to *mean*. If adding italics is not a visible change for the given font or browser, that is a problem with that font or browser, not for us.

OK, how about <I>?
(In reply to comment #5)

consideration for what that emphasis is supposed to mean

OK, as Ilmari Karonen said in Bug 26266#c1 , use <I> not <EM>.

If adding italics is not a visible change for the given font or
browser, that is a problem with that font or browser, not for us.

OK, I'll accept italics. Now please send <I>s, as in fact it is much harder for a WikiSysop to customize that in than it is to just change Mediawiki:Common.css .

Proof <I> is good:
Bug #24529 Comment #0, quoting
Bug #671 Comment #27 :

meanwhile, <i>/'' and <b>/''' should be
left alone, as HTML 5 redefines them more narrowly and they will continue to be
used).

http://www.w3.org/TR/html5/text-level-semantics.html#the-i-element

Also note Bug 369, where <em> was changed to <i>.

(In reply to comment #7)

Also note Bug 369, where <em> was changed to <i>.

That was done because <em> has the semantic meaning of emphasizing part of a sentence which is not always the intention when using '' in Wikitext. There could be any reason for it, thus it has been changed for the neutral (semantically meaningless) <I>

Making them <I> instead of <span> will have:

  • No visual change
  • No change in pronouncement by text readers
  • No difference in semantic meaning

All it does it changing markup for no reason.

It also has a downside, since it will cause problems for wiki sysops that have
copied older CSS from other wikis that defined the style like
span.allpagesredirect { font-style:italic; color:green; }.

They are italized already with CSS, hence bug 26266 is fixed.
Marking as WONTFIX.

It also has a downside, since it will cause problems for wiki sysops that have
copied older CSS from other wikis that defined the style like
span.allpagesredirect { font-style:italic; color:green; }.

Private CSS can be reduced in the future by MediaWiki supplying
default CSS at the same time it supplies the classes, as mentioned in
Bug #26266 Comment #0.

What I don't understand is why does Mediawiki implement "''" purely in
HTML (<i>), with no CSS involved, but it implements our
allpagesredirect item we are talking about here purely in CSS with no
HTML involved.

It should then be safe to remove all <i> from Mediawiki and replace
them with pure CSS. Same with <em>, <strong>, etc.

If for _some reason_ that is undesirable, then for that _same reason_
why can't
<div class="allpagesredirect">...</div> be please changed to
<i class="allpagesredirect">...</i>, or
<div class="allpagesredirect"><i>...</i></div>, or
<i><div class="allpagesredirect">...</div></i>?

Just like Mediawiki sends the combined HTML and CSS
<strong class="mw-specialpagerestricted">.
Why did they eventually add that <strong> there, but are refusing to
add an <i> here, but at the same time not removing all HTML tags wholesale?

happy.melon.wiki wrote:

(In reply to comment #11)

What I don't understand is why does Mediawiki implement "''" purely in
HTML (<i>), with no CSS involved, but it implements our
allpagesredirect item we are talking about here purely in CSS with no
HTML involved.

It should then be safe to remove all <i> from Mediawiki and replace
them with pure CSS. Same with <em>, <strong>, etc.

If for _some reason_ that is undesirable, then for that _same reason_
why can't
<div class="allpagesredirect">...</div> be please changed to
<i class="allpagesredirect">...</i>, or
<div class="allpagesredirect"><i>...</i></div>, or
<i><div class="allpagesredirect">...</div></i>?

Just like Mediawiki sends the combined HTML and CSS
<strong class="mw-specialpagerestricted">.
Why did they eventually add that <strong> there, but are refusing to
add an <i> here, but at the same time not removing all HTML tags wholesale?

When an editor adds double apostrophes into a piece of wikitext, they are saying "make this piece of text italic". That is what the double apostrophes *mean*. The <i> tag is special in the sense that *all* UAs are *required* to display its contents in italics, which is obviously the correct thing to do to a piece of text for which someone has said "make this piece of text italic".

What all your comments above are not understanding is that most people Just Don't Agree (TM) that redirects on Special:Allpages unquestionably *should* always be in italics. Some wikis have decided that it's a good idea, and implemented it with CSS using the classes that we agree it is beneficial to provide. You have yourself explained that italics is sometimes *not* the best way to highlight text, especially in certain character sets; it may be that bold, or underline, or a different colour, would be a better way of distinguishing them. All of which can be provided by a wiki very easily in their own CSS. You are saying that we should be taking that flexibility *away* from wikis, and forcing them to have the redirects in italics whether they want them or not. That is not a progressive change.

They can easily turn it back off with
.allpagesredirect{font-style:normal}
while text browser users on the other hand have no way of turning <i>
on for themselves. We had this same argument getting
mw-specialpagerestricted to finally carry an additional <strong> tag,
instead of the simple plain initial CSS implementation. Why is this
case different?

You know some of us use lynx when we don't want to see the stupid stylistic crap...

If you want to see styles, use a browser that supports css. If you want to use a text browser, and see the stylistic crap, use a text browser that supports css (yes they exist). If you want to use lynx, use lynx, but don't complain that it works as designed.

No I don't use lynx, and I don't want to see styles. We are facing a
page full of links, half of them redirects, and cannot tell which
ones, because you won't put the <i> there, even though your style for
it is italic anyway. You put <strong> on mw-specialpagerestricted but you won't put <i> on allpagesredirect. Why? What does "web accessibility" mean?

(In reply to comment #12)

All of which can be provided by a wiki very easily in
their own CSS. You are saying that we should be taking that flexibility *away*
from wikis, and forcing them to have the redirects in italics whether they want
them or not. That is not a progressive change.

But can't they just overpower it back in MediaWiki:Common.css as I have shown in Bug 26519 Comment 6 ?

happy.melon.wiki wrote:

(In reply to comment #15)

because you won't put the <i> there, even though your style for
it is italic anyway.

Ok, serious WTF. Italics is not "our style"; MediaWiki does not have 'a' style. It has a *default* style, and wikis can use what they think is appropriate and change what they think is not. We have implemented italics as the default style for redirects entirely because you browbeat everyone into submission on bug 26266; you've said *yourself* that it is not universally suitable. Why on earth would we want to lock in a style which is not accessible in an entire character set?

(In reply to comment #16)

But can't they just overpower it back in MediaWiki:Common.css as I have shown
in Bug 26519 Comment 6 ?

Your entire argument in this bug report is that this is precisely what users of text browsers *cannot* do. Which is it? You can't have your cake and eat it; users cannot be flexible when they want to do something different to you, but uncompromising when they want to do what you want.

(In reply to comment #17)
Maybe I should give up the ghost as nobody seems to remember what those
HTML tags were originally for.

And even if you were to implement it for me, the next guy probably would
just come along a little later and like the funny videos below, and
Bug 26442, chuck it back out.

E.g., Facebook just says 'Sorry, we're not cool enough to support your
browser. Please keep it real with one of the following browsers...'

They do seem to have a m.facebook.com site that does work with text
browsers though.

Maybe if I put an 'm' in front of my wiki's URL, it will too. Ha ha.

Anyway, I was just thinking if there was <i>s, then on
http://radioscanningtw.jidanni.org/index.php?title=Special:Allpages
even text browsers could see which links were redirects.

You might say "if I give you that, next thing you'll be asking for is
some HTML tag for redlinks!"

Well, no. I can move the cursor upon a link and see where it will go
before clicking it, thus able to tell if a link is a redlink by its URL.

But I can't do that for redirects. They all look the same as normal
links URL-wise. I would have to look at the HTML page source to tell.

And if you put the <i>s in the code, with powerful CSS, anybody can
"take them right back out" for themselves.

However, if you don't put them in, then the text user has nothing to
grasp on. No way to stick them in himself.

I think accessibility would also allow a "whole range of future super
slim devices" to use MediaWiki, without having to implement sytlesheets.

Anyway, it seems that I should just keep my text browser habit to myself
these days. I'm even too embarrassed to say which one I use.

*"Stale old stuff" http://www.youtube.com/watch?v=VM3QqTcM55k
*"Can't even pronounce this one" http://www.youtube.com/watch?v=M6a0OPefhi0