- From: James Graham <jgraham@opera.com>
- Date: Sun, 17 Jan 2010 19:11:38 +0000
- To: Boris Zbarsky <bzbarsky@MIT.EDU>
- Cc: Aryeh Gregor <Simetrical+w3c@gmail.com>, Graham Klyne <GK@ninebynine.org>, Julian Reschke <julian.reschke@gmx.de>, HTMLWG WG <public-html@w3.org>
Quoting Boris Zbarsky <bzbarsky@MIT.EDU>: > On 1/17/10 7:46 AM, Aryeh Gregor wrote: >> Aren't there lots of features regularly discussed here that can't be >> changed despite the fact they were never put in a CR? Things like >> localStorage > > Which is now widely viewed as a huge mistake, right? 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. >> or various details of attributes and elements (like the >> autobuffer discussion recently)? > > Again, the early implementation isn't helping the spec quality here > much; we'll end up with two attributes for controlling buffering (or > possibly drop autobuffer from the spec altogether, of course). 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. Likely that person would never have read the spec for an unimplemented <video> tag, regardless of the length of the review period; it was simply not on their radar until it was a practical tool that they could use. Of course with a longer review period, there is a greater chance that *somebody* might notice a flaw. However I would guess that that probability rises only slowly with the time available for review; most sections of the spec seem to attract a small number of readers with a particular interest in that technology, plus, eventually, the people actually implementing the feature. Most people are simply uninterested in specs that they cannot use, and find it hard to envision flaws based on the description of a feature rather than the actual reality of wanting to implement or use the feature. 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. 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.
Received on Sunday, 17 January 2010 19:12:18 UTC