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

Really interesting points. The syntax & permitted values for color tokens certainly seems to be the most controversial part of this spec! Some of the concerns raised here feel similar to the ones in issue #79.

I must confess my knowledge of the theory and terminology around colors is a bit limited compared to some of the posters here. In case it helps others, I've found this [article about "Improving Color on the Web" on the Webkit blog](https://webkit.org/blog/6682/improving-color-on-the-web/) useful as it has a handy "Definitions" section that explains things quite well IMHO. (If you know of other good learning resources on this stuff, please do share some links here!)

Based on my (limited) knowledge of this topic the main concern being raised here is that the current draft spec restricts colors to:

* sRGB color space (or is that color _profile_?)
* Color depth of 8bits per channel

Safari, soon Chrome and perhaps other browsers, platforms and tools support wider gamuts (i.e. _more_ colors that don't exist in the sRGB space) and/or higher color depths (the _precision_ with which colors within a given color space can be specified). Design systems wanting to use such wide gamut and/or higher depth colors therefore cannot accurately represent them using the DTCG format.

The syntax for color values proposed by @romainmenke could resolve these issues because:

* The floating point numbers for each channel offer a much higher color depth than the 8bits afforded by the hex format the spec currently specifies
* Explicitly stating the color space lets folks use different color spaces. Though, I'd imagine the spec would need to define a finite set of color spaces that can be used in order to enable interoprability.

Questions to y'all:

1. Is it possible to do a lossy conversion from a higher color depth to a lower one?
2. Is it possible to do a lossless conversion from one color space to another for colors where their gamuts overlap?
    * I'm assuming if a color in space A does not exist in space B's gamut, the conversion would necessarily be lossy. Right?

Assuming the answer to 1. is "yes", then any tools that only support 8bits per channel could simply do the lossy conversion from the token's "raw" floating point value. Depending on their needs, this could be done at the point at which they load a tokens file or at the point at which the value is displayed in the UI.

Going the other way around is fine too. A tool that can only generate 8 bit per channel colors can easily write out those values as floating point numbers. Such tools are just a bit limited in terms of the range of values they can produce.

The use-case that requires some further thought would be a tool that can import, manipulate and then export token files. Ideally any tokens in the original file that was imported, not modified and then included in the exported file would be perfectly preserved. However, if the import process inluded a lossy conversion, then the corresponding exported token would no longer be the same. I think that's a broader topic as it applies to other kinds of tokens too. For example dimension tokens with `rem` values. If they were to travel through a tool that internally only supports `px` values, there's the same kind of challenge. I think I'll therefore open a separate Github issue for this specific topic.

However, aside from that "preserving tokens when travelling _through_ a tool" issue, I see no problem with adopting an array of floating point numbers instead of a hex string. As others have pointed out, this would not impose any obligation on tools to _internally_ support higher depth colors. It therefore shouldn't be a blocker to existing design tools (or indeed any kind of tool) adopting the DTCG format.

If the answer to my 2nd question above is also "yes", then the same might be true for supporting additional color spaces beyond sRGB. Let's imagine the spec supported the Display P3 color space which, if I'm not mistaken, has a wider gamut than sRGB. If someone's specified a color token using Display P3 and a tool that internally only supports sRGB uses that token, then there are 2 possibilities:

* The color is in gamut for sRGB, so the tool just performs a lossless conversion and uses the result
* The color is out of gamut for sRGB, so the tool needs to do a lossy conversion to the closest color in sRGB and use that

The latter doesn't strike me as any different to a tool doing a lossy conversion from a higher color depth to a lower color depth. A nice to have might be to display a warning message to the user to inform them that the color they see in the tool's UI is an approximation of the actual color specified by the design token. But, I think that's quite acceptable.

Again, going the other way is fine too. Any color tokens generated within the tool which are therefore necessarily confined to the sRGB color space can be exported to the DTCG format without issue. Just because the spec can represent more colors than the tool, doesn't mean the tool needs to be able to generate all of those possible colors.

It seems supporting the sRGB is a no brainer as that seems to be the de-facto standard one most current design tools support. It's also what _all_ browsers support. I _presume_ the same is true for native apps on various OSes (but please correct me if that's not the case).

The question therefore becomes, if we were to go down this route with the spec, which other color spaces should we support?

Bear in mind that _every_ tools that supports the DTCG format would be expected to at least be able to convert from _all_ of the specced color spaces to whatever it uses internally. So, the more spaces we require in the spec, the more complexity there might be for implementors.

Question: Is there a color space that has a gamut wide enough to encompass all other color spaces? If so - and assuming you can convert in gamut colors losslessly between spaces - then would it not suffice to only add that?




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