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

I don't know where to appropriately have this conversation, but I'm very worried about the migration path to this thing from the existing technology called "CSS Modules." https://github.com/css-modules/css-modules

To differentiate between the proposal here and the existing "CSS Modules" thing, I guess I'll call the existing thing "ICSS Modules," since (as an implementation detail) they compile to so-called [Interoperable CSS](https://github.com/css-modules/icss) files.

ICSS modules and CSS Modules V1 sound identical (they're both just called "CSS Modules") but they behave completely differently.

* ICSS modules mangle class names for scoping; CSS Modules V1 returns a CSSStyleSheet, which has to be attached to a shadow DOM root in order to have any scoping.
* ICSS modules export a mapping of class names to mangled names, allowing a tree-shaking algorithm to drop unimported ICSS rules. CSS Module V1 returns a big old CSSStyleSheet object, which the user would then attach in bulk.
* ICSS modules work great with server-side JS, allowing developers to return plain HTML + CSS with no client-side JS required for rendering. I can't see how a CSSStyleSheet could be used on the server side at all.
* ICSS modules are popular, and developers have been asking (perhaps naively) for native browser support for "CSS Modules" for years, in the same naive way that they wish for JSX built-in to the browser. This proposal is not at all what they meant.

Then there's the naming conflict. Imagine trying to Google for this: "How do I port my code from CSS modules to CSS modules?"

If I may be so bold as to speak for the many, many developers who never use Shadow DOM and never plan to start using it, it seems like this proposal is just going to make our lives worse.

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