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

I believe there are 2 separate issues here:

1. How many different ways should the format allow the _same_ color to be written as?
2. Should the format support color-spaces other than sRGB and/or greater precision than 8bits per channel. Or, to put it another way, should we increase the range of _different_ colors that can be expressed?

I'll therefore address them separately:

**1) Allowing the same colour to be written in different ways**
Here are a few ways of expressing the _exact same_ color (if we assume sRBG color space & 8bits per channel):

* `#ff0000`
* `#f00`
* `rgb(255, 0, 0)`
* `{ r: 255, g: 0, b: 0 }`
* `hsl(0, 100, 50)`
* `{ h: 0, s: 100, l: 50)`

This is just like how 0°C is the exact same temperature as 32°F, or 1 km is the same distance as 0.62 miles. And, as with temperatures and distances, different people will have different preferences. Some folks find HSL a more intuitive way of expressing a color and others prefer RGB. Some like hex numbers, others like decimal numbers.

From a human-friendliness perspective, offering more choices is desirable. But, in this instance, the choice is only being limited for people wanting to create or edit DTCG token files in a text editor. That's an important audience no doubt (and I certainly see myself hand-editing token files in the future! 😜), but I'm not convinced only being able to write color values as hex triplets would be a deal-breaker for many people. (For many years, that was the only way you could write colors in CSS too)

Bear in mind that the spec is only mandating how color values can be written inside DTCG token files. There is absolutely nothing stopping tools converting to or from other formats when presenting the color value or letting users input them. For example, a color picker widget in a design tool could let a user enter HSL values or even provide a choice of HSL, RBG, HSB, etc. All that the spec is mandating is that if that color gets saved out to the DTCG token file, it then needs to be converted to an RGB hex triplet.

_Furthermore_, from an implementation perspective, this adds complexity and increases the risk of bugs or interoperability issues. If the spec mandated that all of the above formats for writing color values needed to be supported, then _every_ tool that implements our spec would need to have code that can:

* Look at a color value and figure out which of those formats it is (so that it can...)
* Convert from that format to whatever internal represenation of color values that software uses

Granted, it's not _too_ complex to do and there are plenty of color conversion libraries out there that can help. But, nonetheless it is extra work, more code to test and maintain and more chances for bugs to creep in. It might also be a barrier to entry for small teams or inexperienced programmers wanting to make tools that do things with token files. And the more formats we permit, the more that complexity grows.

I strongly believe that interoperability is an important goal of the DTCG's file format. You should be able to save tokens in one tool and open them in any other tool and it should "just work". So, what happens when one tool has a bug in how it handles the many color formats, or another tool forgets to add support for one? Interoperabilty will suffer. Color tokens exported by tool A might not be able to be imported into tool B anymore.

So, if our spec allows 1 or only a small number of color formats, we keep that implementation complexity low and, hopefully, ensure a higher degree of interoperability between tools.

As you can tell, I'm very much in favour of keeping the number of permitted color formats in our spec to a minimum. However, I don't have a strong preference as to which one(s) we choose. Our current draft only allows hex triplets, but that could be changed to something else or extended to allow an alternative.

Another angle to consider is that whatever we settle on for version 1 of the spec, can be expanded in future versions of the spec. Obviously, we'd want to do so in a backwards compatible way (i.e. tools that support v2 files should still be able to read v1 files without problems), but adding more formats shouldn't be a problem.

**2) Allowing a greater range and/or precision of color values**
This is something I'm keen on too. Many modern devices have amazing screens than represent more colors than ever before. Folks should be able to take advantage of that in their design tokens.

_But_, does that necessarily need to be in v1 of the spec? If we stick with just 8bit per channel, sRBG hex triplets for now, there is nothing stopping us broadening that in future versions. Just like CSS once only had hex triplets and now has many more formats and support for different color spaces, we too could add those things in future versions (in fact, we could just adopt the same formats CSS uses - as others have already suggested in comments elsewhere).

As far as I know, popular design tools like Figma don't support these things yet and browser support is still limited. So, in the spirit of keeping things lean and simple for now to get a v1 spec sooner rather than later and then also gaining adoption across many tools and some momentum, my preference would be not to tackle this right now. But I'd definitely want to revisit this topic in the future.



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


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

Received on Thursday, 2 December 2021 23:33:13 UTC