W3C home > Mailing lists > Public > www-style@w3.org > February 2014

Re: Procedural (non-technical) point about freezing the cat and hat combinators before they've even been defined (was Re: Shadow DOM: Hat and Cat -- if that's your real name.)

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 05 Feb 2014 13:58:36 -0500
Message-ID: <52F289DC.7020108@mit.edu>
To: Dimitri Glazkov <dglazkov@google.com>
CC: "www-style@w3.org" <www-style@w3.org>
On 2/5/14 1:47 PM, Dimitri Glazkov wrote:
> Are there spec bugs for these? I would love to understand what specific
> issues you're worried about here.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18752
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22980

track the things I mentioned in the mail to Tab, I think.

Other things we're a bit concerned about:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=20958

and not sure whether we have bugs tracking these:

http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0200.html
http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0114.html

Plus of course the cat/hat stuff this thread started with.

> On shipping: currently, there's an Intent to Ship posted on blink-dev.

For those of us not intimately involved with Blink development, what 
does this mean in practice?

> On freezing: A "frozen API" is glorious concept, but I don't see how it
> would work.

The canonical way such things have worked in the past is that a UA ships 
something and then claims it can't change it anymore because it has been 
shipped and changes would break compat.  For some values of "worked", of 
course.  ;)

> On resolving outstanding issues: absolutely. The spec work doesn't stop
> just because there's an implementation in the wild.

That depends on whether the implementation is willing to adjust as the 
spec changes.  Historically UAs have not been terribly willing to do so, 
though some have been more willing than others.

> My assessment of the remaining open spec bugs is that they all can be addressed as evolution
> of the current Blink implementation.

Without breaking compat in the process?  Or will Blink be willing to 
make such breaking changes?  That's the part that is least clear, esp. 
considering the original mails in this thread explicitly talked about 
some breaking changes Blink would not be willing to make.

> I think what Tab was trying to convey is the relative level of pain a
> change in the API causes. For example, it's relatively easy to polyfill
> and thus tweak DOM APIs.

It's not really easy to polyfill the event path, unless I'm missing 
something?

-Boris
Received on Wednesday, 5 February 2014 18:59:07 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:18 UTC