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

(Sorry, I've only skimmed the rest of this thread; it got real long real fast.)

Overall, several good ideas in here. I think it could do with a more holistic look at the use-cases, tho - as written, it gradually grows more complex and reinvents itself in several forms. I think deciding on what use-cases to address, and solving them directly, will result in a better proposal than what's currently written.

-----

Being able to define parametrized groups of variables and pass them around as a group makes sense. There's several distinct ideas here:

1. Being able to rename an entire group of variables with one command (rather than having to write out every single variable in the group and rename them individually).
 * Sub-idea: assuming variables/mixins do need to declare the variables they can see, being able to declare an entire group's visibility at once would be useful.
2. Automatic grouping of variables by prefix, so later users can extend the group with new properties as needed, and have them automatically included.
3. Being able to define a single "generic" variable, and then associate sub-values with it. (The example of `--color-green` being the "representative" green, and then `--color-green-100`/etc being specific tints.)
4. Parametrized variables (aka cascading custom functions?), where you gain access to a special variable representing the parameter.
5. Being able to refer to parametrized/grouped variables dynamically, with the parameter/identifier supplied as an argument rather than being part of the variable name.

--------

I think being able to refer to variables by prefix, and possibly rename them by prefix, makes sense. The syntax suggestions are fairly lightweight, and it doesn't meaningfully overrun any other functionality in the language.

We will need some syntax to differentiate it from existing variables, tho. The existing syntax space is wide-open, intentionally, so we can't just infer grouping from the property name, or from the value being a `{}`-block. But something like `--foo-*: {...}` is possible, where the `*` token indicates it's not a standard variable, and has a specific syntax that's a `{}` block.

I would love to see specific examples of people using design systems and running into these problems, however, to make sure we are indeed solving their problem. This is designing syntax/tooling, and the use-cases are necessarily more abstract, but we still need to be sure we're actually helping people.

-----

As we get further down the list, tho, we're basically just doing functions. (Or array/dict lookups, which can be seen as particularly simple functions; or vice versa, functions are particularly complex array lookups.) We already have a proposal for doing CSS functions, and I don't think we should do functions *twice*, with different syntaxes, unless there's a *really* good reason.

Near the end, you argue against the usage of custom functions for handling several of these. I think we should look at this possibility more carefully, as functions do substantially overlap in use-cases here.

You mention having to write a new function as being heavyweight; I acknowledge it's certainly heavier than writing some variant of `--color-primary-*: var(--color-red-*);`, but I don't think this is something you'd do repeatedly. You'll set up your desired variable names at the top of your stylesheet, and then never think about them again.

(But still, if we did introduce something like the `--foo-*: ...` syntax, allowing it to accept a variable-group reference like `--color-primary-*: var-group(--color-red-*);` would make sense, in addition to directly defining the group via a `{}` block.)

> Which part is variable is part of the syntax, so e.g. in the example above, there is no clear path to defining a --color() function from that.

I think this is a plus, fwiw. Making it clear what's variable and what's not is a *good* thing; people shouldn't be assuming that every dash-separated suffix of a variable name can be removed to form a more generic variable.

A --color() *could* exist, tho, once we actually introduce the conditional functions we've bandied about. (And we should do so, as part of the custom functions proposal, imo.) That way you could write `--color(primary, 40)` if you wanted, and have it handled by something like:

```css
@function --color(--type, --tint: 40) {
 result: cond(
  (var(--type) == primary) --color-primary(var(--tint)),
  ...
 );
}
```

Or an equivalent syntax with at-rules.

> There is no way to pass a few key colors to a component or subtree and have the rest be computed from them. In fact, we cannot pass functions around at all, only the result of their invocation.

Sure there is. You can't pass functions around the cascade, but functions can depend on custom properties, so like:

```css
@function --color-green(--tint: 400) 
 using (--color-green-100: oklch(...), --color-green-900: oklch(...)) {
 result: color-mix(in oklch, var(--color-green-100) calc((100 - var(--tint) / 10) * 1%), var(--color-green-900))
}
```

This calculates the full green spectrum off of the start/end greens, and allows them to be overridden in any subtree.

> This approach works far better for tints that are generated as samples on a continuous axis. It is unclear how a set of predefined tints would look like as something like that.

Assuming the conditional functions end up existing, then you could always test for the precise values you want to define for, and let any non-matching values resolve to something invalid. Or you can round to the nearest value you want to handle. Several possible options, and it gets larger as we expand CSS's value space.

----------

I think the biggest issue with using functions is that it wouldn't mesh with your "automatic grouping by prefix, so others can extend it" goal. The `--color()` example I gave above, for instance, can't be extended to take more keywords. This might be addressable directly, tho!

Like, if we think this sort of "define groups of functions with a common prefix, and dynamically dispatch to them" will be common, we could just make dynamic dispatch work. Like:

```css
@function --color(--type, --tint: 40) {
 result: function-call(--color / var(--type), var(--tint));
}
```

The first argument to `function-call()` here is a slash-separated set of idents, which get composed into a dash-separated function name, which is then passed the remaining arguments. With this, then, if you define `--color-primary()`, you could call `--color(primary, 40)` and it would Just Work, and similarly if someone defined a `--color-green()`, etc.

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


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

Received on Thursday, 29 February 2024 21:36:25 UTC