[TPAC Prep] CSS modules

[o-t-w]

This is a summary of the current status of CSS modules

CSS Module Scripts allow JavaScript modules to import style sheets. They can then be applied to a document or shadow root using adoptedStyleSheets in the same way as constructable style sheets.

import styles from "./styles.css" with { type: "css" };
document.adoptedStyleSheets = [styles];

Motivation

• Many developers want to write their CSS in separate .css files, rather than as strings in JavaScript. That is possible today using a <link> tag, but that approach is not recommended.
• CSS modules will allow styles to be loaded in component definitions without adding <style> or <link> elements that need to be created in each element instance.
• Without CSS-in-JS it's difficult to ensure that CSS is loaded before the component is defined and rendered. CSS module scripts provide the same ordering guarantee.
• Component authors may need to import a resource that is only available as an external .css file, and don't have control over the resource to wrap it in a JS module.

For further motivational details, see this explainer document: webcomponents/css-modules-v1-explainer.md at gh-pages · WICG/webcomponents.

I've recently written about the import attributes here.

Open issues

There is one open issue: define behavior of @import in CSS modules

There is an open pull request for updating the HTML spec which would resolve the remaining issue about import attributes.
Seeing as CSS modules are unlikely to land until JSON modules land, these two open PRs are also relevant:

• Add "json" destination, for JSON modules whatwg/fetch#1691
• Add "json" destination for "connect-src" webappsec-csp#611

Browser support

CSS modules have two prerequisites: constructable stylesheets and import attributes.

Constructable stylesheets are supported in all browsers.

An older syntax of import attributes, then known as import assertions, shipped in Chrome 91. An update to the syntax is currently implemented in Chrome Canary behind a flag. Support for the older syntax is not being removed from Chrome.

Chrome 93 added support for CSS modules.

Firefox are currently working on support for import attributes, but will start with JSON modules and ship CSS modules at a later date.

WebKit position
A PR has been merged adding support for import attributes.
No developers are currently assigned to the WebKit implementation of CSS modules.

Multiple stylesheets per file

Currently, when using CSS module scripts in Chrome, every CSS import makes a separate HTTP request. Allowing multiple stylesheets within a single CSS file would allow bundlers to merge all the CSS into a single file. The stylesheets would then be available as named exports.

import {sheet1, sheet2} from './styles1and2.css' with {type: 'css'};

In April the CSS working group discussed this proposal and resolved "Accept @sheet with URL fragment referencing rule. Exact details to be in the Cascade spec". It will be part of the CSS Cascade Level 6 specification but has not been added yet. There are no open issues.

It would be worth fleshing out the use-case and benefit for this feature outside of web components. Given that PostCSS can already concatonate @import statements into a single CSS file, and use of multiple stylesheets per file would still make use of a build tool to create the single file, the benefit isn't too clear.

Related specs and proposals

• Declarative CSS module scripts

[Westbrook]

Great intro to this as a spec. Would you be able to share some specifics around the use case this unlocks and why it is valuable?

An overview of the status/blockers on whatwg/html#7233 would be helpful in outlining for implementors the work we’d ask for them here.

Also, I’m a big fan of the capabilities outlined by w3c/csswg-drafts#5629. Do you have any thought on that being a part of the work needed to call this “done”?

[o-t-w]

I don't think the rationale or use case has changed since the previous report, so I've basically copied that over.
I've added a bit of info about the current status of whatwg/html#7233 and w3c/csswg-drafts#5629. I don't think anything about whatwg/html#7233 is actually contentious, the PR just needs the addition of tests as far as I can tell.