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

I have some concerns in addition to the questions of distinct stylesheet identity discussed by @tabatkins and @justinfagnani above, and I am not entirely sure that we need to commit to either of these options at this point.

For option 2 as stated in [this post](https://github.com/w3c/webcomponents/issues/759#issuecomment-490256626) (CSS modules are leaf nodes), there are really two sub-options:

2a) Pull in the full `@import` tree of the CSS module during the module graph link phase.  Block module graph Evaluation until all of these are resolved, and if any of them 404 then cause module graph linking to fail.  This approach would mean that we're blocking the module graph on fetches for things that are not in the module graph.  Maybe this isn't a real problem, but intuitively something feels off to me here.

2b) Don't block module Evaluation on `@import`s and don't fail the module graph if they don't resolve.  This approach gets us closes to how `@import` works in normal stylesheets.  But, it breaks a key assumption that a module importer can normally make: by the time a module executes, all of its dependencies have already been loaded successfully.  Allowing a CSS module's `@import`s to pop in after module Evaluation, or fail to load altogether, breaches this contract.

On the other hand Option 3 (CSS modules are non-leaf; `@import`s are treated as CSS modules) changes the behavior of `@import` in such a fundamental way that I wonder if it would be more appropriate to add this behavior under a new syntax, as a totally separate feature -- `@module-import` or something.  This should alleviate concerns about `@import`s behaving differently when a stylesheet is consumed as a module vs in a `<link>`.  It would create a clear break between CSS written for a module and CSS written in the 'classic' way, but there is precedent for that -- JS modules generally won't work right when pulled in by a classic script (e.g. `import` statements will be syntax errors).

If forced to choose between these options now I think I prefer (2a); it gets us close to the `@import` behavior that users are familiar while keeping the module semantics of statically resolving all dependencies.  It also leaves us open to introducing non-leaf CSS modules in the future with an additional `@module-import` syntax.

However, I want to take a step back and ask if we really need support for `@import` in either constructible stylesheets or CSS modules at this point.  Is there evidence that it will be widely used or that the lack of support will be an adoption-blocker for these features?  Looking at https://chromestatus.com/metrics/feature/popularity, the use of [CSSStyleSheetReplaceWithImport](https://chromestatus.com/metrics/feature/popularity#CssStyleSheetReplaceWithImport) (<=0.000001%) is quite a bit lower than the use of [CSSStyleSheetReplace](https://chromestatus.com/metrics/feature/popularity#CSSStyleSheetReplace) overall (0.036757%) [note -- the anchor tags don't always seem to work so you might have to ctrl-f for these on the [page](https://chromestatus.com/metrics/feature/popularity)].

I believe there was a concern that removing `@import` support from constructible stylesheets could be a difficult decision to reverse.  But it's not clear to me why this should be the case.  If the presence of an `@import` makes us throw a syntax error (in constructible stylesheets) or fail to load the module (in CSS modules), it seems that we would have a lot of flexibility to make future changes; no one could have reasonably taken a dependency.

So, if explicitly throwing/failing on `@import` is the path that leaves us the most flexibility, and we don't have a totally solid best path forward for doing otherwise, then I think it would be reasonable to just continue throwing.  Once constructible stylesheets and CSS modules are shipped more broadly and gain wider use, we will have more information and more developer feedback about how they are used and how they interact, and this will give us a better basis to make decisions like introducing a new `@import` syntax.  But do we need to constrain our choices at this stage by picking a strategy that we will be stuck with forever?

-- 
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-600362455