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

On 1/17/10 5:36 PM, James Graham wrote:
> 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.

Sort of.  This was the case for Gecko.  In Chrome's case, the 
multi-process was in fact done after localStorage, without worrying 
overmuch about the issues as far as I can tell.  I have no idea what the 
ordering was for IE, since both shipped in IE8 and their development 
process is somewhat more opaque than Webkit's or Gecko's...

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

True.  Many things that happen are somewhat random, but that doesn't 
mean one shouldn't try to tilt the odds in a desirable direction.

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

Maybe.  We (Gecko) get a fair number of bug reports against such 
features when we have them.  Clearly not a substitute for widespread 
author deployment, but much better than shipping first and getting 
feedback later.  Hard to say whether that would have caught the 
autobuffer issue, of course; you may be right about that particular case.

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

That doesn't tell web authors "This is half-baked; don't push for 
implementations of it."

> The "problem" is that people actually want the features in HTML5, and
> hence implementers want to provide them.

Sort of.  "people" seem to want complete feature and misfeature parity 
between all web browsers.  Given any behavior difference, people will 
file it as a bug on one or both browsers.

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

Maybe.  Implementers implement what they feel like; as far as I can 
tell, some of it is for the reason you describe and some is to be able 
to check off checkboxes in a "we support hot new technology X" 
spreadsheet that they can then hype.  Never mind if their implementation 
is broken, or even useless.  The important part is that its "implemented".

We don't want to encourage that dynamic, and right now we are, with our 
de-facto policies of not changing stuff once someone ships it and our 
unclear message to web authors about what things they should push for 
implementation of and which they shouldn't.  The net result is there is 
at least short-term competitive advantage to shipping crappy 
implementations of as much of "HTML5" as possible as fast as possible, 
whatever the effects on "the platform".  Now on the other hand all the 
implementors involved happen to be decent human beings who don't want to 
poison features, etc.... and that's what keeps the whole thing from 
being a total fiasco.

And this issue is not necessarily restricted to HTML5 (some CSS features 
have similar issues).  Basically, any time implementation happens to 
check off a checkbox, the result seems to be brokenness.

> These are often the things that other implementers have
> already implemented and so are needed for compatibility.

That's a separate story entirely; the parts of HTML5 that are "needed 
for web compat" are not the parts I'm worried about here.

> 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 honestly don't think that's the case.

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

I think we could effectively focus on getting those parts of the spec 
more likely to be implemented in the near future into a stable state by 
giving Ian feedback that he should focus on them and that we could focus 
a lot more on providing implementation feedback while implementing, and 
not sometime shipping.  I don't think we've done a great job of this, as 
a group.  Gecko's implementors of the offline cache stuff didn't ask 
nearly as many question as I think they should have.  I don't recall a 
slew of questions about web forms coming through, and the stuff there is 
complex enough that I find it a little hard to believe that there were 
no questions to be asked.  That sort of thing.

Of course I could just be completely off my rocker here.  Wouldn't be 
the first time!

-Boris

Received on Monday, 18 January 2010 01:58:47 UTC