Re: [WICG/webcomponents] Declarative CSS Module Scripts (#939)

justinfagnani left a comment (WICG/webcomponents#939)

I've been trying to communicate more clearly that this feature should not be tied to DOM structure or shadow root scopes, because what we're attempting to do is serialize JS references, so I made this live example showing the type of client-side structure that we need to SSR, and how shared styles do not conform to any particular DOM layout:

https://stackblitz.com/edit/declarative-shared-css-stylesheets-example?file=index.html

I think the main point is that we have JS lines like this:

```ts
import sharedStyles from '../styles/shared-styles.css' with {type: 'css'};

const styles = new CSSStyleSheet();

// In a custom element:
this.shadowRoot.adoptedStyleSheets = [sharedStyles, styles];
```

And we need to serialize that shadow root with those styles, and any other shadow roots that use those styles too. Since JS references can flow to just about anywhere in the app, there is no relationship between them and the structure of nested shadow roots. And since shadow roots directly reference these stylesheets client-side, it is not an encapsulation violation to let them reference them in HTML.

I think the big mental challenge here seems to be that serializing JavaScript references is inherently less strict than the references behave in JS. In JS we cannot forge a reference to an arbitrary object. Once you have a serialization format, you possibly can. SSR systems could use GUIDs or content digests to make unguessable references, but it's difficult to require and validate that they did so. I also think that this is fine. We aren't allowing arbitrary JS references to be serialized, just those to StyleSheet objects.

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

Message ID: <WICG/webcomponents/issues/939/2877560623@github.com>