Re: [w3c/webcomponents] define behavior of `@import` in Cascading Style Sheet (CSS) modules (#870)

This was discussed in a TPAC breakout session today: https://www.w3.org/2020/10/29-components-minutes.html

We're not really any closer to making a decision on whether an `@import` inside a CSS module should or should not result in the `@import` being itself a CSS module.  As such, we discussed moving forward with a V1 of CSS modules that does not allow `@import`. Shipping the feature, building developer excitement around it, and seeing how it is used in production and gathering feedback could help ensure we arrive at the correct final design choice without risking backwards compatibility problems.

@annevk had a concern that blocking `@import` initially and then opening it up later is potentially problematic, because suddenly imports are allowed to do fetches where they couldn't previously.  The counterpoint to this was that the way browsers do speculative loading means that this sort of thing can already happen, so it's not really a new thing.  So I'm considering that issue to be settled, but please let me know if there are still concerns there.

The remaining question then is how to block `@import`: either fail the module graph if one is present, or ignore it and emit a console warning.

The Constructable StyleSheets spec https://wicg.github.io/construct-stylesheets doesn't appear to have been updated, but @mfreed7's comment [here](https://github.com/WICG/construct-stylesheets/issues/119#issuecomment-642300024) summarizes the state of things after the most recent discussion about this in the CSS Working group (notes inlined in [this comment](https://github.com/WICG/construct-stylesheets/issues/119#issuecomment-597733392)).

Whatever we do with CSS modules should align with the behavior of [`CSSStyleSheet.replaceSync`](https://wicg.github.io/construct-stylesheets/#dom-cssstylesheet-replacesync) and [`CSSStyleSheet.replace`](https://wicg.github.io/construct-stylesheets/#dom-cssstylesheet-replace).  In my opinion, either throwing on `@import` or just ignoring `@import` should be sufficient not to introduce compatibility risks, and not throwing seems to align nicely with 'normal' CSS.  But if one wants to argue that just ignoring `@import` without throwing is too risky, then that argument also applies to `replace()`, where we also may eventually want to support `@import`.  So, one way to move forward could be this:

1. Update https://wicg.github.io/construct-stylesheets so that it reflects the behavior for `replace` and `replaceSync` resolved in the CSSWG (ignore `@import` but don't stop parsing or throw an error).
1. In the [CSS Modules implementation](https://github.com/whatwg/html/pull/4898/), make [`the create a CSS module script`](https://whatpr.org/html/4898/895fd80...3338fff/webappapis.html#creating-a-css-module-script) steps use the `replace` steps in https://wicg.github.io/construct-stylesheets/#dom-cssstylesheet-replace to parse the CSS text and generate the stylesheet object.  This includes failing the module load if `replace` throws an error.  Referencing constructable stylesheets in this way codifies the matching behavior of these features right into the spec.
1. Optionally circle back to the CSSWG to reconsider holistically whether `replace`, `replaceSync`, and CSS modules should all throw an error on `@import` instead of ignoring.  Any change here would be applied to the constructible stylesheets spec, and CSS modules would get the new behavior automatically.





-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/870#issuecomment-719067611