Re: formal objection to one vendor/one vote

I don't think that taking a stand is ignoring implementors, the first and
foremost important thing to do for the Working Group is creating a
specification that is good for the Web, not for the business model of one
implementor. Interoperabilty and the fact that anyone (who has the technical
ability) can implement the complete spec is of importance to keep the Web
open.

It can take time to convince an implementor to do the *right* thing for the
openness of the Web. But if Microsoft can be moved to implement CSS 2.1,
than so can Apple to implement theora. We just have to be persistent.

The same goes for various accessibility requirements.

Benoit Piette

2009/7/11 Ian Hickson <ian@hixie.ch>

> 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.   `._.-(,_..'--(,_..'`-.;.'
>
>