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

Re:_WRT base values_ (the comment you quoted was me not Adam. As a LESS proponent turned Tailwind proponent myself, I'll take the conflation 😄)

> The main motivation is twofold:
> 
> 1. To ensure that groups produce a value when used in regular properties

Not sure that I'm understanding. I think you're saying to ensure that given `--color-green: { base: /* … */; }` we can `my-component { color: var(--color-green); }` and cannot `my-component { color: var(--color-green); }`? To me `var(--color-green-base)` is more intuitive there, and requires less special knowledge, than `var(--color-green)`.

> I’d love to hear more about the cases where you want to have a value called "base" or "default", but it's not actually the same value as you want the property to return when no suffix is used.

I wasn't clear, that's not what I had in mind. But here's a contrived example for it: a palette with ten shades of green, where shade 3 is the starting point from the other nine shades are calculated, and where shade 5 is the "primary" shade (think the 400 font-weight). In the group definition you'd have top level names 1, 2, base, 4, primary, 6, 7, 8, 9, 10, and the variables would be green-1, green-2, green, green-4, green-primary, green-6, etc. Usable if you know the rule, but arguably not an accurate reflection of the design. Especially in colors where a designer might not give special distinct meaning to "base" vs "default", and in CSS where we don't already have magic keys, I'm not sure the language should read meaning into any key name.

That's off the top of my head. What I had in mind

Say the magic name is `default`, and the design's source of truth is outside code in some comp, and the design calls some shades "default". These are the downsides I've run into when putting the "default" shades under the key `default`:

- deviation within the code: "green default" in the palette definition, "green" elsewhere
- deviation between the design and the code. "green default", the name in the source of truth, is sometimes "green default" in the code and sometimes "green"
- redesign complication. If all the "green default" needs to change to "dark red", you can't do a _search and replace all_ (unless you know all the contexts in which the base shade of green is used, and are strong with regex). You search e.g. `--color-green` and manually identify the ones that need to change.
- refactor complication. Say the designer renames "default" to "primary" and the code is to change to match. Again, brush up on negative lookaheads or do it manually.

I've hit all of those when using Tailwind's magic `DEFAULT` key for color shades called "default" in the design comp (and now favor the non-magic `default` key, which resolves all four complications.)

tldr I want to have the choice to have a key "base" or "default", and for the language to not swallow that key (and I don't expect the language to let me leave off a key)

> does that mean that we could groups in groups in groups
>
> Yes.

Then does magic `base` entail more special rules —at least "no grouping under base"— to prevent the ambiguity of `--a-b` in

```css
--a: {
  base: {
    b: 1;
  }

  b: {
    base: 2;
  }
}
```

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


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

Received on Sunday, 25 February 2024 00:55:47 UTC