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
Search tags
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?
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.
--
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
Thomas Steiner
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?
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
> 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.
Anne van Kesteren
>
> 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
--
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
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
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.
Westbrook Johnson
Daniel Ehrenberg
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
Yoav Weiss
>>> 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
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
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.