- From: Wii <notifications@github.com>
- Date: Thu, 21 Mar 2024 04:25:22 -0700
- To: WICG/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <WICG/webcomponents/issues/909/2012007424@github.com>
@mirisuzanne Thank you for that explanation. Looking at it that way, it makes sense how `@layer` might be a bad choice for narrowing down which styles to pull into a shadow-dom. My personal mental model of "layers" is that in practice they end up representing something like "phases" of styling: *first we reset browser defaults, and get to some neutral state; then we apply a framework, and get to a basic styled state; then we apply site-wide styles, and get to an overall finished page; then we might add some more specific layers based on what page we're on, etc.* In that sense, it makes sense to express a concept like "Take the resets and the framework styles from the light dom, but not the other stuff" using `@layer` names. `@sheet` seems like a good alternative for this, at least on a conceptual level, although at a glance it seems like it could end up lacking some relevant features. The first thing that comes to mind, without having read the whole proposal yet: It would be useful, if not essential, to name a sheet when `<link>`ing it directly from the HTML, otherwise we might end up with situations like "*I want to tell this component to only pull resets, but my `resets.css` is just linked in the HTML, so now I have to change my HTML and wrap it in a `<style>` block, or worse, edit the `resets.css` itself and wrap the entire content in a `@sheet` rule*", which I would find very undesireable both as a user and author of components. As a more general design consideration for this feature, one could phrase it like this: *Using a web component should not dictate or narrow down how page authors can organise their CSS* ----- Also, please note that this applies to the selection of which styles to inherit; it has nothing to do with the requirement to wrap inherited styles in a layer *inside* the shadow-dom, as that really is just a matter of handling cascade specificity (in the most common case, making sure no inherited styles end up overriding inner styles of the shadow-dom) -- Reply to this email directly or view it on GitHub: https://github.com/WICG/webcomponents/issues/909#issuecomment-2012007424 You are receiving this because you are subscribed to this thread. Message ID: <WICG/webcomponents/issues/909/2012007424@github.com>
Received on Thursday, 21 March 2024 11:25:26 UTC