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

> I'd advocate for correctness over convenience of manually typing things in that are wrong? Add me to the list of people who think bending this rule is okay. 🙃 IMO human readable > easily human writable, especially regarding colour.

Give it a few years for good editing tools to be created an no one will be writing token files by hand. (who enjoys fiddling in a json?)

Being stuck with legacy bits of data in each token value for eternity (backwards compat) is the price we will pay for this. 

Long terms gains vs. Short term inconvenience.

And as you say there is the risk that a small number of (critical) tools keep using hex srgb, holding everyone back.

------

In case anyone reading is doing an implementation of a translation tool in JavaScript:

We do color conversions to generate fallback CSS for modern notations.
We very recently bundled and published the color conversions as a separate package : https://github.com/csstools/postcss-plugins/tree/main/packages/color-helpers

```ts
import { conversions } from '@csstools/color-helpers';

console.log(conversions.cie_XYZ_65_to_sRGB([0, 1, 0]))
```

This also handles gamut mapping.

It is derived from the sample code found in : https://github.com/w3c/csswg-drafts/tree/main/css-color-4

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


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

Received on Tuesday, 7 February 2023 16:51:13 UTC