Intent to Implement: CSS Modules V1
Daniel Clark
Intent to Implement: CSS Modules V1
Contact emails
dan...@microsoft.com, sase...@microsoft.com, tra...@microsoft.com, pc...@microsoft.com, gw...@microsoft.com
Design doc/Spec
Explainer: https://github.com/w3c/webcomponents/blob/gh-pages/proposals/css-modules-v1-explainer.md
The Synthetic Modules Design Doc describes how CSS modules will be implemented using Synthetic Modules. See in particular the ModuleScriptLoader section.
TAG Review: https://github.com/w3ctag/design-reviews/issues/405
Summary
CSS modules are another type of module script alongside JavaScript and JSON module scripts. CSS module scripts are fetched in the same way as other module
scripts, e.g. with "cors" mode and using strict MIME type checking. They share the same module import syntax, e.g.
import styles from "./styles.css ".
The CSSStyleSheet parsed from the fetched file is provided as the module's single default export, with parse errors checked before instantiating the module graph.
Motivation
Current solutions for including CSS in component definitions are lacking; they suffer from one or more of the following rough edges:
- Side effects like appending <style> elements to the document. If this is done in the top-level scope of the document then it breaks shadow root style scoping. If it is done inside a shadow root then each individual instance of the component must include its own <style> element in its shadow root instance.
- Inlined CSS text as a string in JavaScript. This is not optimally performant (it's processed by both the JS and CSS parsers) and is a poor developer experience.
- Dynamically fetch()ing CSS is generally not statically analyzable and requires careful dependency management by the developer for complex applications.
See GitHub thread here for additional design discussion and use cases: https://github.com/w3c/webcomponents/issues/759
Risks
Interoperability and Compatibility
The initial implementation of this feature will be behind an experimental flag. Prior to shipping by default, we’ll confirm support from other browser vendors and drive the standardization of the feature in the HTML spec.
Edge: Public support; Microsoft will drive the Blink implementation.
Firefox: No definite signals
Safari: No signals
Web / Framework developers: Generally positive responses in the GitHub Issue thread and some positive engagement on Twitter e.g. in the responses to this thread.
Ergonomics
We expect the feature to be commonly used in tandem with JavaScript modules (and potentially other module types yet to come).
The feature will be built on Synthetic Modules as part of the existing module graph infrastructure so we don't expect any new performance issues.
Activation
Since the feature shares the existing modules syntax and infrastructure we expect that developers already familiar with ES6 modules will have very little difficulty learning and taking advantage of the feature.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Link to entry on the feature dashboard
https://www.chromestatus.com/feature/5948572598009856
Requesting approval to ship?
No