Re: [csswg-drafts] Proposal: CSS Variable Groups (as a solution to several design systems pain points) (#9992)

Excited by the idea of somehow handling this in CSS, thanks for pushing it forward!

Bunch of thoughts, broken up by some horizontal rules...

---

One thing I haven't seen mentioned yet (but maybe everyone just is aware/understands and sees no issue) is that the proposed syntax is already valid:

<img width="1042" alt="image" src="https://github.com/w3c/csswg-drafts/assets/4323180/3df22ce3-821d-4245-81b6-9fb6ba8e831f">

...which is good in some ways (no parsing changes) but also means this would be adding new behavior to any projects already storing JSON-y type stuff in a custom property, which as I understand was an intentional design goal of custom properties from the beginning, to allow storing things you might pull out using JS.

Any projects already doing anything like this would now implicitly have new variables defined in their project that they didn't have before. Maybe not an issue in practice, but thought it was worth making sure everyone is aware.

---

Personally I think the `default`, `min`, `max`, `min-key`, `max-key`, and `arg` stuff feels like too much scope to try and settle on for an initial version (as alluded to in the proposal).

A lot of it feels very specific to solving problems just for colors, and the idea of custom property groups is not really color-specific, so I think these will be hard and slow questions to come to decisions on.

---

I think the `base` idea is interesting (we did a very similar thing in Tailwind but it was this all caps `DEFAULT` keyword) but I don't like that it makes `base` a reserved word that can't be used as part of one of these custom property names within a group now. To me it doesn't feel worth it — I'd rather just not have a way to create a no-suffix variable within a group, or come up with some syntax that is totally conflict free, for example:

```css
--color-green: oklch(65% 50% 135) {
  100: oklch(95% 13% 135);
  200: oklch(95% 15% 135);
  /* ... */
  900: oklch(25% 20% 135);
};
```

Challenge with that syntax of course is how do you override just the `--color-green` base variable without overriding the whole list, but honestly maybe it's fine to just have a limitation that you can't use this syntax if you want to do that. People can always fall-back to defining the custom properties one by one.

Another idea is to change the left hand side, for example:

```css
--color-green:  oklch(65% 50% 135);
--color-green-*: {
  100: oklch(95% 13% 135);
  200: oklch(95% 15% 135);
  /* ... */
  900: oklch(25% 20% 135);
};
```

Now the implicit `-` separator is explicit and captured on the left

---

Agree with some others that the implicit `-` separator feels a bit magical — I think some way of including the dash in the nested token names feels safer to me, like what was mentioned in the proposal:

```css
--color-green: {
 -100: oklch(...);
 -200: oklch(...);
 /* ... */
}
```

I think moving that to the left hand side with some sort of special character to imply the group would be nicer, like I mentioned above:

```css
--color-green-*: {
  100: oklch(95% 13% 135);
  200: oklch(95% 15% 135);
  /* ... */
  900: oklch(25% 20% 135);
};
```

---

I like that you can disable a whole set of colors this way using `initial`:

```css
@import "a-lot-of-colors.css";

:root {
  --color-potato: initial; /* Would disable the whole color group */
}
```

This is a problem I've been trying to figure out for Tailwind CSS v4.0 because we are moving all of our color token definitions to CSS instead of the JS config file we've used historically.

This would also work with the `*` syntax I suggested:

```css
@import "a-lot-of-colors.css";

:root {
  --color-potato-*: initial; /* Would disable the whole color group */
}
```

---

If something like this makes it into CSS I would _love_ a way to reference these groups in other potential future CSS features to sort of create dynamic selectors.

Tailwind for instance generates utility classes for every color automatically, but all of the tooling to do it is incredibly complex and relies on scanning all of your HTML files to find classes you're using and generate them.

It would be amazing to have some way to declaratively define a matching pattern in CSS that points to a group and makes these selectors "just work".

This is terribly under-thought pseudo-code but maybe it's enough to communicate the idea:


```css
:root {
  --color-green: {
  100: oklch(95% 13% 135);
  200: oklch(95% 15% 135);
  /* ... */
  900: oklch(25% 20% 135);
  }
}

@match .bg-${color} {
  background-color: group(--color, match(color);
}
```


This would allow me to use classes like `bg-green-500` in my HTML without actually defining every single class.

This is obviously way out of scope for this proposal but it's the sort of interesting future use case that might be worth considering during the design. This sort of thing could be a Tailwind killer in a very good way 😄

We're prototyping this style of syntax for Tailwind CSS v4 as a way to create custom utilities that we ingest and process as a preprocessor, but it would be amazing to get power like this in the language in some way one day.

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


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

Received on Saturday, 24 February 2024 15:32:21 UTC