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.