- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Sun, 17 Jan 2010 16:26:22 -0500
- 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_ 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