[whatwg] Technical Parity with W3C HTML Spec

On Fri, Jun 25, 2010 at 3:30 PM, Aryeh Gregor <Simetrical+w3c at gmail.com> wrote:
> I'm pretty sure they won't be. ?Any significant implementer has always
> had veto power over the spec.

I fear that simply refusing to implement is indeed the WHATWG's
equivalent of how Tab described FO-threats in the W3C environment: a
much more efficient way to influence the direction of the document
than sharing technical reasoning during the design of a capability.

> For example, Mozilla vetoed Web
> Databases, and Apple vetoed Theora requirements, by just saying they
> wouldn't implement them.

Web Databases was removed from the specification before we were even
certain within Mozilla that we wouldn't implement them, so I don't
think that's quite right.  It's true that we don't think it's a good
technology direction for the web, and that we didn't believe it
belonged in HTML5 proper, but I don't think that's quite the same
thing.  (To the extent that "Mozilla" has unanimity on such things in
the first place.)

>?Ian has always made it clear that he'll spec
> whatever the implementers are happy with.

That is not my recollection of what happened with offline, for what
it's worth. Mozilla and Google had a relatively small set of
deviations between approaches (ours developed on the whatwg list and
Google's developed behind closed doors prior to the Gears
announcement) and Ian specified an entirely different model, over the
objections of both Mozilla and Google.  I welcome corrections to the
timeline and details here, but apparently the behaviour that we
*should* have exhibited was simply refusing to implement, rather than
changing late in our development cycle to the new specification that
Ian constructed, for which there was no implementation or deployment
experience.

Is that really how we want the group to operate?  It seems to reward
silent refusal with greater influence than transparent reasoning.  We
saw similarly (IMO) offensive behaviour when IBM voted against the ES5
specification at ECMA General Assembly, simply because their pet
feature hadn't been included (though there was ample technical
justification for its omission, both in closed-door membership
meetings and in the public list).  Happily, in that case it simply
made IBM look manipulative and petty, and didn't prevent the
specification from reaching ratification.

If I were to be in charge of an organization building a platform that
competed with the web, I would certainly consider it worth my time to
implement a browser and then refuse to implement pieces of the
specification that competed with my line of business.  Certainly if I
were running an organization that made a browser and had a line of
business threatened by a piece of the specification, it would be very
clear how to mitigate that threat, since no specifics need be provided
in support of a refusal veto.

Mike

Received on Friday, 25 June 2010 16:00:35 UTC