Re: [community-group] Legacy color (#137)

@c1rrus Thank you for these insights!

Is it not better to start with a data format that can support larger color spaces but limit this to srgb in v1?

That would create a much easier upgrade path.

---------

```json
{
  "color-token-1": {
    "$type": "color",
    "$value": "#ff7700"
    // new rule: When using hex string, sRGB color space is assumed
  },
  "color-token-2": {
    "$type": "color",
    "$value": {
      "colorSpace": "sRGB",
      "channels": [1, 0.5, 0],
      "alpha": 1
    }
  }
}
```

This feels like a very slippery sloop.
It seems to confuse "property color" with "type color".

A color property in a program might take one of more possible types for it's value but a color type should be unambiguous.

If type ambiguity is introduced the spec also needs to have a way to define type aliases.

The example above hints at these types :

- `color-hex`
- `color-modern`
- `color` -> `color-hex | color-modern`

It also makes implementations in typesafe languages much more difficult.

------

In my opinion this favours short term convenience while introducing long term complexity.
One of the benefits of creating a brand new spec is that we can avoid these things and choose the best possible format from the start.


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


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

Received on Sunday, 26 June 2022 16:24:40 UTC