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

On Wed, Feb 5, 2014 at 10:58 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> 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


Thanks! Most of these are either addressed or are a dependency on a spec
(such as selection -- in that particular case, Shadow DOM adds nothing new.
It's the selection that's broken).

For example, 18752 was just an idea that will probably never see the light
of day (that's why it's filed in "Things to Consider in the Future" bug
tree: https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=15480), and
the one with resetStyleInheritance falls away as a simple polyfill.


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


This is https://www.w3.org/Bugs/Public/show_bug.cgi?id=23467 (which by the
way has some of the most detailed design docs I've seen)


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


It means that an engineer who is responsible for the feature thinks it is
ready to ship, and now the Blink API owners need to make a decision whether
it is a good idea.


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


There's an example-in-process of that with Shadow DOM. As the
intent-to-ship states, new Shadow DOM will be unshipping the old
(pre-Blink), prefixed Shadow DOM API that is only loosely compatible with
the new API (in that it has <shadow> and <content> element, and allows
creating shadow trees with element.webkitCreateShadowRoot).


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


It's not easy, but it's possible. Ask arv :)

:DG<