Intent to Ship: CSS module scripts

[Daniel Clark]

Contact emails

dan...@microsoft.com, pc...@microsoft.com, tra...@microsoft.com

Explainer

https://github.com/w3c/webcomponents/blob/gh-pages/proposals/css-modules-v1-explainer.md

Specification

https://github.com/whatwg/html/pull/4898/

Design docs

Explainer: https://github.com/WICG/webcomponents/blob/gh-pages/proposals/css-modules-v1-explainer.md
This design doc covers how the feature was implemented using Synthetic Modules: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/SyntheticModules/designDoc.md

Summary

CSS Module Scripts are an extension of the ES Script Modules system that allows web developers to load CSS into a component definition in a manner that interacts seamlessly with other module types:

 

import styleSheet from "./styles.css" assert { type: "css" };

Blink component

Blink>HTML>Script

Search tags

css, module, import

TAG review

https://github.com/w3ctag/design-reviews/issues/405

TAG review status

Issues addressed

Risks

Interoperability and Compatibility

There isn't yet consensus on how @import should work in CSS modules. To prevent future future compatibility problems, for now @imports in CSS modules will be ignored (and will issue a console warning) to prevent developers from taking dependencies on them. When consensus is reached on how these should work, the functionality will be added in future changes. See https://github.com/WICG/webcomponents/issues/870.

Gecko: No signal Awaiting response to https://github.com/mozilla/standards-positions/issues/541, but expected to be Positive based on prior conversations.

WebKit: No signal Awaiting response to https://lists.webkit.org/pipermail/webkit-dev/2021-June/031901.html

Web developers: Positive (https://github.com/WICG/webcomponents/issues/759) Very positive feedback in the original GitHub issue https://github.com/WICG/webcomponents/issues/759. Lit developer community is strongly in favor.

Ergonomics

We expect CSS module scripts to be commonly used in tandem with JavaScript and JSON modules (and potentially other module types yet to come). The feature is built on Synthetic Modules as part of the existing module graph infrastructure so we don't expect any new performance issues.

Activation

Build tools and polyfills may be useful for adoption as import assertions and CSS modules roll out across various browser platform implementations.

Security

CSS module scripts only work with a type: "css" import assertion (https://github.com/tc39/proposal-import-assertions), preventing the MIME type security issue described in https://github.com/WICG/webcomponents/issues/839. Aside from that, this feature does not have any particular security concerns. The feature shares the same behaviors as JavaScript modules with respect to CORS etc.

Debuggability

No special debuggability support needed.

Is this feature fully tested by web-platform-tests?

Yes, see https://wpt.fyi/results/html/semantics/scripting-1/the-script-element/css-module?run_id=5199279083749376&run_id=5673011829014528&run_id=5752753198465024&run_id=5695660181422080

Flag name

--enable-blink-features=CSSModules

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=992499

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5948572598009856

Links to previous Intent discussions

Intent to implement: https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/vCrJCQxNnzo/m/OAYI9cPWAQAJ

This intent message was generated by Chrome Platform Status.

 

[Mathias Bynens]

Debuggability: No special debuggability support needed.

IMHO at a minimum, we should ensure that styles imported through this new mechanism can be viewed and edited through the DevTools Styles panel. It looks like this already works, although the styles show up as “constructed stylesheet”, and there is no pointer to their source *.css module file. I’ve filed https://bugs.chromium.org/p/chromium/issues/detail?id=1219441 for this.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/MW2PR00MB0441F9F7B8BD265447C6FD01C5349%40MW2PR00MB0441.namprd00.prod.outlook.com.

[Daniel Clark]

Thanks Mathias for pointing out the DevTools issue. I left some initial comments in the bug and will explore a fix.

[Artur Janc]

Hi Daniel,

You mentioned requiring import assertions with a `css` type above, but I noticed that the examples in the explainer (https://github.com/WICG/webcomponents/blob/gh-pages/proposals/css-modules-v1-explainer.md) don't use assertions. Is it just because the explainer is out of date and hasn't incorporated the import assertions changes?

Also, I assume CSS modules by default are loaded in `cors` mode and that we're planning to have strict MIME type checking to ensure that anything that's not `text/css` cannot be loaded as a CSS module; can you confirm this?

Cheers,

-Artur

[Thomas Steiner]

On Tue, Jun 15, 2021 at 2:24 PM 'Artur Janc' via blink-dev <blin...@chromium.org> wrote:

You mentioned requiring import assertions with a `css` type above, but I noticed that the examples in the explainer (https://github.com/WICG/webcomponents/blob/gh-pages/proposals/css-modules-v1-explainer.md) don't use assertions. Is it just because the explainer is out of date and hasn't incorporated the import assertions changes?

I have a PR open for this: https://github.com/WICG/webcomponents/pull/932. 

[Daniel Clark]

> You mentioned requiring import assertions with a `css` type above, but I noticed that the examples in the explainer (https://github.com/WICG/webcomponents/blob/gh-pages/proposals/css-modules-v1-explainer.md) don't use assertions. Is it just because the explainer is out of date and hasn't incorporated the import assertions changes?

 

Yes, the explainer is out-of-date. Last week I created this to update it; just waiting on approval: https://github.com/WICG/webcomponents/pull/931

 

> Also, I assume CSS modules by default are loaded in `cors` mode and that we're planning to have strict MIME type checking to ensure that anything that's not `text/css` cannot be loaded as a CSS module; can you confirm this?

 

This is correct. CSS modules use `cors` mode and have strict MIME type checking, the same way as JavaScript modules.

 

From: Thomas Steiner <to...@google.com>
Sent: Tuesday, June 15, 2021 5:26 AM
To: Artur Janc <a...@google.com>
Cc: Daniel Clark <dan...@microsoft.com>; blin...@chromium.org <blin...@chromium.org>; yan...@google.com <yan...@google.com>; Changhao Han <chang...@google.com>; Mathias Bynens <mt...@google.com>
Subject: Re: [blink-dev] Intent to Ship: CSS module scripts

 

On Tue, Jun 15, 2021 at 2:24 PM 'Artur Janc' via blink-dev <blin...@chromium.org> wrote:

[Artur Janc]

On Tue, Jun 15, 2021 at 4:16 PM Daniel Clark <dan...@microsoft.com> wrote:

> You mentioned requiring import assertions with a `css` type above, but I noticed that the examples in the explainer (https://github.com/WICG/webcomponents/blob/gh-pages/proposals/css-modules-v1-explainer.md) don't use assertions. Is it just because the explainer is out of date and hasn't incorporated the import assertions changes?

 

Yes, the explainer is out-of-date. Last week I created this to update it; just waiting on approval: https://github.com/WICG/webcomponents/pull/931

 

> Also, I assume CSS modules by default are loaded in `cors` mode and that we're planning to have strict MIME type checking to ensure that anything that's not `text/css` cannot be loaded as a CSS module; can you confirm this?

  

This is correct. CSS modules use `cors` mode and have strict MIME type checking, the same way as JavaScript modules.

Great, thanks for the clarification! 

[Anne van Kesteren]

On Fri, Jun 11, 2021 at 10:26 PM 'Daniel Clark' via blink-dev
<blin...@chromium.org> wrote:

> Specification
>
> https://github.com/whatwg/html/pull/4898/

That PR is both old and marked as draft. I would be a lot more
comfortable with this shipping if it was more-or-less ready to land,
or even better, had landed.

[Mike West]

I think that this is a pretty reasonable thing to ship, but I agree with Anne that the details of the integration in HTML need to be worked out to a level that we can rely upon. This also came up in https://github.com/mozilla/standards-positions/issues/541#issuecomment-860896685. I don't think the PR needs to have landed, but given that it hasn't moved since Oct. 2020, I'd like to see more of the open questions answered (and locked in with tests) before moving forward so that we're confident that the spec won't shift out from under us.

Would you mind taking another look at that integration point, Daniel?

-mike

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADnb78hRCZsbzxq9frq_qSGxC0525-raMSRN26u745KT0znk6A%40mail.gmail.com.

[Yoav Weiss]

Beyond the valid point on the state of the PR, I'd like to better understand how developers will be using this.

Asking around, I hear a lot of developer enthusiasm around this as a replacement for current "CSS in JS" practices, but I'm curious as to how loading would work here. 

Are we expecting developers to import CSS from the JS, resulting in delayed discovery (where the JS needs to be downloaded and parsed before the CSS is discovered - I'm assuming parsing is enough for static imports)? 

Are we expecting them to use bundlers and this would mostly be an authoring-time tool? 

Are we waiting for WebBundles to save us?

More clarity on that front would be highly appreciated :)

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DdQyvt%2BKKveHZK3bWZbVQOhzYhw%3DaCczJggUzGb0NDcyQ%40mail.gmail.com.

[Daniel Clark]

I’ll work on addressing those open issues in the HTML spec PR. I see that Mason’s PR https://github.com/w3c/csswg-drafts/pull/6304 merging constructable stylesheets into the CSSOM just landed a couple days ago, so that should make it a bit easier to handle the open issues around the integration with the constructable stylesheets spec.

 

Yoav, regarding the questions about loading, I think the story on this is pretty similar to the state of things for JavaScript modules today. We are indeed expecting developers to import CSS from the JS, so the delayed discovery happens with the same timing as a nested JS module import.  There’s a sort of waterfall where the top-level module is fetched and parsed, and then another fetch is kicked off for its imports (both CSS and JS), and this recurses etc.

 

Like with JS modules, I expect bundlers to be used to smooth over performance issues with this delayed discovery in production. Long-term, advancements like WebBundles should reduce the need for this. Short-term, I think there’s still a lot of value in being able to import CSS like this natively in the browser.

 

The expectation is that this will be a very common way of importing CSS in web component definitions (some of the problems with current ways of doing this are discussed here). So being able to use the feature directly in the browser without extra tooling will be very useful. If I’m a new developer learning how to use web components, it’s better if I can put together a web component, using best practices for including my CSS, without needing to set up extra tooling. Or even if I’m an experienced developer writing a web component, the further I can go without involving a build step in my development loop, the better.

 

-- Dan

 

From: Yoav Weiss <yoav...@chromium.org>
Sent: Thursday, June 17, 2021 6:50 AM
To: Mike West <mk...@chromium.org>
Cc: Anne van Kesteren <ann...@annevk.nl>; Daniel Clark <dan...@microsoft.com>; blin...@chromium.org
Subject: Re: [blink-dev] Intent to Ship: CSS module scripts

 

Beyond the valid point on the state of the PR, I'd like to better understand how developers will be using this.

[Yoav Weiss]

On Fri, Jun 18, 2021 at 3:22 AM Daniel Clark <dan...@microsoft.com> wrote:

I’ll work on addressing those open issues in the HTML spec PR. I see that Mason’s PR https://github.com/w3c/csswg-drafts/pull/6304 merging constructable stylesheets into the CSSOM just landed a couple days ago, so that should make it a bit easier to handle the open issues around the integration with the constructable stylesheets spec.

 

Yoav, regarding the questions about loading, I think the story on this is pretty similar to the state of things for JavaScript modules today. We are indeed expecting developers to import CSS from the JS, so the delayed discovery happens with the same timing as a nested JS module import.  There’s a sort of waterfall where the top-level module is fetched and parsed, and then another fetch is kicked off for its imports (both CSS and JS), and this recurses etc.

 

Like with JS modules, I expect bundlers to be used to smooth over performance issues with this delayed discovery in production.

Unlike JS modules, I'm not 100% sure what that would look like and if that can avoid the extra RTTs. Do you have a sense of if/how bundlers could create a single bundle from a mix of JS and CSS (and other) modules?

Have y'all talked to the bundler community?

 

Long-term, advancements like WebBundles should reduce the need for this. Short-term, I think there’s still a lot of value in being able to import CSS like this natively in the browser.

 

The expectation is that this will be a very common way of importing CSS in web component definitions (some of the problems with current ways of doing this are discussed here). So being able to use the feature directly in the browser without extra tooling will be very useful.

I agree that it can be very useful at authoring time.

 

If I’m a new developer learning how to use web components, it’s better if I can put together a web component, using best practices for including my CSS, without needing to set up extra tooling. Or even if I’m an experienced developer writing a web component, the further I can go without involving a build step in my development loop, the better.

I'm concerned that this would result in a footgun that many developers would reach for, resulting in slower user experiences.

Maybe proper best practices around preload or modulepreload can help here? e.g. "if you're loading a CSS module, add a modulepreload for it (with a "style" `as` value) as part of the HTML that loads the script that does the importing"

Have y'all tried something like that? I guess that can get complicated with dynamic imports, but they are already not great on that front.

[Westbrook Johnson]

> Unlike JS modules, I'm not 100% sure what that would look like and if that can avoid the extra RTTs. Do you have a sense of if/how bundlers could create a single bundle from a mix of JS and CSS (and other) modules?

As a developer we've roughly been doing just this for quite a number of years now via concepts like https://github.com/css-modules/css-modules, https://www.npmjs.com/package/rollup-plugin-lit-css or similar where the imported CSS becomes part of the JS module graph post-build. Updating these techniques to be triggered via import assertions is already in conversation with major tools in this area: https://github.com/rollup/rollup/issues/3799 with more advanced cross bundler considerations like https://docs.google.com/document/d/1BObemtyKibEYKZPuu5YqHlam6gRSA42oqPMnuSGHcTs/edit being looked into. As with so many things, it's a bit of a chicken or egg situation...

Enabling similar capabilities without the build step will not only super charge what's possible at development time, it will open the door to investigating both new user land techniques as well as future specifications that build on top of this one. For instance, this proposal looks to address how to bundle multiple sheets into the same file without munging the content type to JS (https://github.com/w3c/csswg-drafts/issues/5629), but is difficult to fully achieve without first shipping the assertions outlined herein.

[Daniel Ehrenberg]

(Yoav asked me to comment on this thread.)

CSS modules of this form has been much of the point of import
assertions (which I co-championed at TC39) the whole time. I've been
involved in this space for a while, and even wrote the an earlier
version of the HTML PR specifying it.

The mismatch of this approach to CSS modules vs framework developer
expectations is pretty vast, but this could be said about Web
Components in general. I think we should go for this anyway. I don't
see a path to getting cross-browser consensus on something that
matches what web devs are doing today (though this path could get us
closer: https://github.com/w3c/csswg-drafts/issues/3714), and this
approach already does have pretty good cross-browser agreement, and
it's better than what we have today (where stylesheets are often
inefficiently duplicated, or ugly syntax is used, or both).

In particular, this approach to CSS modules fits well with shadow DOM
and poorly with the way people tend to build things today in
mainstream frameworks. I think that this approach should work just
fine with CSS bundlers' existing class synthesis approaches, but I
don't know whether the tooling ecosystem will actually go that way
beyond more certain libraries like lit-element.

I think browser-native bundling *would* save us from this "late
discovery" issue, and that we have a mechanism (albeit ugly) to do
something similar today: moduleprefetch (you're right that we should
make sure to test this).

Overall, shipping this would have more symbolic implications (building
towards HTML modules and WC in general) than immediate practical ones.
Everything with modules on the Web is this way: you just can't use
them yet, and instead you emulate them with tools. Developers have
workflows that take this into account. So, I don't think CSS modules
will make things incrementally worse, as far as loading performance
goes.

Dan

> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXf0d8Avh5BVeUbXmZ7MZ8ej6P372BjyajHyMaKRg8QpQ%40mail.gmail.com.

[Yoav Weiss]

I'm now convinced that the performance risk is low enough and that today's tools are likely to incorporate CSS module output in the same way they currently integrate CSS into ES module flows.

I'm looking forward to WebBundles actually solving this problem for the longer term, but this is not likely to make things worse in the interim, while providing developers with development time conveniences.

At the same time, I urge y'all to be cautious on that front. Please test that this works well with preload and modulepreload, ensure that developer advice on that front is solid and prominent, and work with the JS tooling ecosystem folks to make sure they are properly handling this feature while we all wait for WebBundles.

I was leaning towards LGTMing, but then noticed the PR comments are still pending. Can you bring it to a more "landable" situation?

>>> To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

>>> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADnb78hRCZsbzxq9frq_qSGxC0525-raMSRN26u745KT0znk6A%40mail.gmail.com.
>>
>> --
>> You received this message because you are subscribed to the Google Groups "blink-dev" group.

>> To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

>> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DdQyvt%2BKKveHZK3bWZbVQOhzYhw%3DaCczJggUzGb0NDcyQ%40mail.gmail.com.
>
> --
> You received this message because you are subscribed to the Google Groups "blink-dev" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Daniel Clark]

Thanks Wesbrook and Dan E for adding your thoughts on the performance/bundling question.

 

I’ve brought the HTML spec PR up-to-date with changes from the related import assertions and JSON modules PRs. The remaining open review comments require a bit of refactoring in constructable stylesheets, so I created https://github.com/w3c/csswg-drafts/pull/6411 for that refactoring. As soon as that lands I’ll push a change resolving those comments.

 

The DevTools issues that Mathias pointed out are now fixed in Canary (with https://chromium-review.googlesource.com/c/chromium/src/+/2964539 and https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2964580).

 

-- Dan C

 

From: Yoav Weiss <yoav...@chromium.org>
Sent: Friday, June 25, 2021 12:08 AM
To: blink-dev <blin...@chromium.org>
Cc: Daniel Ehrenberg <litt...@chromium.org>; Mike West <mk...@chromium.org>; ann...@annevk.nl <ann...@annevk.nl>; Daniel Clark <dan...@microsoft.com>; blin...@chromium.org <blin...@chromium.org>; Yoav Weiss <yoav...@chromium.org>
Subject: Re: [blink-dev] Intent to Ship: CSS module scripts

 

I'm now convinced that the performance risk is low enough and that today's tools are likely to incorporate CSS module output in the same way they currently integrate CSS into ES module flows.

>>> To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

>>> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADnb78hRCZsbzxq9frq_qSGxC0525-raMSRN26u745KT0znk6A%40mail.gmail.com.
>>
>> --
>> You received this message because you are subscribed to the Google Groups "blink-dev" group.

>> To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

>> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DdQyvt%2BKKveHZK3bWZbVQOhzYhw%3DaCczJggUzGb0NDcyQ%40mail.gmail.com.
>
> --
> You received this message because you are subscribed to the Google Groups "blink-dev" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Daniel Clark]

Thanks Yoav – the PR comments have now been resolved, if you’d like to take another look: https://github.com/whatwg/html/pull/4898

 

From: Yoav Weiss <yoav...@chromium.org>
Sent: Friday, June 25, 2021 12:08 AM
To: blink-dev <blin...@chromium.org>
Cc: Daniel Ehrenberg <litt...@chromium.org>; Mike West <mk...@chromium.org>; ann...@annevk.nl <ann...@annevk.nl>; Daniel Clark <dan...@microsoft.com>; blin...@chromium.org <blin...@chromium.org>; Yoav Weiss <yoav...@chromium.org>
Subject: Re: [blink-dev] Intent to Ship: CSS module scripts

 

I'm now convinced that the performance risk is low enough and that today's tools are likely to incorporate CSS module output in the same way they currently integrate CSS into ES module flows.

>>> To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

>>> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADnb78hRCZsbzxq9frq_qSGxC0525-raMSRN26u745KT0znk6A%40mail.gmail.com.
>>
>> --
>> You received this message because you are subscribed to the Google Groups "blink-dev" group.

>> To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

>> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DdQyvt%2BKKveHZK3bWZbVQOhzYhw%3DaCczJggUzGb0NDcyQ%40mail.gmail.com.
>
> --
> You received this message because you are subscribed to the Google Groups "blink-dev" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Yoav Weiss]

LGTM1

[Daniel Clark]

Sending a friendly ping to the thread fishing for more LGTMs. It would be great to ship this in 93 but the runway for that is growing short.

 

Thanks!

 

From: Yoav Weiss <yoav...@chromium.org>
Sent: Monday, July 12, 2021 7:47 AM
To: Daniel Clark <dan...@microsoft.com>

[Daniel Clark]

I should also mention that the HTML spec PR has landed: https://github.com/whatwg/html/pull/4898

[Mike West]

LGTM2.

Thank you for doing the work to get the HTML PR over the finish line.

-mike

[Daniel Bratell]

LGTM3

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DePmYnu6g1qCnCQc158Jz5dQGZKYfs5tNGdPFZGYbBgnA%40mail.gmail.com.