[whatwg] Technical Parity with W3C HTML Spec
Tab Atkins Jr.
jackalmage at gmail.com
Fri Jun 25 16:11:44 PDT 2010
On Fri, Jun 25, 2010 at 4:00 PM, Mike Shaver <mike.shaver at gmail.com> wrote:
> 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.
It's possible to use it like that, sure. It makes you look like a
jackass, but it would work. However, its efficacy isn't something
that the WHATWG or anyone else can change - if someone with
significant market share refuses to implement something, *web authors
can't use it*. End of story. No amount of moaning or complaining
about the unfairness of gaming-possibility will change that, because
it's simply how reality works.
There's no sense speccing something that can't be used, because a
significant chunk of an author's visitors won't ever have it. Better
to spend time speccing things that everyone *will* implement.
> 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.
Like I said above, it's not our choice. Removing something from the
spec when a significant browser refuses to implement it is simply
making the spec match reality, because authors won't be able to use
> 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.
Note that "has a browser" isn't enough to give a company veto power.
You need "has a browser with sufficient market share" (where
"sufficient" is somewhere around 1%, based on previous remarks from
Ian). This is due to the reasons stated above - the veto isn't a
power that we grant browsers, it's a right that they earn on their own
by virtue of having users.
More information about the whatwg