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

Quoting Boris Zbarsky <bzbarsky@MIT.EDU>:

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

So it seems like you are saying that, in this case, a mostly-unrelated  
shift in the technology landscape (browsers wanting to switch to multi  
thread/process) designs caused problems with an existing feature. The  
fact that feature happened to be in a working draft spec rather than a  
CR spec (or even a REC) is just an accident of history. Indeed I don't  
doubt that there are many spec-wise stable features that we would  
design differently today given the typical architecture of modern  
browsers (or architecture we would like in modern browsers) compared  
to the typical browser architecture at the time the feature was first  
designed.

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

I strongly suspect that only an actual shipping implementation was  
good enough. I imagine people are not that interested in authoring  
production sites against "experimental" features that only appear in  
technology-preview builds (or even features that are prefed off by  
default in shipping builds). The @autobuffer issue did not come up  
until someone considered the problem of using <video> on their  
production site with real-world concerns like billing for bandwidth,  
and, critically, until there were two implementations (enough to make  
it seem worth targeting), one of which did not behave in the way that  
they needed (but still conformed to the spec). Prior to the issue  
coming up there were numerous people who made experimental demos with  
video (and a few who made serious sites using it) and yet more people  
who had read much of the spec. However none of those people noticed  
the problem, or if they did, they thought it insignificant.

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

I suspect the main effect of technology preview builds is to get  
people who are interested in specs to seriously consider speccing a  
technology. The "experimental preview" builds I have seen are  
typically so far from the final design and used by so few people that  
they do not do a great deal to avoid problems cropping up later (e.g.  
Opera's experimental <video> build didn't prevent the @autobuffer  
problems).

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

The draft already says exactly that:

"Implementors should be aware that this specification is not stable.  
Implementors who are not taking part in the discussions are likely to  
find the specification changing out from under them in incompatible  
ways. Vendors interested in implementing this specification before it  
eventually reaches the Candidate Recommendation stage should join the  
aforementioned mailing lists and take part in the discussions."

The "problem" is that people actually want the features in HTML5, and  
hence implementers want to provide them. I don't think that slicing  
and dicing the spec into a multitude of different specs fundamentally  
changes the market dynamics; implementers implement the things that  
they think are best for the platform (i.e. the things that authors are  
asking them for). These are often the things that other implementers  
have already implemented and so are needed for compatibility. That  
inevitably creates feedback on those features as they come into  
broader use, which leads to the realisation that the design should be  
altered. However it also creates legacy content that implementers are  
reluctant to break (because their users don't like it when upgrades  
break sites). Yet without the implementations and the user feedback,  
we likely wouldn't realise that the spec wasn't really ready after all.

All these pressures are more-or-less independent of anything in the  
spec itself and of anything that the W3C, the WHATWG, or anyone else  
in specs land, does. I guess we could start a massive negative  
publicity campaign about our own spec and talk about how it won't be  
ready until 2022 or something but, quite apart from the fact that that  
seems silly, the "HTML5 won't be ready for many years" thing has  
already happened and hasn't stopped people using the features that are  
shipping already. I guess implementers could band together and pledge  
not to implement certain things, but it hardly seems likely to happen  
and doesn't even seem particularly likely to improve the overall  
quality of the spec when it finally is implemented.

Received on Sunday, 17 January 2010 22:37:13 UTC