- From: Romain Menke via GitHub <sysbot+gh@w3.org>
- Date: Sat, 06 Jul 2024 11:56:49 +0000
- To: public-css-archive@w3.org
> Today, if you `@import "mixins.css"`, it is equivalent to inlining the contents of mixins.css at the call-site (alternatively, it's kinda lika a data-uri). If you do this in 20 places, you will have 20 instances of everything from mixins.css. I guess it still "works" because whatever comes last will override previous instances of the same name, but hopefully it's clear that this is a problem. Can you specify what the problem exactly is? To me it isn't clear from context. (browsers optimize multiple imports of the same file) ------ > Today, if you `@import "mixins.css"`, it is equivalent to inlining the contents of mixins.css at the call-site (alternatively, it's kinda lika a data-uri). If you do this in 20 places, you will have 20 instances of everything from mixins.css. I guess it still "works" because whatever comes last will override previous instances of the same name, but hopefully it's clear that this is a problem. > In comparison, when you import a module, you get to properly use things from it without repetition and without unintentionally polluting to global namespace (e.g. the mixins and functions will only be available to the importer and not to other files). Each of those 20 importers will get to import members from the exact same shared module. This sequence of arguments seems forced. I don't see how having the (still unclear) problem of importing the same stylesheet 20 times relates to isolation and naming conflicts. Are you sure that you aren't trying to solve naming conflicts? ------- > > (1) Having multiple ways CSS can behave depending on "is a module" vs "is not a module" is bad on its own. This makes everything more complex to use and understand. > I agree it's making things more complex, but it might be a necessary thing to do? Today, nobody wants to use `@import` in production because its behavior is so undesirable. At best, today's `@import` is a marker for build tools to concatenate CSS. `@import` does have an unsolvable problem. It introduces a waterfall pattern to the network requests to display your page. Browsers can't know ahead of time which `@import`'s will exist in a stylesheet without first fetching and parsing that stylesheet. If you already do know all the stylesheets referenced with `@import` ahead of time, then you can simply use `<link href="foo.css" rel="stylesheet" />` for each`. This conundrum makes it hard (impossible?) to use `@import` and still have a fast website without needing to rely on complex tooling. But that doesn't seem to be the issue you are referring to, right? ------- I've spend a great deal of time creating a test suite for `@import` behavior in the past year and that this is used to improve interop between dev tools: https://github.com/romainmenke/css-import-tests?tab=readme-ov-file#current-state `postcss-import`, `@csstools/postcss-bundler` and `esbuild` all support creating bundles with `@import` that very closely mimic native behavior. (`lightningcss` also aims to follow this behavior, but it has more open bugs) That means that all dedicated CSS bundlers support `@import` as specified and implemented by browsers. As far I know, no one opened an issue about this behavior with one of those tools. Saying that no one uses `@import` because its behavior is undesirable is simply untrue. Both tools and CSS authors use it extensively. ------- > > (4) Existing tooling to simulate isolation of styles is very invasive. … Any module system for CSS would lack those properties. > I don't see why this is relevant here. The purpose of a module system is not to solve DOM scoping or to replace JS-based tooling (despite the confusingly overlapping ["CSS modules"](https://github.com/css-modules/css-modules) name). For those problems, I believe `@scope` and shadow DOM encapsulation are the correct solutions. Ok, but that leaves me more confused what problem you are actually trying to solve. ------- > > (5) CSS has effects. These are not side-effects, it's just CSS. > This is exactly the problem, imo. 🤔 ------- Can you provide a demo that is somewhat realistic and explains the issue better? Maybe a github repo with a bunch of stylesheets and an html page? It would be good to know what CSS are writing now and how the outcome isn't want you want or expect. -- GitHub Notification of comment by romainmenke Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10518#issuecomment-2211748671 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 6 July 2024 11:56:50 UTC