W3C home > Mailing lists > Public > public-html@w3.org > January 2010

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

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Sun, 17 Jan 2010 12:07:04 -0500
Message-ID: <4B5343B8.30009@mit.edu>
To: Aryeh Gregor <Simetrical+w3c@gmail.com>
CC: Graham Klyne <GK@ninebynine.org>, Julian Reschke <julian.reschke@gmx.de>, HTMLWG WG <public-html@w3.org>
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?

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

> Realistically, the spec stabilizes piece by piece as it gets widely used, and only gets to CR when
> *everything* is stabilized.

While true (and unfortunate), Microdata and RDFa+HTML are not in that 
position: they're now independent drafts that can happily proceed to CR 
once they're actually ready.

> In a spec as large as HTML5, that means
> that some parts will be stable years before the whole spec.

Sure, and those are annotated (though I've never been quite able to tell 
who decides when those annotations get changed and what those decisions 
are based on).  But that's irrelevant to the Microdata or RDFa+HTML 

> In this particular case, I've confirmed with Ian that if Wikipedia
> starts using microdata, it won't later be changed so as to break our
> content, so for my purposes it's stable.

And for my purposes, that's not Ian's decision to make.

> CSS vendor prefixes have their own disadvantages, though, right?
> There's no way to tell them apart from vendor-specific extensions, for
> one thing.  I recently spoke to a web developer who thought
> border-radius was a nonstandard feature that WebKit and Mozilla
> happened to agree on.  Furthermore, since authors often do "-moz-foo:
> bar; -webkit-foo: bar; foo: bar"

Then they know they're playing with fire, I'd hope.  If not, I 
personally have no qualms about breaking them, in general.

Received on Sunday, 17 January 2010 17:07:39 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:57 UTC