Re: [csswg-drafts] Do we need real CSS modules? (#10518)

@romainmenke I appreciate you giving this thing some quality thought. That's exactly why I opened this issue. 💜

In my mind, the main use case for "module"-like system is for using pure values (e.g. mixins, functions) in multiple files without producing *more* CSS. 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.

---

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

It's possible that `@import` could be "fixed" to behave in a more sensible way. Said differently, maybe `@import` could be turned into CSS modules? It doesn't have to be a totally new system, especially if you're not using any new features.

> Naming conflicts are a real issue, let's solve that specifically.

I agree naming conflicts (or lexical scoping, more generally) is something that should be solved and would love to see other proposals to tackle this problem. I just also thought you should get it for "free" if using CSS modules.

> With cascade layers we already have a tool to determine the order in which CSS is applied. Being able to determine the order makes it possible to solve most issues that could happen by having multiple imports of the same file.

I'm a huge fan of cascade layers and I've been using it heavily ever since the day it shipped in all three browsers. But it solves a different problem. I don't consider "order of CSS" to be a major problem anymore.

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

> CSS has effects. These are not side-effects, it's just CSS.

This is exactly the problem, imo. The default behavior of CSS is to "style something on the page". This is fine as a default, but it makes it hard to reference a CSS file without instantly "using" it. A module system splits the "import" and "use" part into two stages. 

Earlier I mentioned mixins and functions as being "pure" values, but there's also `@sheet`, which allows for CSS to exist in an inert state until it is specifically applied. This makes it possible to write CSS that might potentially be loaded ahead-of-time but not used until later. I believe if we get a proper module system, we'd be able to tap into more powerful features like [`modulepreload`](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/rel/modulepreload).

> Transferring mental models and context from other domains (JavaScript) to CSS doesn't always work well.

You don't necessarily have to look at JavaScript. There's precedence for something like this in the CSS world (e.g. [Sass modules](https://sass-lang.com/documentation/at-rules/use/)). And one day we'll hopefully also have HTML modules.

-- 
GitHub Notification of comment by mayank99
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10518#issuecomment-2207510128 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 3 July 2024 23:33:51 UTC