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

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