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

> linking in a stylesheet multiple times does fresh requests for each of its @import rules 

Is this always true? Didn't @bzbarsky just say that Firefox doesn't do this?

If this should always be true, then it seems like a big knock against `@import` in CSS modules. You wouldn't want a bunch of CSS modules to _ever_ `@import` a common stylesheet because you'd cause multiple fetches. Imagine 100 components that `import` 100 different component-specific CSS modules that each `@import` a few common stylesheets. That's a few 100 extra fetches.

Maybe we should disallow `@import` in that case, and treat CSS modules as if the called `replaceSync`? It wouldn't seem to behave how developers using modules would expect otherwise.

> 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

Isn't the stylesheet itself the stylesheet-global state?

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

I thought I did with the `base.css` example - mutating a common stylesheet object seems like a reasonable way to switch themes across ShadowRoots. It's the only way I can see that doesn't involve getting every component to opt into some out-of-band system, in addition to loading a base CSS module.

Let's frame the example another way:

theme.js
```js
import styles from './base.css';

export function switchTheme(url) {
  styles.replace(await (await fetch(url)).text()));
}
```

element.css
```js
@import './base.css';
```

element.js
```js
import styles from './element.css';

class MyElement extends HTMLElement {
  constructor() {
    super();
    this.attachShadow().adoptedStylesheet = [styles];
  }
}
```

It would be great if this worked. And not just for theme switching in an app, but for visual design tools and IDEs with live previews. Otherwise it does seem to discourage use of `@import`, which would be bad because there's no other way to have CSS modules load dependencies.



-- 
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-490692275