Re: [w3c/webcomponents] CSS Modules (#759)

> With my user hat on, I think option 3 is preferable because it maps to the module loader behavior better.

**If** we assume that CSS's `@import` rule is directly analogous to the JS `import` statement. Today it's definitely not; linking in a stylesheet multiple times does fresh requests for each of its `@import` rules and constructs independent CSSStyleSheet object for them.

This would be changing the behavior of `@import` in a way that can't be reproduced manually; there's no way to cause two stylesheets to share a single child stylesheet with the CSSOM as it stands.

> This is analogous to JS Modules as well. import has the advantage that when a module is imported multiple times there's only one module instance.

JS and CSS have significant divergences here: 
* JS can have significant side effects upon loading, so limiting that to the first instance can be good, while CSS doesn't.
* JS commonly shares mutable global state across a module, and having multiple instances use the same state is usually what you want, while CSS has virtually no stylesheet-global state (just `@namespace`; nothing usefully mutable)
* stylesheet importing isn't as semantically significant as module importing; When A.js imports B.js, B is typically a separate *thing* semantically, but when A.css imports B.css, B.css is basically treated like it was just inlined into A.

Can you explain any particular advantage that having imported stylesheets sharing an `@import`ed stylesheet would provide?

> Much like document.currentScript is set to null for modules, parentStyleSheet and ownerRule can be null for CSS modules.

The question was what the `.parentStyleSheet` and `.ownerRule` would be for the `@import`ed sheet, if it's shared between two `import`ed sheets. That probably shouldn't be null, but it can't correctly be just one of the two sheets.

----

All in all, it looks like Option 3 (treat `@import` like a JS `import`, deduping same-url imports) would give us a brand new behavior for nested stylesheets which *cannot be reproduced by hand*, and would also have some awkward interactions with the existing CSSOM APIs which expect a tree structure with two-way links. I've come to strongly feel that Option 3 is definitely the wrong choice, and that we should be using Option 2 (the "`import "foo.css"` just fetches the sheet and constructs a CSSStyleSheet from its text" option).

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