W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2010

[whatwg] Technical Parity with W3C HTML Spec

From: Ashley Sheridan <ash@ashleysheridan.co.uk>
Date: Sat, 26 Jun 2010 00:31:18 +0100
Message-ID: <1277508678.2787.98.camel@localhost>
On Fri, 2010-06-25 at 16:11 -0700, Tab Atkins Jr. wrote:

> 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
> that feature.
> 
> 
> > 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.
> 
> ~TJ


If we all subscribed to that point of view though, everyone would still
be stuck using IE5. As it is, there's a push by developers to use
features that IE has always been slow to implement but other browsers
have, and IE being the most popular browser is a pretty major player.
Just because they've refused to support things countless times hasn't
stopped the progression of standards; standards that other browsers
adhere to for the most part.

I'm quite thankful that standards weren't dropped because this 'major
player' refused to participate in the same sport as everyone else.

Thanks,
Ash
http://www.ashleysheridan.co.uk


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100626/cebc27cf/attachment.htm>
Received on Friday, 25 June 2010 16:31:18 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:24 UTC