RE: The harm that can come if the W3C supports publication of competing specs

For better or for worse, major browsers already have implemented a number of
HTML 5 features, and (also "for better or for worse") a number of Web sites
have already started leveraging that functionality. One thing I've noticed
is an outright mockery of this group around the "HTML 5 will be a
recommendation in 2022" concept, which is *incredibly* misunderstood. People
have an amazing ability to miss the rest of that statement (the part about
how "recommendation" means it has two full and correct implementations,
which will indeed take quite a while), for whatever reason. The point is,
the HTML 5 cat is already out of the bag as it were. Regardless of what
people should or should not do (I'm in general agreement that leveraging
features from a spec that is still in development is not a good idea unless
you don't mind getting burned if it changes underneath your feet), people
are already implementing and leveraging these features, and I would not be
surprised if some of the HTML 5 features we keep discussing have already
surpassed some of the older items that we are loathe to remove or change due
to them being used by 0.001% of Web pages.

J.Ja

-----Original Message-----
From: Shelley Powers [mailto:shelley.just@gmail.com] 
Sent: Sunday, January 17, 2010 12:05 AM
To: Justin James
Cc: HTMLWG WG
Subject: Re: The harm that can come if the W3C supports publication of
competing specs

On Sat, Jan 16, 2010 at 10:09 PM, Justin James <j_james@mindspring.com>
wrote:
>> It is irresponsible of us to encourage the use of unreleased and
>> unstable specifications. Even ones we like.
>>
>> Shelley
>
> That creates a "first mover" problem which will render HTML 5 forever
stuck
> in limbo. HTML 5 will not become a full "recommendation" without two full
> and complete implementations. Therefore, HTML 5 will never because a 100%
> "released" and stable specification without encouraging its use before it
> has achieved that status.
>
> In fact, I'd say that most specs written in the modern era are like this.
> The days of having a spec develop in a bubble with everyone waiting on its
> public, stable release are OVER. Draft-N wireless, anyone? In reality,
> plenty specifications attempt to document the "baseline" where existing
> implementations overlap to provide a common ground that new
implementations
> can start from.


Implementations. Not recommending that production sites utilize the markup.

Yes, before we go to candidate recommendation, we'll need two
implementations of the specifications. But that doesn't mean that
production sites should incorporate specifications that aren't
LC--that aren't even FPWD yet.

There is a world of differences between the two.

>
> J.Ja
>
>

Shelley

Received on Sunday, 17 January 2010 06:18:40 UTC