Intent to Implement: CSS Modules V1

2216 views
Skip to first unread message

Daniel Clark

unread,
Aug 12, 2019, 12:52:00 PM8/12/19
to blin...@chromium.org, Travis Leithead, Bo Cupp, Greg Whitworth, Sam Sebree

Intent to Implement: CSS Modules V1

 

Contact emails

dan...@microsoft.comsase...@microsoft.comtra...@microsoft.compc...@microsoft.comgw...@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

 

 

Reply all
Reply to author
Forward
0 new messages