Speed of specs (was: RE: Extensibility strategies)

> -----Original Message-----
> From: Ian Hickson [mailto:ian@hixie.ch]
> Sent: Saturday, August 02, 2008 3:28 AM
> To: Justin James
> Cc: 'HTML WG'
> Subject: RE: Extensibility strategies
> 
> 
> I just wanted to jump in and clarify one point which I think may be
> important to consider:
> 
> On Sat, 2 Aug 2008, Justin James wrote:
> > >
> > > The solution to a lack of peer review is peer review, not syntax.
> >
> > I agree *completely*. But we need *something* in place that lets
> browser
> > vendors extend HTML at the speed which they code, not the speed which
> we
> > get specs out the door.
> 
> We can discuss features much quicker than implementors can code and
> ship
> them. Many of the features in HTML5 are examples of this:
> 
> - postMessage() will likely be in then ext version of all four major
> browsers, and we discussed it and got it pretty much nailed down in
> time
> for most of them to get it sorted out.
> 
> - Web Workers were specced in about a week once browser vendors came to
> the table and asked for a spec.
> 
> - <video> went from proposal to thorough spec in a few months, in
> plenty
> of time for implementors.
> 
> There are lots of other examples. The point is that when implementors
> come
> to the Web community first, we can get a basic agreement hammered out
> much
> quicker than they can code it, and then we avoid all the problems of
> lack
> of peer review and of having to have extension mechanisms.
> 
> Now don't get me wrong. None of the examples above are complete. We're
> still collecting implementation and author feedback, and I'm sure there
> will be many more changes as we tweak things. But we don't need to
> actually finish the spec to avoid the problems of browsers making up
> their
> own extensions. Indeed, a spec can't ever be complete before getting
> two
> full implementations. Specs and implementations grow in tandem.
> 
> It's only when browser vendors fail to come to the table at all -- as
> with
> canvas, for instance -- that we get problems.

What I had in mind was something to get a true, formal spec ratified and
completely much more quickly. As you point out, we as a group can get
something together quickly, particularly once the browser vendors get
onboard. Less fortunately (or quite fortunately, depending upon the
circumstances!), you've also said that everything in the draft is open for
discussion, revision, editing, removing, etc. until this spec is finalized.
That means that we could spec something this week, browsers could ship on
that spec next month, authors could start using it in two months... and 3
months later we realize that there is a critical flaw with it and need to
change the spec, but we can't because browser vendors already shipped based
on it.

I know I'm being overly tight here, it's not like finalized specs never
change either. But I'm the kind of person who won't buy a 802.11 "draft n"
WiFi router, because that spec never finalized, and I would strongly
discourage HTML authors from writing code based upon an implementation of a
spec that has not been finalized yet. So yeah, I'd like it if we could have
some sort of "HTML add-on" items that we could release in a finalized form
on a regular basis, and get stuff like Web workers, <audio>, <video>, etc.
in it so people can be working with a finalized spec that we promise we've
really audited and plan on not changing before the full HTML 5 spec gets
finalized, instead of them basically guessing what hopefully won't change
and implementing and authoring against that.

I also recognize that this is 99.99% not going to happen for a great number
of reasons, our charter and expected deliverables, for one thing. :)

J.Ja

Received on Wednesday, 6 August 2008 05:33:41 UTC