Re: [WICG/webcomponents] "open-stylable" Shadow Roots (#909)

@bkardell Thank you for your longer description.  Please also forgive the wordy response.

Short answer:  with declarative shadow DOM, selector shadow-crossing no longer needed, but (inherited and repriortizable) shadow @layer now needed.

Because I am using declarative shadow DOM, I am saying that in your example I (as a component user _<b>or</b>_ a component designer) do not need:

```css
.foo .bar button {
}
```

where `.foo` is outside the shadow tree and `.bar button` is inside the shadow tree. Because declarative shadow DOM already solves that in a completely different but much better way.

But I still need something for:

```css
.bar button {
}
```

where `.bar button` is inside the shadow tree.

Why does declarative DOM (and repriortizable cascade layers) matter here? It may seem unrelated, but when I use it, I find it central.

Declarative shadow DOM doesn't change how the shadow tree works. The shadow tree is still encapsulated in exactly the same way as always. That's great.

But declarative shadow DOM does change when the shadow tree is initialized -- earlier at parse time rather than later imperatively.  That's great too.

So with declarative shadow DOM, the component user, not the component designer, writes the component template.

_So now the component user already has easy access to style a shadow tree from inside the shadow tree_.

See my original example.

So given this, my longer answer to:

> What would take a change is if you wanted to write a style that somehow considered across the shadow boundary. Are you suggesting that it should? How? With a new combinator?

is 

- I am suggesting I don't need to cross the shadow boundary in that way at all.
- Change not needed. 
- There's a better, different, and easier way. No new combinator needed, and its absence is superfluous. 
- A (any?) component I might have wanted it for before I can now just rewrite as an HTML-first declarative web component. 
- The Web is a broad place and all use cases matter, so hopefully it is not too harsh to say that just for me, by and large the whole let's invent a new way for selectors to cross shadow boundaries is OBE (overtaken by events).

But now that is so easy for a component user to style a shadow tree from inside the shadow tree, I want to take the next step.

I want to bring in a lot of styles, including subsets of page styles, into shadow trees, with differing priorities. 

There are double-loady ways of doing that now with declarative shadow DOM, but "inheriting" cascade layers into shadow trees as I have described previously seem much better to me.

So for me shadow @layer is not related to the (now unneeded) solution of defining a new shadow crossing selector.

But shadow @layer is related to the original primary use case of this issue of how can component designers support styles they don't control.

I think that half-light takes a great half step in this direction too.  I just see pull, rather than push, as the key path.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/WICG/webcomponents/issues/909#issuecomment-1977302028
You are receiving this because you are subscribed to this thread.

Message ID: <WICG/webcomponents/issues/909/1977302028@github.com>