- 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