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

I would like to advocate for option (1). Reasons why:

* I don't think the absence of @import will doom the feature to not being used, because many sites have build tooling for them that can optimize away @import, or can just not use it
* @import has runtime performance problems due to causing multiple round-trips
* Choosing options (2) or (3) implies substantial implementation and spec complexity
* We could add support for @import or something like it based on web developer demand in the future, if really needed
* The feature seems mostly about developer ergonomics / convenience (though I'm still learning about use-cases, could be wrong; see below)

I reviewed the many useful and interesting comments on [this Stack Overflow page](https://stackoverflow.com/questions/10036977/best-way-to-include-css-why-use-import). My summary of the use cases:
  * Sharing CSS themes between pages
  * CSS for non-default media queries modes that don't appear on the regular page

The first use-case can I think be solved with developer build-time tooling and is about developer ergonomics only. The second use case is, I believe, about loading low-priority stylesheets later than the main ones, and can be solved by factoring these style sheets into later loads after the initial render.

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