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

There was a long discussion running from https://github.com/w3c/webcomponents/issues/759#issuecomment-490256626 (in which @dandclark lays out three options) through https://github.com/w3c/webcomponents/issues/759#issuecomment-497893148 on what the behavior of `@import` in CSS modules should be.  This discussion didn't lead to a resolution.

Since that issue feels like it's getting too large for a single issue, I'm splitting it out into its own issue.  (Sorry if that's not the preferred way of dealing with things here.)

The lack of a resolution of that issue is becoming problematic.  Because Constructable Stylesheets wants to match the behavior of CSS modules, this led to a [extended discussion](https://lists.w3.org/Archives/Public/www-style/2020Mar/0009.html) in last week's CSS teleconference that could have been avoided if this issue had been settled.  And as far a I can tell what it's waiting on is primarily the choice between whether option 2 or option 3 is preferable.

Personally I found @tabatkins's arguments in favor of option 2 relatively persuasive, because it requires less change to the CSS OM, and because many of the theorized advantages of option 3 address issues already handled in existing `@import` handling (even if it's not well specified today).  (And I'd note that CSS always has the option of introducing a new syntax for doing an import as a module.)

cc @matthewp @justinfagnani @emilio @argyleink @domenic @rniwa @chrishtr who also participated in that discussion.

I'd note that I'm also filing this as an effort to get w3ctag/design-reviews#405 finished up.

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