Re: [shadow-styling] /shadow vs /shadow-all

On Mon, Feb 10, 2014 at 3:57 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> The /shadow-all combinator is exactly the older ^ combinator from
> previous updates.  I added the /shadow combinator (which only selects
> the top-level elements in the shadow tree) based on suggestions from
> Boris and Jonas that there should be an easy way to select into a
> shadow tree without implicitly invoking a descendant combinator, due
> to the performance implications of descendant combinators.
>
> My coworker Elliot pointed out privately, though, that moving only
> into the top-level elements makes the styling more brittle - if the
> component author rearranges their shadow DOM so that something isn't a
> child anymore, it'll break users.
>
> He'd prefer that the shortest name go to something that isn't as
> brittle.  He also pointed out that, with bottom-up selector matching,
> there's not actually any real cost difference between /shadow and
> /shadow-all, since you can always cheaply jump from an element in a
> shadow tree directly up to the shadow host in any reasonable
> implementation.  (For the same reasons that any element can cheaply
> jump up to the document in any reasonable implementation.)
>
> This seems compelling to me.  I'd like to swap things around to have
> /shadow be the old ^ combinator, where it selects all the elements in
> the shadow tree, and either rename the "only top-level elements" one
> to /shadow-child, or just kill it and rely on use of :top to handle
> this use-case.

I've gone ahead and made this swap for now.

Based on our discussions in telcons previously about using combinators
vs pseudo-elements, here's my current plan:

1. Keep /shadow/ (which now selects all elements in the shadow tree)
and /shadow-deep/.
2. Drop /shadow-child/.  (Keep :top, so the use-cases can still be addressed.)
3. Add ::shadow, which selects the shadow root.

This has a few advantages, I think:

1. Like I argued in the call, I don't think a pseudo-element for the
/shadow-deep/ functionality makes sense, because there's no
corresponding element for it to select, nor is it ever planned for
there to be.  Using a combinator makes the most sense, as this is just
a super-descendant relationship.
2. I'm okay with ::shadow, as it can be explained as selecting the
shadow root, but I find it confusing that you'd use "foo::shadow bar"
and "foo /shadow-deep/ bar" to do relatively similar things.  Instead,
my plan keeps consistent syntaxes for both - combinators the whole
way.
3. Adding the ::shadow pseudo-element *as well*, though, still gives
us the potential benefits of having "foo::shadow" return the
ShadowRoot object when evaluated in JS, and lets us address the "use
existing combinators" feedback that made /shadow-child/ so clumsy.

This also has the advantage of not delaying our implementation
further, as we can implement this in stages.  Converting ^ and ^^ to
/shadow/ and /shadow-deep/ is just a rename, but supporting
"foo::shadow > bar" is a substantial burden for us in the short term,
as our internal machinery is *not* capable of handling combinators
after a pseudo-element right now.  We're fine with implementing this,
just not immediately. ^_^

~TJ

Received on Wednesday, 5 March 2014 23:40:16 UTC