- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Wed, 05 Feb 2014 13:58:36 -0500
- 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