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

> It is precisely my concern that you think this should be pretty trivial, but I claim that it's really really not

@dfabulich we have a lot of experience building polyfills for these features, including Shadow DOM with and without style scoping, CSS custom variables, JS and HTML modules, and a few prototypes for Constructible Stylesheets. We also have a limited version of the transform (for slightly different semantics) in use at Google.

I think we have a very good idea of what this entails, and the transform for CSS modules is quite simple, especially compared to the polyfills we've build before.

I'm a firm believer in layering for polyfills, so the transform would be based on Constructible Stylesheets so that 1) we have optimal perf in Constructible Stylesheets supporting browsers 2) can work on-top of any Constructible Stylesheets polyfill, and 3) we enable all the use-cases like `adoptedStylesheets`.

And like most polyfills, there will likely be multiple competing implementations and better techniques will be discovered and used if they exist. I advocate for new APIs to consider polyfill-ability, and I'm very confident that this proposal is easily and efficiently polyfillable by a build-time tool.

Dropping `@import` from v1 allows us to start getting the tools ecosystems to add support while the decision is worked on.

> as the bundler will have to flatten all @imports together and let the browser download all of the imported rules, whether they're needed or not.

You can easily construct `@import` supporting transforms that do not duplicate 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-520618493