You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A recurring pain point around defining WC styling is that shadow DOM CSS is too limited to target what authors actually want to target. A common use case is targeting slotted (light DOM) descendants and/or relationships between slotted elements.
WCs today can always inject light DOM CSS the first time an instance of a WC is created or connected, but it is nontrivial to do well, and very easy to do wrong, which creates a footgun. The easy option would be to inject it in e.g. document.head, which means it does not get applied in any ancestor scopes (when you have nested shadow roots). Additionally, because this CSS needs to use regular selectors (rather than :host) it cannot support customizing element names or scoped registries. Not to mention that it requires CSS to be maintained in two separate places (or to jump through hoops so that the same CSS file can be used in both places).
An easy solution to this would be a new @-rule (@light? @global?), the contents of which are evaluated in the context of the light DOM, except :host still works. So for example this would work:
<foo-tree><ul><li></ul></foo-tree>
@light {
:hostul>li {
list-style: ...
}
}
Just like any other @-rule, it can also be combined with nesting to keep related styles together. E.g. the rule above could also be written as:
:host {
@light {
ul>li {
list-style: ...
}
}
}
There is a lot of precedent in frameworks for being able to have this kind of escape hatch (e.g. Svelte’s :global, Vue’s :global() etc).
Talking about this with @tabatkins, it seems pretty straightforward. He said it may be easier to get consensus if it is scoped to not be able to specify anything outside :host. I think the vast majority of use cases are within :host, though being able to write whole rules means we can also use :host() and :host-context().
The text was updated successfully, but these errors were encountered:
Talking about this with @emilio he pointed something out: this is not always as simple as "writing CSS as if the CSS was on the outside". Consider this case:
The light DOM inside <fancier-list>’s shadow root is:
<fancy-list><slot></slot></fancy-list>
So a selector targeting fancy-list li would not work in either context.
Maybe that’s okay though? Since this is a band-aid solution because we cannot have #7922 maybe it’s okay if some edge cases are missed?
A recurring pain point around defining WC styling is that shadow DOM CSS is too limited to target what authors actually want to target. A common use case is targeting slotted (light DOM) descendants and/or relationships between slotted elements.
WCs today can always inject light DOM CSS the first time an instance of a WC is created or connected, but it is nontrivial to do well, and very easy to do wrong, which creates a footgun. The easy option would be to inject it in e.g.
document.head
, which means it does not get applied in any ancestor scopes (when you have nested shadow roots). Additionally, because this CSS needs to use regular selectors (rather than:host
) it cannot support customizing element names or scoped registries. Not to mention that it requires CSS to be maintained in two separate places (or to jump through hoops so that the same CSS file can be used in both places).An easy solution to this would be a new @-rule (
@light
?@global
?), the contents of which are evaluated in the context of the light DOM, except:host
still works. So for example this would work:Just like any other @-rule, it can also be combined with nesting to keep related styles together. E.g. the rule above could also be written as:
There is a lot of precedent in frameworks for being able to have this kind of escape hatch (e.g. Svelte’s
:global
, Vue’s:global()
etc).Talking about this with @tabatkins, it seems pretty straightforward. He said it may be easier to get consensus if it is scoped to not be able to specify anything outside
:host
. I think the vast majority of use cases are within:host
, though being able to write whole rules means we can also use:host()
and:host-context()
.The text was updated successfully, but these errors were encountered: