[css-scoping][selectors] :root should resolve to :host in shadow trees

[LeaVerou]

https://drafts.csswg.org/selectors/#the-scope-pseudo

Currently, if used in regular CSS but outside an @scope rule, :scope resolves to :root. However, this is not super useful within shadow CSS. :host would be a lot more natural.

This would be a breaking change, but I’d wager the prevalence of :scope outside @scope in shadow CSS is so low that we can still make it.

This means the same CSS can be used within Shadow DOM to style the component, as well as using @import ... scope(...) to style light DOM elements.

[sorvell]

This means the same CSS can be used within Shadow DOM to style the component, as well as using @import ... scope(...) to style light DOM elements.

This is indeed an annoying pain point right now when trying to share styles. While you can write :where(:host, :scope, :root), it's cumbersome and I believe this isn't currently supported in Safari (bug or unspec'd?).

Separately and for the same reason could :root resolve to :host in a shadow tree?

[LeaVerou]

Separately and for the same reason could :root resolve to :host in a shadow tree?

YES!

Actually, that’s all we need. Since :scope resolves to :root outside @scope, if :root resolves to :host, by proxy :scope also resolves to :host. I’ll rename the issue.

[Loirooriol]

Highlight pseudo-elements inherit custom properties from :root. Does this mean that in shadow dom they will be inherited from the host?

[Loirooriol]

Even if resolving to :host is more natural, right now authors can choose :host vs :root.
If both :root and :scope behave as :host, then authors will lose the ability to target the actual root.
So maybe just changing :scope but not :root would offer more flexibility.

Edit: or maybe just let :root match the host, while in :host-context(:root) it refers to the actual root (or host's host)?

[LeaVerou]

Highlight pseudo-elements inherit custom properties from :root. Does this mean that in shadow dom they will be inherited from the host?

Seems reasonable.

Even if resolving to :host is more natural, right now authors can choose :host vs :root. If both :root and :scope behave as :host, then authors will lose the ability to target the actual root. So maybe just changing :scope but not :root would offer more flexibility.

Not sure that kind of flexibility is something authors need though, given that :root is meaningless in shadow roots.

Edit: or maybe just let :root match the host, while in :host-context(:root) it refers to the actual root (or host's host)?

That seems reasonable.

[andruud]

Edit: or maybe just let :root match the host, while in :host-context(:root) it refers to the actual root (or host's host)?

Hmm, this is basically the same as allowing :scope to point to different things depending on where it appears in a selector, which I'm pretty sure we explicitly decided to avoid in the past (@mirisuzanne). Although :host-context() might be enough of an "explicit tree-context switch" that it's OK after all ...

So maybe just changing :scope but not :root would offer more flexibility.

I think this move makes more sense, since :scope is already intended to be the "root in some context".

:where(:host, :scope, :root)

If we let :scope match the host, you'd only need :scope for that.

[mirisuzanne]

I support making :scope match the :host for sure. I do think :host-context(:root) is a very explicit opt-in if we do want to make the change to :root as well. That change makes sense to me on first glance.

[sorvell]

As @LeaVerou said, :root doesn't match anything currently in a shadow tree so the change would be to make it do something useful when sharing a stylesheet also used in the main document.

A relevant use case would be to define a series of custom properties on :root, and you might want to ensure these are defined as they are in :root for a given shadowRoot if you know that they may have been reset via inheritance.

Regarding :host-context(:root), I think it's unfortunate to rely much on something like this since we're in a bad spot on :host-content where Webkit has refused to implement it.