-
Notifications
You must be signed in to change notification settings - Fork 679
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css-cascade][css-scoping] Host layerable shadow roots #9792
Comments
@knowler are your example stylesheets that are inside the shadow DOM or outside? |
There seem to be two issues at play: styling access to the shadow DOM and styling priority in relation to shadow DOM styles. Layers are well designed for helping with the priority side. I like the idea of layering custom element styles into a page style, much the same way I would layer-in styles from other third-party tools. That's what layers were designed for! I'm a bit less convinced by the way layers are used here to also grant access. For one thing, it feels a bit tangential to the layering, and not entirely obvious that adjusting the priority also provides access for some but not all page styles – based on the priority of those styles. I'm not sure it makes sense to base access on priority like that. But also: this puts a limit on the ability of layers to do what they're designed for: explicitly re-arrange priorities. I can see use-cases where that works, but also use-cases for the opposite. When I ship a web component, I want to provide default styles that are easy to override. The current priority order is fine, with the page taking precedence. What I really want to do is provide access for those page styles to get in. |
@mirisuzanne I do think that access goes hand-in-hand with priority though (inversely, i.e. access decreases in subsequent layers). It might not be what Cascade Layers were explicitly designed for, but just how Cascade Layers came to be out of an eye towards how the Cascade already worked, that’s what inspired how this feature should work. User agent and user styles have access to shadow contexts for styling, so shifting the shadow context down to be within the layers of the document styles, the layers which come before would have access in the same way. Just because access seems to be tied to priority in this way, doesn’t mean that’s how Cascade Layers should work, but I think it does work well with the design of shadow DOM styling APIs. My goal with this feature isn’t to replace those APIs (i.e. custom elements, CSS Parts, custom properties, I think maybe the underlying challenge here is that theming requires coordination across layers in the cascade. Theming often requires some access to defaults, since it’s not easy for component authors to be able to make their component inherently/universally themable, especially as a component becomes more complex (i.e. composing elements). I actually think that might be what this experimental “Defaults Styles for Custom Elements” section of the latest Scoping Level 1 Editor’s Draft is trying to get at. |
I originally proposed this here: WICG/webcomponents#909 (comment). I talked with @mirisuzanne and she recommended we continue to flesh out this proposal here before bringing it back to WICG. What follows is more so geared towards one who has read/understands the CSS Cascading and Inheritance spec (see the original proposal for a more web-components-oriented perspective).
This is a proposal to allow cascade layers within an outer context (e.g. a document or shadow root) to style elements within an inner context (i.e. elements within a shadow root).
In regard to the Cascade, this would effectively bump the corresponding shadow context down in the sorting order to be within the outer context’s layers (i.e. sorted after whatever layer it was marked for access).
For authors of the outer context (e.g. a consumer of a Web Component using the Shadow DOM), this would mean greater styling flexibility than what is available through existing shadow root styling APIs (e.g. CSS Parts, slots, custom properties).
For authors of the inner context (e.g. an author of a Web Component using the Shadow DOM), this would mean reduced style encapsulation—but style encapsulation nonetheless:
!important
.all: revert
to effectively ignore styles from the host’s permitted layers for an element.!important
.How this would work?
TODO: add better examples here
Here’s an idea for the CSS syntax (
shadow()
might not be great sincedrop-shadow()
is a thing):In this case, the simplified expected sorting order (for elements in the shadow root):
defaults
layer.layouts
layer for the exposed elements (e.g. CSS Parts).In cases where the shadow root was layered after the first layer, it would still receive the styles of the previous layer(s):
For this case, the simplified expected sorting order (for elements in the shadow root):
defaults
andcomponents
layer.layouts
layer for the exposed elements (e.g. CSS Parts).Use cases
TODO: add more use cases
Problems with this proposal
The text was updated successfully, but these errors were encountered: