<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.26.3">
</HEAD>
<BODY>
On Fri, 2010-06-25 at 16:11 -0700, Tab Atkins Jr. wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
On Fri, Jun 25, 2010 at 4:00 PM, Mike Shaver <<A HREF="mailto:mike.shaver@gmail.com">mike.shaver@gmail.com</A>> wrote:
> On Fri, Jun 25, 2010 at 3:30 PM, Aryeh Gregor <<A HREF="mailto:Simetrical+w3c@gmail.com">Simetrical+w3c@gmail.com</A>> 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
</PRE>
</BLOCKQUOTE>
<BR>
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.<BR>
<BR>
I'm quite thankful that standards weren't dropped because this 'major player' refused to participate in the same sport as everyone else.<BR>
<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
Thanks,<BR>
Ash<BR>
<A HREF="http://www.ashleysheridan.co.uk">http://www.ashleysheridan.co.uk</A><BR>
<BR>
<BR>
</TD>
</TR>
</TABLE>
</BODY>
</HTML>