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

Thanks for the careful look @tabatkins, I’ve been looking forward to your reply!

> There's several distinct ideas here:

That's a nice overview. I think the decomposed proposal may mesh better with that line of thinking.

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

Yeah, I think that makes a lot of sense, and removes a lot of the magic.
Though does that mean the wildcard could be preceded by *anything*? Would people be able to do `--foo*: {s: ...}` and reference it as `--foos`?

A few thoughts as I read your reply:

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

Did you see the [entire table of popular design systems](https://lea.verou.me/docs/var-groups/#background) that I included in my proposal?

> Functions

It's not just about verbosity. I have *no* idea how you'd offer something where the design system specifies the ends and the midpoint, and the other tints are automatically computed BUT you can also add hand-tweaked variants to influence how the interpolation works. Though perhaps that is better addressed in `mix()`/`color-mix()`.

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

Groups are analogous to objects/dicts, not functions. Dynamic groups do encroach into function territory, but they are more analogous to JS proxies than functions.

You could argue that everything can be implemented via functions (and Lisp even argues that everything can be implemented via lists) but typically languages offer data structures as well, because implementing data structures as functions is painful AF.

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

It's not primarily about it being heavyweight (though as an author, looking at your code examples of how it could be done has me going NOPE NOPE NOPE I’d take the repetition over this 😅). That's the least of it. 

I think possibly the biggest issue is around **encapsulation**. Whether the palette is defined as continuous or not, or somewhere in between *should* be an implementation detail, not drive how you refer to design tokens. The final user of the design system should not have to care about whether `--color-red-200` is specified manually, or the result of interpolation between e.g. `--color-red-100` and `--color-red-400`.
And it should be possible to *change* between the two, without uses having to be updated. E.g. you notice that your generated `--color-yellow-800` is crap and want to insert a stop in terms of how the interpolation happens, that should be possible without users of the design system having to update their code (and other shades near it should also benefit from the adjustment).

Also, unless we introduce some kind of syntactic convenience, having to use functional syntax is an all-or-nothing preposition which does not play nicely with composition across a distributed ecosystem, while my proposal had paving the cowpaths and requiring as little shared contract between context and components as possible as explicit goals.
Meaning that once YOUR design system uses functions, every design system you use needs to use functions, or you're stuck doing manual mappings again.
E.g. if a component is expecting `--color-primary`, `--color-primary-100`, etc. and all I have is `--color-red(100)`, there is no way to map the two without a lot of repetitiveness.

But even if the component did use functions for its design system, how would you pass these to a component? None of the proposals around functions includes a concept like a function *reference*.
If I want to set a component's `--color-primary` (and its tints) to my `--color-magenta` (and its tints), how would that work with functions?

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


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

Received on Friday, 1 March 2024 20:24:54 UTC