Re: [community-group] Loosen up the color type (#79)

It seems there is growing consensus that there is a need for 16 bit per channel, wide gamut support and that srgb hex isn't good enough.

If there are still concerns that hex is required to gain adoption it could be an option to have single value type that has optional fields?

- `hex` subfield with a fallback srgb color
- `channels` subfield with color information in 16 bit per channel, wide gamut
- `alpha` subfield (shared field for both `hex` and `channels`)


- all color tokens must include `hex`
- optionally color tokens can include `channels` + `colorSpace`
- `colorSpace` must be one of several color spaces referenced within this specification


Valid color values :

```json
{
  "foo": {
    "$type": "color",
    "$value": {
      "hex": "#000",
      "colorSpace": "xyz-d65",
      "channels": [0.1, 0.2, 0.3],
      "alpha": 0.6
    }
  }
}
```

```json
{
  "foo": {
    "$type": "color",
    "$value": {
      "hex": "#000"
    }
  }
}
```

Invalid color values :

```json
{
  "foo": {
    "$type": "color",
    "$value": {
      "colorSpace": "xyz-d65",
      "channels": [0.1, 0.2, 0.3],
      "alpha": 0.6
    }
  }
}
```

-------

Tools must follow this logic when reading :

1. if you don't support `16 bit per channel, wide gamut values`
  1.1. use the `hex` fallback
2. if the token doesn't have a `16 bit per channel, wide gamut value`
  2.1. use the `hex` fallback
3. if you don't support the color space
  3.1. use the `hex` fallback
4 use the `16 bit per channel, wide gamut value`

Tools must follow this logic when writing :

1. if you don't support `16 bit per channel, wide gamut values`
  1.1. emit a token with only a `hex` field
2. emit a token with a `hex` field and a `16 bit per channel, wide gamut value`
  2.1 if the value is within the srgb color space
    2.2 do a simple conversion
    2.3 else, apply gamut mapping

_2.3. is lossy, this can not be avoided_

This gravitates heavily towards hex.
But it also places pressure on tools to support modern formats because the conversion to hex can be lossy.

None of this complicates the design token format as a whole.
The logic around `$type` and `$value` is still valid.



-- 
GitHub Notification of comment by romainmenke
Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/79#issuecomment-1420770136 using your GitHub account


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

Received on Tuesday, 7 February 2023 13:23:17 UTC