https://bugzilla.wikimedia.org/show_bug.cgi?id=671
S. McCandlish <smccandl...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks| |19719
--- Comment #47 from S. McCandlish <smccandl...@gmail.com> 2010-07-24 23:31:20
UTC ---
Another long one, since there are so many things to cover. This time I've
broken into into clear sub-topics. I'm also proposing this be split into
multiple bugs.
* On the dfn element:
Summary: Aryeh appears to have removed his (and, I note, the *only* extant)
objection to implementing dfn.
--- Comment #43 from Aryeh Gregor <simetrical+wikib...@gmail.com> 2010-07-22
17:24:10 UTC (In reply to comment #41) ---
> Maybe we should allow it even if it's only useful in theory, but if there
> were real-world uses (i.e., non-hypothetical) then I'd certainly be fine
> with adding it
Yay! This argument is over then, since I've already satisfied your conditions
by providing examples of such uses. Ergo:
*************************************************************
* I move that the dfn element be whitelisted immediately. *
*************************************************************
--- Comment #43 from Aryeh Gregor <simetrical+wikib...@gmail.com> 2010-07-22
17:24:10 UTC (In reply to comment #41) ---
> So what you're saying is that theoretically someone somewhere might be able to
> derive some benefit from this, but you don't have specific examples of people
> who *will* benefit from it? Like who have said they want it and will use it
> for some specific constructive purpose if it's available?
No, that's not what I'm saying. To repeat myself and my specific examples that
have been ignored: Every vision-impaired user with a screen reader
(text-to-speech) browser can benefit from this, since they can customize their
browser-internal style sheet to distinguish between defining instances of a
term (on WP, this would usually be the bold intro in the lead, and often the
lead-in terms in sections, in complex articles) and misc. stuff that is
boldfaced or sectioned for any number of other reasons. Once the code works,
WP:MOS and WP:LEAD can be updated, and it will propagate rapidly. And, any
author of software that works with MW wikicode would be able to use dfn for
various purposes. So, I obviously have already given specific use cases for it
on WP in particular, both in glossaries and in the more general "defining
instance" case. (Referring to these as "theoretical" and demanding a
"non-hypothetical" example of *something that cannot be implemented because MW
has disabled it* is just cognitively dissonant.) See also Michael's salient
comments on this in Comment #44.
Nothing at all remains in the way of whitelisting kbd, not even dependencies
(as was the case for a while with the abbr element).
* On this bug and its confusing resolution-thwarting mixture of different
issues:
Bug #671 should become a tracking bug, with dfn, q, address, and kbd+samp being
4 separate bugs listed as its blockers. The reasons for and against each tag
are largely different (treating kbd and samp as a linked pair).
* On HTML5's deprecation of the tt element (off-topic now):
Moved to new Bug #24529.
* On the idea of applying dfn with a template to the boldfaced term at the top
of an article's lead (e.g. "{{leadterm|elektrokardiogram}}"):
--- Comment #45 from Christopher Yeleighton <giecr...@stegny.2a.pl> 2010-07-22
19:33:30 UTC (In reply to comment #41) ---
> I would rather say [[{subst:PAGENAME}]] and leave inserting the DFN tags to
> the engine. (I admit I have changed my position on this subject.)
I don't follow you. Where would this link appear (presumably with correct
double squiggly bracketing) and why? If you mean to suggest that PAGENAME can
be used in the lead, that won't actually work in hundreds of thousands of cases
because of disambiguation and because (especially in bio articles, e.g. [[Newt
Gingrich]]) the article title and the subject of the article as given in the
lead often do not match even when the article title is not disambiguated. But
I may be misunderstanding what your suggestion is. My point was that dfn is
explicitly intended for defining instances of a term/name like the bold intros
to leads in WP articles. I cannot see a way to automate is application there,
so it would have to be done manually or via a template (and if done manually,
someone would make a template for it immediately anyway, since doing it
manually would be tedious).
*On the address element:
"I don't see why" isn't a valid rationale against implementing this, and no
defensible rationale has been given for not doing so, while examples of its
usefulness have been given, both on and off WP.
--- Comment #43 from Aryeh Gregor <simetrical+wikib...@gmail.com> 2010-07-22
17:24:10 UTC (In reply to comment #41) ---
> [Non-open wiki operators] can ask for it to be optionally (non-default)
> whitelisted. It makes no sense in normal wiki pages, though, and should
> not be allowed by default.
Michael Zajac nailed this one completely in Comment #44.
If there's any further argument, break it into a separate bug, since objections
to this element are unrelated to anything else under discussion here.
--- Comment #46 from Christopher Yeleighton 2010-07-22 20:48:22 UTC (In reply
to comment #44) ---
>> Off the top of my head, an address element could be appropriate in the
>> following places:
>> * In the page footer, for the Wikimedia button.
>
> This case does not need white-listing.
Surely. But the rest do, especially on non-WMF wikis, although Michael provides
some on-WP examples, too.
* On the kbd and samp elements:
"I don't see why" isn't a valid rationale against implementing this, and no
strong rationale has been given for not doing so, even if Aryeh's activism at
HTML5's bugzilla is causing a delay.
We can concede that implementation of the kbd and samp pair is also temporarily
problematic because of alleged uncertainty over at HTML5, and should thus
arguably be deferred in MW for the short term. Personally, I'm near certain
that Aryeh's HTML5 proposal won't succeed, because HTML5 has been moving toward
significantly increased, not reduced, semantic tagging, and in 5 weeks it's met
nothing but skepticism. Three (i.e., less than two more) months is probably
enough time to see which way that wind blows).
--- Comment #43 from Aryeh Gregor <simetrical+wikib...@gmail.com> 2010-07-22
17:24:10 UTC (In reply to comment #41) ---
> I'd like to see specific examples of screen readers or power-users'
> stylesheets that do not treat these the same as <code> or <tt>, since you
> say these are near certain or absolutely certain.
I'd like to have a new Lexus and to be 15 years younger.
I'm not going to spend hundreds and hundreds of real dollars buying expensive
software to satisfy your nitpicking, especially since you seem so adamantly
opposed to this (alone among *all* active respondents on this thread, I might
add) that I doubt you'd be satisfied anyway.
I'm also not going to spam around asking for blind users to send me copies of
their style sheets, for the same reason, and because interpreting them would be
necessarily subjective and extremely time-consuming, and because I have more
productive things to do, and so do they, and surely so do you.
Let's not waste any more time here. It's basic logic: All non-crap modern
browsers, including good screen readers, provide for local stylesheets (they
override remote ones and browser defaults, as I'm sure you're aware). Given
that, we can be 100% certain that some users actually use this feature, or it
wouldn't be there (I think I first saw this feature around 1996 in Netscape, so
that's 14 years in which to get rid of it if it were simply creeping
featuritis). Given this and the fact that (go ask any accessibility forum) a
major thorn in the collective side of visually impaired users is
distinguishability of types of content, and you have a 100% certainty that some
visually impaired readers use this feature to distinguish between various
different types of content that are often poorly distinguished. Q.E.D.
If there's any further argument about these, after the moribund discussion over
at HTML5 peters out, kbd+samp should become its own bug, since the objections
to the one are identical to the other, but not even related to objections
(where any still exist) to dfn, address or q. The new bug should be labeled
LATER, but only temporarily.
* On the q element
It isn't on the table right now; it's implementation really is being held up by
uncertainty at the specs level and by grossly inconsistent user agent
implementation.
It should be its own bug, marked LATER until the situation stabilizes.
--- Comment #45 from Christopher Yeleighton <giecr...@stegny.2a.pl> 2010-07-22
19:33:30 UTC (In reply to comment #41) ---
> HTML5 goes flip-flop about this. The version I have in memory cache says
> quotation marks should be explicit inside Q.
Yeah, that's obviously the sanest solution, but until it's stable I have to
agree with Aryeh that we shouldn't implement it here because it could just end
up having to be undone, or redone, with repercussions for millions of live
pages on thousands of wikis.
* On Wikipedia-centric assumptions:
What is or isn't useful on Wikipedia itself isn't really of any concern here,
since this is open software. MediaWiki is much broader than Wikipedia, and
than WMF projects. Much of this bug's extreme lack of progress (I mean, really
- this is **bug number 671**!) is directly traceable to treating this as if it
were a *Wikipedia* feature request, rather than MediaWiki one. There is no such
thing as "abusing" MW as a CMS. It's a platform for collaborative and easy
editing of content, and that obviously *is* a CMS, whatever else you want to
call it and whatever technologies it uses, to whatever ends. Any legal use that
users wish to put it to for editing and presenting content is perfectly valid.
Michael Zajac's Comment #44 addressed some of this, too. But there's also this
point:
--- Comment #43 from Aryeh Gregor <simetrical+wikib...@gmail.com> 2010-07-22
17:24:10 UTC (In reply to comment #41) ---
> Since wiki pages are, by their nature, not owned by anyone or authored by
> any single person, [address] makes no sense for wikis.
Not every wiki is publicly editable by the entire world. Some have very tightly
controlled editorship (e.g. 3 people, with some pages "owned" by specific
individuals).
* On using angle brackets in Bugzilla messages (off-topic):
--- Comment #43 here from Aryeh Gregor <simetrical+wikib...@gmail.com>
2010-07-22 17:24:10 UTC (In reply to comment #41) ---
> If your mail client touches angle brackets in plaintext e-mails, it is
> absolutely and completely broken and you need to tell it to stop.
yet:
--- Comment #4 on Bug #23932 from Aryeh Gregor <simetrical+wikib...@gmail.com>
2010-07-22 15:52:51 UTC ---
> ... we only kowtow to [obsolete versions of MSIE] until they're not used by
> a significant number of people.
These are contradictory stances. In the case I reported, the GMail app built
into the Android operating system, for one, "eats" material in angle brackets.
It is certainly "used by a significant number of people". If "fix the broken
application; we will not adapt" is good enough for the Droid goose, it's good
enough for the IE gander. I've developed this argument a bit more at Bug
#23932, where it's more relevant.
> Surely you're not saying I should write my Bugzilla posts to work around
> broken tools that don't obey standards? 0:)
That's precisely what I'm saying, if you insist on forcing all editors on every
MW-based wiki to write all their content and markup around old, buggy versions
of MSIE. You can't have it both ways. If we stop kissing IE's buggy but, then
I recind any plea for being nice to Droid users. But, as I said, this issue is
better discussed at Bug #23932, which is all about supporting Microsoft
zombieware.
* On 671's dependencies:
I'm adding the HTML5 tracking Bug #19719 to "blocks", since dfn is a stable
part of HTML5, and kbd, samp and address will almost certainly be, Aryeh's
proposal over there notwithstanding. The abbr element has already been
whitelisted, so I'm removing Bug #8633 as a "blocks" dependency. Since Bug
#22905 has been fixed, removing it as a "depends on" dependency.
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
