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

I’ve said it before, but I’ll say it here for the record: making web component styling exactly like framework components would be a huge regression. Style encapsulation is good (who wants to use a leaky abstraction??) and the goal should be to augment it, rather than replace it. It’s also possible to augment it in such a way that appeases legacy use cases, works with existing framework component styling paradigms, and better empowers existing and future web components.

In opening a shadow root for greater styling access from its host’s context (i.e. a document or another shadow root), layers actually become quite useful for a component author. If you look through a framework component’s styles you’ll notice some implied layers in action (using specificity and order of appearance). Typically, there are resets, the base styles for a component (e.g. a base class like `.navbar` in Bootstrap), then variants, and then themes. You’ll even notice that components which are composed by others are ordered first. So now as a component author who would like to maintain style encapsulation, perhaps I’d like to allow consumers greater control of tweaking my components to better improve their use of them. By providing them these layers as hooks, they can more deterministically “slot” their styles where they need to go for the proper effect. Maintaining style encapsulation ensures that the final styling API for the component remains in tact and it doesn’t leak when being used within other compositions (e.g. in another component; on page).

My initial emphasis in the [“host layerable shadow roots” proposal][1] of cascading external layers prior to a shadow root’s styles was to provide a component some default styles for elements to compose with within its shadow root. Currently, the only happy-path to do that is to pre-modularize what you want a shadow root to compose with as a web component. Parts and slotted content fail here since the cascading is reversed: _the component is providing defaults_ for them that the consumer overrides (this is good for the final styling API). Through discussing with others and reading a lot of CSS it became clear that more granular cascading control would be desired.

Now, while the concern that using layers as the mechanism for access is completely valid (and I think another mechanism, like `@scope` could be better), being able to selectively expose layers almost like named slots for external styles is quite valuable. It’s worth exploring how this can be done in a way that allows a consumer to be selective about which of their styles need to affect what in a shadow root while keeping those styles isomorphic: still useful for their own context (i.e. you aren’t needing to write duplicates of your styles specifically for the shadow root). Layers are context-specific conventions, so some care needs to be taken here.

[1]: https://github.com/w3c/csswg-drafts/issues/9792

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

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