- From: Landon Durnan via GitHub <sysbot+gh@w3.org>
- Date: Mon, 07 Nov 2022 20:29:05 +0000
- To: public-design-tokens-log@w3.org
I think the challenge with the array proposal is there's no clear way of knowing what tokens would be generated based on the hex values. While many systems have adopted a numerical scale that represents the lightness / darkness of a color, it's not always multiples of 10s. I've seen just as many use multiples of 100s. There's also many cases that omit or add steps based on the luminosity, for example [Material 3 adding a `95` and `99` in it's scale](https://m3.material.io/styles/color/the-color-system/key-colors-tones). While the differences in the actual tokens is very similar, I think many systems would be very opinionated on the key and values being closely linked to how that system thinks about color. As I understand the semantic boundaries proposal, something like this seems like it's already doable by choosing values that have more meaning or creating additional aliases. `$color-blue-50` == `$color-blue-mid`. Is the suggestion to limit to only three values (light, mid, dark)? I've found often that's not enough. -- GitHub Notification of comment by landondurnan Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/178#issuecomment-1306149093 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 7 November 2022 20:29:07 UTC