- From: Nate Baldwin via GitHub <sysbot+gh@w3.org>
- Date: Wed, 15 Jun 2022 05:28:24 +0000
- To: public-design-tokens-log@w3.org
I agree that there should be more flexibility built-in. Considering tokens are an interchange format I would not necessarily expect them to house transformations. But as a way to express "design decisions", it seems backwards or outdated to not support a method for defining decisions as decisions are made. In other words, I as a designer should be able to specify a color like ``` { colorSpace: 'CAM16', channels: [76, 100, -56], alpha: 1 } ``` Then it's a matter of tools being able to support a color space or not. However, looking at a bit more likely scenario, we can see how a fallback may be necessary for non-24bit sRGB colors, like with DCI-P3/Display-P3: ``` { colorSpace: 'Display-P3, channels: [1, 0.5, 0], alpha: 1, fallback: "#FF8800' } ``` At which point, forcing the fallback value to meet the earlier requirement makes sense. -- GitHub Notification of comment by NateBaldwinDesign Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/137#issuecomment-1156004333 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 15 June 2022 05:28:25 UTC