- From: Ian Hickson <ian@hixie.ch>
- Date: Sat, 11 Jul 2009 23:38:01 +0000 (UTC)
- To: Sam Ruby <rubys@intertwingly.net>
- Cc: HTMLWG WG <public-html@w3.org>
On Sat, 11 Jul 2009, Sam Ruby wrote: > > Ian also took the opportunity to provide some insight[4] into his > decision making process. In doing so, he created an impression that he > did so as Apple exercised a unilateral veto. I believe that such an > impression is unfortunate, counter-productive, and not in line with my > understanding of either W3C or WHATWG processes. In particular, I > actually believe that the accepted goal of the WHATWG was two complete > and bug-free implementations in 2022. I do not believe that Apple's > participation is required to meet that goal. In particular, I believe > that there are at least three implementations today which could form the > basis for meeting that goal, with required codecs, namely the browsers > produced by Mozilla, Google, and Opera. Nor do I believe that Ian has > talked to anybody who can say with absolute certainty what Apple will or > will not support by 2022, as I don't believe that such a person exists. It's true that we could decide Safari is a lost cause and that the spec won't describe what Safari does. When Mozilla says they won't implement some other feature that has majority agreement, then we'd also call them a lost cause, because it would be unfair to give Mozilla veto power when we didn't give it to Apple. And then we would have to decide that Chrome should be a lost cause when they decide that they can disagree with features in the spec without repercussions since everyone else is doing it, and then when Microsoft say they're not going to implement the parser section, we'll still be fine, because Opera would still be implementing everything, and after all we only need two implementations to pass to REC, and I'm sure we could find another... Lynx, maybe? Of course by this point the spec would have no relationship to reality whatsoever, but that's fine, because the goal is to go to REC, not match reality, right? Sarcasm aside, when I say that implementors have a veto, I'm not saying this is part of the W3C or WHATWG process. It's not. The processes don't claim that anyone has a veto, because claiming that would be politically inconvenient, as is clear from recent discussions. But that's academic. They have the veto whether we like it or not. It's not granted to them by the standards organisations; it's not that I want to give them power over the spec; it's just that as a simple matter of practicality, the implementors decide whether or not they implement the spec, and if they don't, then the spec is wrong. This isn't just browser vendors -- conformance checker implementors have the ultimate word on what is conforming, ATs have the ultimate word on what bolt-on accessibility features work (witness HTML4 and axis="" or scope=""), editors have the ultimate word on editor-related conformance requirements (e.g. our "SHOULD default to UTF-8"). There's two costs to ignoring implementors - one is that it takes the spec further from reality, and the other is that it loses the respect of the implementors, which can in turn mean they go even further from the spec. An extreme example of the latter is XHTML2. The working group didn't take into account that implementors would have to implement their work, and so the browser vendors ignored it. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Saturday, 11 July 2009 23:38:39 UTC