Re: [w3ctag/design-reviews] Declarative CSS Modules and Declarative Shadow DOM `adoptedstylesheets` attribute (Issue #1000)

We reviewed this today in a breakout and while we agree that this use case needs to be solved, we think there might be a way to tweak or to finish implementing some more-general features to solve the use cases, so that we wouldn't need to add features that are specific to web components.

It seems that this is solving two problems:
1. Sharing of styles across shadow roots
2. Defining those styles inline in the containing HTML file

For the first problem, the [reasoning](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/ShadowDOM/explainer.md#using-relstylesheet-attribute) listed for why `<link>` or `@import` cannot be used for sharing styles across shadow roots is simply that they cause additional network requests. Minimizing network requests also seems to be the core of the reason to use ESM-style CSS imports.

In that case, perhaps the issue can be addressed at the root, by specifying that these requests MUST be deduplicated, either by default (if web compatible) or with a certain flag set. It appears that in most cases UAs deduplicate these anyway, and in cases where they don't, that's not consistent (e.g. @Westbrook shared https://q9yc7v.csb.app/ which causes multiple requests in Chrome but not in Safari), which is encouraging in terms of web compat. **Fixing the underlying problem benefits not just web components, but the entire platform at large.**

Btw it's incorrect to say that
> Inline `<style>` blocks do not support `@import` rules

I have personally used inline `<style>` with `@import` rules regularly, even in shadow roots (see https://elements.colorjs.io/src/color-picker/). Are you talking about a more specific case they don't work with? E.g. constructible or adopted stylesheets?

To allow these styles to be defined inline, [`@sheet`](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/ShadowDOM/explainer.md#sheet) seems like a better solution. Using `<script>` for CSS, with specifiers that mimic filenames, seems like a disproportionate level of complexity for the problem being solved, and contorts existing primitives into doing things they were never meant to do. That is, `adoptedStylesheets="sheet1, sheet2"` seems better than `adoptedStylesheets="/invented_filename1.css, /invented_filename2.css"`. The main drawback listed in the explainer for `@sheet` is lack of implementations, which seems moot given this is also not implemented? 

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1000#issuecomment-2433471327
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1000/2433471327@github.com>

Received on Wednesday, 23 October 2024 21:11:39 UTC