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

I was initially very pro-hex, but seeing the comments I have been convinced that in order to define a color accurately, an author should use the proposed colorspace + channels/components + alpha format. This will allow a color to be accurately translated for any target platform, without requiring a the translator or platform to make any assumptions.

To maintain the maximum amount of compatibility and ease of writing, Maybe we go with the following:

---

If a token has a `$type` of `color`, the `$value` MUST be:

EITHER 
A string containing the six-character sRGB hex value (`"#0000ff"`) or eight-character hex+alpha value (`"#0000ffff"`). If a six-character hex value is present, it is safe to assume the color is fully opaque (alpha value of "ff" / "100%" / "255").

OR 
An object containing the following properties:
    - REQUIRED: The color space to be used when interpreting the color, as a string.
    - REQUIRED: the non-alpha components[^1] of the color listed as an array of floating-point numbers or integers in the range [0,1].
    - OPTIONAL: The alpha component of the color listed as a single floating-point number or integer in the range [0,1]. If the alpha component is omitted, it is safe to assume the color is fully opaque.

---

✅ So this is valid:

```json
{
  "srgb-color": {
    "$type": "color",
    "$value": {
      "colorSpace": "srgb",
      "components": [
        0.1,
        0.2,
        0.3
      ],
      "alpha": 0.6
    }
  }
}
```

✅ This is also valid:

```json
{
  "srgb-color-hex": {
    "$type": "color",
    "$value": "ff0000ff"
  }
}
```

✅  And this:
```json
{
  "srgb-color": {
    "$type": "color",
    "$value": {
      "colorSpace": "srgb",
      "components": [
        0.1,
        0.2,
        0.3
      ]
    }
  }
}
```


❌ But this is not:

```json
{
  "srgb-color-rgba": {
    "$type": "color",
    "$value": "rgba(255, 255, 255, 1)"
  }
}
```

As for which color spaces to support - I think it's safe to allow the value of "colorSpace" to be anything. It's best for us to allow translators to choose which color spaces they want to support beyond srgb - including wide gamut like display P3 or fancy futuristic spaces like xyz-d65, or all the color spaces we haven't invented yet.

[^1]: using "components" instead of "channels" is my preference.

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


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

Received on Friday, 2 December 2022 20:54:41 UTC