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

> 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.

What is the practical benefit of allowing `colorSpace` to be anything?

I think this must be strictly defined.
If it can be anything tool creators can not write the code for the conversions.

> fancy futuristic spaces like xyz-d65

In what way is `xyz-d65` futuristic or fancy?

>  Generally speaking, I sense a general consensus around: 1. Allowing authors to write colors as hex values, 

There definitely isn't a consensus about hex or a dual format.
I am strongly against hex strings. I don't see why I need to complicate my tool's implementation by adding support for this format in the parser logic.

> using "components" instead of "channels" is my preference

This is unusual, the most often used technical term is "channels"

-------

I think there is some confusion between certain things:
- color profiles for screen/print
- device capabilities
- color pickers in design tools
- color data in a platform specific format
- color data format
- color spaces

## color profiles for screen/print and device capabilities

That a person's display is limited to ±sRGB or ±displayP3 today must not influence how we store color data. Tomorrows screens might be ±rex2020.

Design token files also aren't pdf.
These will not be send to a printer who has a custom ICC profile specific to their equipment.

Design token files will always be processed further.

## color pickers in design tools

In a design tool's color picker it makes sense to have multiple color models like hsl, lch, oklch, rgb, hwb,... as these allow designers to use different mental models to pick and tweak colors.

These color models have no benefit in a raw data format.
A computer doesn't have a preference or opinion about these things, it only needs a format that is able to correctly record the color with high enough fidelity.

If a designer prefers to work in oklch but only picks colors that fit within the sRGB color space then the output could be written as sRGB to maximize compatibility with other tools.

## color data in a platform specific format

Some platforms (iOS, Android, CSS) might have limitations today and maybe only support sRGB or only displayP3.

With this I mean the API's to instruct the platform to use a specific color, not the device capabilities.

CSS in Firefox can only express sRGB today but this could be on a device capable of rec2020.

This is the responsibility of translation tools to form the bridge between raw data and what can be expressed on a specific platform.


## color data format

This is purely the data structure, not the contents.

- hex format
- structured color format

`#fe05c2`

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

If the expectation is that colors will be mostly manually typed then hex can be useful.
However this format is intended to be written and read by software.

Do we need the extra complication of a dual format?
It adds extra burden on tools to write the parser logic for colors.
It isn't much, but little things add up.

This was asked in detail here : https://github.com/design-tokens/community-group/issues/149

## color spaces

These are purely an encoding of color information.
By going for something like `xyz-d65` today the specification will be future proof.

Design tools only need limited conversion logic between the formats they have color pickers and color display for and `xyz-d65`.

Translation tools can be platform specific and can specialize in converting from `xyz-d65` to the best that is possible on the respective platforms.

If the list of color spaces to support is exhaustive then all tools will need a lot more logic for all the possible combinations.

----

Only the data format and the list of color spaces are a factor for the design token file format. Everything else is irrelevant.

-- 
GitHub Notification of comment by romainmenke
Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/79#issuecomment-1335932101 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 22:40:11 UTC