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

Another thing: While I do like @romainmenke's proposed syntax for color token values, it doesn't have to be mutually exclusive with the current spec draft's hex triplet or quartet string syntax. We could theoretically permit both. For example:

```jsonc
{
  "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
    }
  }
}
```

In this example, both tokens have the exact same color value, just expressed in the different syntaxes. This would add a little bit of complexity to parsers as they'd need to add some logic along the lines of:

```js
if (tokenType === "color") {
  if (typeof tokenValue === "string") {
    // it must be a hex triplet or quartet
    // (and therefore color space is sRGB)
    // ...
  }
  else if (typeof tokenValue === "object") {
    // it must be the object style
    // ...
  }
  else {
    throw new Exception("Invalid color token value");
  }
}
```

IF we decided that this was acceptable, then that might afford us some flexibility about _when_ the format needs to support higher color depths and/or additional color spaces:

1. We continue as is meaning that v1 of the spec only supports the hex strings (and is thus limited to sRGB and 8bits per channel). Later versions introduce the object syntax as an _alternative_ way of expressing color values, including colors that use higher depths and other color spaces.
2. We introduce both syntaxes right now, so v1 of the spec has them.
    1. For v1 we could restrict ourselves to only the sRGB space to keep things a bit simpler for implementors (in which case, perhaps we don't need the `colorSpace` property right now. That could be introduced in later spec versions when we add support for more color spaces. In that case, when that property is absence, parsers must assume the sRGB color space)
    2. OR, we go all the way and support multiple color spaces in v1

Personally, I'm leaning towards Option 1. or 2.1. I think adding the object style syntax sooner rather than later might be a good thing (and if we decided to do that, we might also want to consider ditching the hex strings altogether and making it the _only_ syntax we use). While I'm totally sold on adding support for more color spaces _eventually_, I don't think their use in UI design is widespread enough today to make it a necessity for the v1 spec.

Bear in mind that `$extensions` could serve as an escape hatch for teams needing them sooner. You could, for example, do something along the lines of:

```jsonc
{
  "color-token": {
    "$value": "#ff0000", // sRGB 8bit-per-channel fallback color
    "$type": "color",
    "$extensions": {
      "com.example.originalColor": {
        "colorSpace": "displayP3",
        "channels": [1,0,0],
        "alpha": 1
      }
    }
  }
}
```

Btw, I know it's taking the DTCG quite a long time to get to a v1 spec. However, that doesn't necessarily mean subsequent versions will take as long. Especially, if they're mostly adding features. So, starting with just sRGB colors now, doesn't mean it has to be a really long time before support for other color spaces is added.

Also, if the v1 spec only supported sRGB teams wanting to use 

-- 
GitHub Notification of comment by c1rrus
Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/137#issuecomment-1166543573 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 14:05:59 UTC