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

I think that in JS, if we read the computed style for a grouped property value, it should return the full group rather than the `base` value. This way, JS can read the entire group and work with any of its values, just as it currently does.

It could be worth introducing new JS APIs to access and read/write grouped values, like this:
```js
getComputedStyle(elem).getGroupedPropertyValue('--color', 'primary', '100')
```

I believe this addresses @devongovett's point as well. As he mentioned, that syntax was valid and would still be considered valid today. As long as JS continues to yield the same results it currently does and gets the full group, I don’t see this causing any breaking changes. I can’t speak for every library, though I myself do maintain a library for sharing data between CSS and JS in this fashion, and I don't think this would cause any breaking changes for my library, so long as JS still retrieves the entire property value, not just the `base`/`default` value.

Even without a new JS method for retrieving nested properties, a JS helper function could still be written to perform such a task as needed, so it's not really a blocker for this feature. A case could be made for requiring the use of the `@property` rule to define CSS custom property groups, possibly with a `group: {boolean}` value.

Nearly all CSS custom property values—including JS—parse as valid, though I don't think this would cause any tangible breaking changes, as this would just parse as valid in contexts where it isn't currently, e.g., used as the value for a color property. Passing it into another CSS variable or consuming it in JS would still retain the full grouped value as it does today.

That said, it does feel risky to have one CSS custom property essentially generate any number of others. This could be confusing for both new and seasoned developers trying to understand where a variable is coming from, e.g., searching their codebase for a static variable name `--color-purple-light` and finding no results.

I would personally prefer a dedicated syntax for referencing nested properties, such as a dot syntax, which would feel familiar and support both strings and numbers in CSS. So, this would be valid syntax: `--color.purple.light`. That approach would make it clearer when a nested value is being used, with the same level of simplicity, and also make it easier for any JS parsers to tell what is a variable name vs. a grouped/nested variable name.

I think the value of use cases for `default` and/or `base` is significant and could still be supported when a group is used as a value. However, this particular usage might require a `@property` rule—not sure. In either case, it would not be a breaking change.

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


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

Received on Monday, 26 February 2024 17:39:42 UTC