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

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_ 
implementation?

> 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.

-Boris

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