https://bugzilla.wikimedia.org/show_bug.cgi?id=671
--- Comment #49 from Aryeh Gregor <[email protected]> 2010-07-25 18:39:44 UTC --- Sigh. Okay, frankly, I wasn't really so much against whitelisting these, and I was mostly just responding to particular arguments that I thought were unreasonable, and to some degree playing devil's advocate. In my view, the issue basically boils down to this: Argument in favor of whitelisting: They're not very useful, but they're practically the only HTML elements we don't whitelist, and it won't hurt anything. We already whitelist similarly marginal elements like <var> and <abbr>. So what's the point in not whitelisting these? Counter-argument: Wikitext is not meant to be HTML. It's meant to be a simplified language that non-technical users can easily learn, without unnecessary features that might be confusing. We don't have to allow everything that HTML does -- wikitext serves a different purpose from HTML, and it's completely reasonable for us to draw the line at a different place. Since wikitext aims to be simplified, any new language construct needs to be concretely justified. Counter-counter-argument: So it's okay to allow <span style="position:absolute; top: 2.8em; right:0em; height: 1em; width: 12em; background: red; border: 2px solid gray; color: white">, but <kbd> is too confusing? Not to mention the fact that we have template syntax which causes grown men to break down into uncontrollable sobbing, and on several well-documented occasions has caused onlookers to spontaneously gouge their eyes out in sheer horror. But <kbd>, oh no, that's just way too complicated. Especially what with how <var> and <abbr> have been whitelisted for a long time, and they've demonstrably caused the total collapse of the Wikipedia user base as we know it, what with everyone using them all over the place. Come on, get real. Counter-counter-counter-argument: . . . :( Phrased thus, I can see no serious argument for not whitelisting these tags. It makes things more consistent if anything. I'll get some other developers' opinions, and if no one objects, I'll go ahead and whitelist <address> and <dfn>. As for <kbd> and <samp>, we may as well wait until that HTML5 bug is resolved, which should be within a few months. This has waited 5.5 years, so a few months more won't kill anyone. I'll just respond to one or two points here: (In reply to comment #45) > HTML5 goes flip-flop about this. The version I have in memory cache says > quotation marks should be explicit inside Q. The current version says the opposite, and I think it has for a long time: http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-q-element (In reply to comment #47) > 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). The way the HTML5 bug tracker works is that everyone is free to comment, but the editor (Ian Hickson, a.k.a. Hixie) has the sole right to make a decision. Hixie normally handles bugs in batches every few months, so I expect he'll decide within a few months. When Hixie makes a decision, it can be appealed to the HTMLWG, which can take like a year, but most of his decisions are not appealed (and I certainly would not appeal whatever decision he makes here). So the people who have commented so far on the HTML5 bug are irrelevant (since it's Hixie's decision alone at this point), but it will be resolved definitively sooner or later. If he WONTFIXes, can add the elements at that point, if the developers agree on that now. > 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. That's fine, but then you should not have claimed that these things are "certain" or "nearly certain", since you have no actual evidence. I don't ask for you to invest any effort at all in testing anything, but I do ask that you accurately represent how well-supported your statements are. Note that JAWS has a trial version, so I managed to test it out in like ten minutes; and there are open-source screen readers too (see bug 15491 comment 4). > 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. Actually, it's mostly due to Brion WONTFIXing it, as lead developer. Since he's no longer lead developer, it became possible to revisit it in the last year or so. No developer seems to really care about it, but I defended Brion's position somewhat half-heartedly and got drawn into a giant argument about it, which I continued for a while mainly because I tend to argue pointlessly about details rather than ignoring the stuff that's irrelevant to the conclusion, so I attacked weak arguments in favor of fixing the bug rather than ignoring them and focusing on the strong arguments. Anyway, that's over now. > 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. My proposal there doesn't affect <address>. > 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. It doesn't really matter, but you're not supposed to remove blocking/dependencies once they're fixed. They're supposed to stay there. -- 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 [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
