- From: Lea Verou via GitHub <sysbot+gh@w3.org>
- Date: Mon, 30 Sep 2024 19:14:39 +0000
- To: public-css-archive@w3.org
We discussed this a fair bit during breakouts with @emilio @rniwa during TPAC, and we'd love to hear from @tabatkins and @fantasai. Currently, `::slotted()` is practically near-useless, as even CSS resets from the host page override component styles. I thought #7922 would fix this, but on its own it’s not enough: the core problem is this cascade order rule that defines that *all* shadow CSS has lower precedence than *all* light DOM CSS unless `!important` is used. In my experience, you typically want more granularity than the all-or-nothing of the current situation: you don’t want component styles to override author styles specifically targeting those elements, but also you don't want generic catch-all author rules like `ul` to override component rules applying styles to e.g. lists within that specific component. Also, specificity can be more granularly tweaked either up or down, whereas there is no recourse when a cascade order rule that sits above specificity doesn't do what you want. Intuitively, it seems that the kind of cascade order that would make sense here is to treat encapsulation context at the same precedence level as source order. @emilio's proposed "important layer" concept seems useful in its own right, but would have similar problems as `!important` if it were the only solution to this problem. Fixing this may require an opt-in of some sort (possibly as a `ShadowRootInit` option), since at this point these selectors are used widely enough that fixing this could be a breaking change. Alternatively, if we see that `::slotted()` is used sufficiently infrequently, we could simply define `::part()` as having very high (or even infinite) specificity. I suspect that will be a no-go however. -- GitHub Notification of comment by LeaVerou Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6466#issuecomment-2383968255 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 30 September 2024 19:14:40 UTC