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

`import styles from './styles.css';` is not yet standardized, so you only know what it does now if you're using a particular tool. There are a number that utilize that same syntax with slightly different behavior:

- [CSS Modules](https://github.com/css-modules/css-modules) The tool you're familiar with
- [Webpack CSS loader](https://github.com/webpack-contrib/css-loader#modules) Defaults to *not* implementing the CSS Modules tool's behavior.
- [rollup-plugin-postcss](https://github.com/egoist/rollup-plugin-postcss) Also defaults to not implementing the CSS Modules tool's behavior.
- [Parcel](https://parceljs.org/css.html): Same, though also might have slightly divergent behavior from CSS Modules according to their docs.

These are just a few of the tools, but they do have some commonalities:
 - They were created before JS modules were implemented in browsers. Design choices could naturally be different after this.
 - They completely omit the import statement from the output, so they don't use any native loading. **Adding native loading will not interfere with them.**
 - They are opt-in and configured at the use site. Packages rarely publish JS modules with CSS imports in them - they transform them out ahead of time. Native loading
 - They are side-effectful. They all append a stylesheet to the main document. That's not a behavior we'd want in the JS module system where modules are by default side-effect free, unless code in them has a side-effect.
 - They assume a single global scope and so are incompatible with `adoptedStyleSheets` and shadow DOM.
 - They allow for importing class names into JS, which is a use case we _do_ want to cover eventually, and definitely not prevent in the meantime. I mention this in the original text of this proposal, and have made the [CSS References proposal](https://github.com/w3c/csswg-drafts/issues/3714) to cover this case natively. Tools (and hand-written JS modules) can also provide those exports like I've shown above.

All-in-all I think this capability will be a huge _boon_ to the userland solutions which will now have a standardized compile target. Packages can use a tool's proprietary semantics, but transform to standard semantics before publishing. This will unlock many packages to publish standard JS modules to npm.

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