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 9:33 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 2/5/14 11:03 AM, Tab Atkins Jr. wrote:
>
>> There are numerous examples of similar things elsewhere in the WG's
>> history, and even current behavior - 'will-change', for example, is
>> probably going to be shipped by Firefox and Chrome before it reaches
>> the "proper" level of maturity in the W3C Process.
>>
>
> Tab,
>
> 'will-change' was discussed at some length, and there is general agreement
> for how it should work.  This was feasible because it's a pretty small
> feature.
>
> For the case of Shadow DOM we're in a worse position, not least because
> it's not so much a small feature.


Indeed! Shadow DOM is so big, I started making momma jokes about it.


>  There are all sorts of known issues where people disagree about how it
> should work.  We're not talking edge cases here but things like how events
> actually propagate, how styles are inherited in the tree (because the spec
> says it works the same way as events propagate), how styles on the
> shadowRoot work, and how <content> behaves by default.
>
> Maybe you do consider those edge cases?  I'm not sure.  Some of these
> (e.g. the <content> one) haven't exactly gotten a lot of discussion, so
> maybe no one cares about them in practice, but the issue with the event
> path and style inheritance seems pretty non-edge-case to me.


Are there spec bugs for these? I would love to understand what specific
issues you're worried about here.

 Sometimes things
>> are important enough that pushing forward a little faster is
>> justified.
>>
>
> Sure, but there is a difference between shipping something people agree
> with in principle but the details aren't fully worked out yet and hoping
> that you didn't make any mistakes in the details and shipping something
> people are explicitly disagreeing with.
>
> The posts that started this thread seemed to be doing the latter, while at
> the same time explicitly pointing out that once shipped the implementation
> would likely be frozen in short order.  I hope you can see how that came
> off as a little ... offputting.  That might not have been the intent, but
> it was the net effect.
>
> I'm going to assume that the initial posts here were phrased unfortunately
> and hence misunderstood by everyone that read them.  So let's try to
> correct those misunderstandings.  Can you please clearly state what your
> plans are for shipping the feature, freezing or not freezing functionality,
> and resolving the outstanding disagreements about the behavior?
>

I can try :)

On shipping: currently, there's an Intent to Ship posted on blink-dev.
There hasn't been a whole lot of discussion there yet, but I expect it to
be an exciting one. I invite you folks to partake.

On freezing: A "frozen API" is glorious concept, but I don't see how it
would work. If Blink does go forward with enabling the API by default, it
as a project accepts all responsibility for any future API changes. That's
one reason I expect he intent-to-ship discussion to be exciting.

On resolving outstanding issues: absolutely. The spec work doesn't stop
just because there's an implementation in the wild. My assessment of the
remaining open spec bugs is that they all can be addressed as evolution of
the current Blink implementation. There's definitely a potential for some
defaults flipping, but that's something we can deal with. For example,
Polymer insulates developer from most of these decisions.

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. Since Chrome updates every 6 weeks, I am not as
worried about those bits.

Since CSS has no extension points, it's more difficult to polyfill. So it
would be harder to "unstick" a CSS combinator if it starts getting used in
the wild. Harder, but again -- not impossible.

Given how much growth Polymer had seen in the recent months, I expect these
features to start getting used pretty actively. On the other hand, if
Polymer tanks, and nobody uses shadow-piercing combinators/pseudoelements,
it's a self-solving problem.

:DG<