W3C home > Mailing lists > Public > public-html@w3.org > January 2010

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

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Sun, 17 Jan 2010 16:26:22 -0500
Message-ID: <4B53807E.1030009@mit.edu>
To: James Graham <jgraham@opera.com>
CC: HTMLWG WG <public-html@w3.org>
On 1/17/10 2:11 PM, James Graham wrote:
> Undoubtedly there are problems with localStorage's design. It is much
> less clear that these problems would have been noticed and dealt with if
> the spec had gone unimplemented for longer.

Given they were noted when someone stopped to think about how exactly 
localStorage is supposed to interact with multiple threads/processes.... 
I'm not sure the implementation state of localStorage was all that 
relevant.  The implementation status of non-single-threaded browsers was 
more important.

> In this case the feedback that @autobuffer was a bad design came when
> someone tried out an actual implementation and realised that it did not
> meet their requirements.

An actual _shipping_ implementation, or an actual _experimental_ 

> In general there is a tension between wanting to avoid really bad
> mistakes by having a long up-front design and review period, and the
> desire to implement features so that they are actually available to
> users.

This is somewhat of a false dichotomy.  It's quite feasible to implement 
features and distribute technology-preview builds without necessarily 
pushing out the implementation to a few hundred million users.  Of 
course some people wouldn't actually try these preview builds...  given 
the number of people who seem to not test whether their site breaks in a 
new browser version until it hits release candidate, possibly quite a 
number of people.

> In general I think the HTML5 process has worked rather well here
> with early implementations typically leading to a great deal of
> spec-changing feedback, the implementations generating invaluable
> feedback from actual users, and implementers typically willing to tweak
> their early implementations when the spec has changed under them.

I think I have two issues with the way the process has worked:

1)  There have been several spectacular failures in terms of the
     "willing to tweak" either not happening or not being enough.
2)  There seems to be a lot of misconception out there about the
     stability of parts of the draft, or even that there are different
     stability levels, with resulting pressure on implementors to
     implement half-baked things.  I think we would be a lot better off
     without such pressures, honestly.

For the full draft, we may be sort of stuck with issue #2 because the 
situation is complex to describe (though saying "this is all unstable 
unless explicitly indicated otherwise" might help).  That's not a 
restriction we have with standalone drafts.

Received on Sunday, 17 January 2010 21:26:58 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:57 UTC