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

Re: https://github.com/WICG/webcomponents/issues/909#issuecomment-1949162507
> Component user could specify:
>
> `<custom-c adoptstyles="custom-addition.css" />`
> 
> Same API in lightDOM or shadow all the way down.

The problem with an approach that uses an attribute is that you would need to apply that attribute on *every single element* you want those styles applied to which recreates the problem of using the `style` attribute for styling. For some use cases, namely where the page author and component author is the same, that would be a non-starter since they likely want to use their styling system for everything.

(Sorry for the *book* you’re about to read…)

A CSS solution that is selector-based and layer-based would be much better since:

- **Page authors** could decide which elements they want their styles to apply to. Also, they’re in the best position to know at what point in their CSS architecture (i.e. document’s cascade) that a component needs to be integrated at.
- **Component authors** could decide if they want to accept styles at all and, if they do, at which points in their own cascade they want those styles to apply.

A layer-based solution ([initial proposal](https://github.com/WICG/webcomponents/issues/909#issuecomment-1883480640); [CSSWG proposal](https://github.com/w3c/csswg-drafts/issues/9792)) highlights concepts already at play within Shadow DOM styling, even if most developers are unaware of them. The relationship between a shadow root and its host’s context is that of two layers (or contexts): an inner one which is cascaded first and an outer one which is cascaded after. This is largely not understood and what trips up many developers. *(No, your `:host`, `::slotted()`, or `[part]` styles don’t have lower specificity: they’re in a different layer of the cascade—specificity doesn’t matter between layers.)*

Layers also help us to think more about what we’re trying accomplish:

1. Am I trying to change the styles of the building blocks a component is using?
 - Currently these styles are limited to the user agent and to any shadow root styles for custom elements used in the component’s shadow tree.
  - This is a pain point: if I want to affect this layer of styling it means I must already have modularized the building blocks I want to provide (and the component needs to have knowledge of them—which could be done with a community protocol).
2. Am I trying to change the component itself (i.e. its internal styling system) and therefore every instance of the component?
3. Am I trying to change a concrete usage of the component within another composition?
 - This is the realm of styling we already have access to with the public styling APIs provided by the component (e.g. the element itself, `::part()`, slotted content, `:state()`).  Those APIs really shine for this realm of styling (and, sure, they can still improve). I think we’re disappointed with them, because we’re trying to use them to accomplish styling tasks from the prior two categories (e.g. providing button styles to a component with `::part()` or as slotted content—you’re not giving the component *defaults* styles, it’s providing you with defaults). Improve the styling story for the first two categories and I think we’ll really start to appreciate the *more declarative* styling APIs that are the product of style encapsulation.

Layers also help us understand the cost of what we’re doing. If I’m using the public styling API of a component, that doesn’t require me to understand how the internals work very deeply and the API should be less prone to break. If I’m setting styles for the default elements a component uses or changing how the component works internally, I should expect increased cost in regard to maintenance. And the great thing is that that code is grouped together which only improves the maintenance experience.

- - -

**As for a combinator or selector that forms relationships across shadow boundaries, I think that’s something we should take some more time to consider: it doesn’t need to hold up a solution for allowing external styles to apply to a shadow root.** Relationships across shadow boundaries are actually a mush broader problem. For example, it seems `:host-context()` is in a half-decade long process of being dropped from the spec. `:is()` and `:has()` are not supposed to work for matching ancestors or descendants at shadow boundaries for `:host()` or `::part()` (even if they currently do in some browsers). It is clear that there needs to be some higher level discussions about how and if these relational selectors should work in general.

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

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