Re: [community-group] The Designer’s Workflow (#43)

> Can you please elaborate?

Sure :-) You initially mentioned:
> just like colors tokens should be used to create new tokens (e.g. button / primary / label / fontsize = typescale / xs)

This is the _additional pointer_ I mean as the simplest scenario - make the fontsize the same value as `typescale / xs`. Slightly extending this case might be simpe mathematical equations, e.g. `fontsize` = 2 * `typescale / xs` or also something like fontsize = min(`typescale / xs`, 0.5rem) … to use variable value if not smaller than 0.5rem.

**Takeaway:** To evaluate the second example, one already needs to know what `rem` in the actual environment is, except for the case where by accident `typescale / xs` is also already defined as a `rem` measure. In this case both measures rely on the same _reference system_ and the decision is trivial.

## Color tokens

For color tokens, such a reference system which gives context to the color coordinates is the [color space](https://en.wikipedia.org/wiki/Color_space).

**Let's explore first the simplest scenrario,** 
…which is totally common these days in web frontends and where everything is based on sRGB color space (like an unwritten law);
We define a color token `awesome-red / middle` = `#cc3600`. Alternatively we could even define it as `awesome-red / middle` = `HSL(16°, 100%, 40%)`. Conversion between `HSL` and `RGB` can easily happen, as both relate to the `sRGB` color space, so we don't leave the reference system called `sRGB`.

I can now imagine deriving new colors with methods common in CSS post-processors, which can for instance make a color `lighter(x)` by `x` percent. So I could do something like `awesome-red / light`= lighter(`awesome-red / middle`, 120%). In the background this would multiply each color component (`R`*1.2, `G`*1.2, `B`*1.2). 
An HSL color would need to be converted into RGB, then made lighter and then converted back. As they share the same color space isn't a problem and almost losslessly doable.

After this proof of concept seems to work, oftentimes ideation stops here. But we want to see whether and where the system breaks, don't we?

**What is happening, when we define a color token based on AdobeRGB?**
First of all, if the token internally (in our exchange format and reference implementation) represents the colors as sRGB, clipping or scaling of the gamut occurs when initializing a token. Just putting a AdobeRGB value in and afterwards receiving the same color would alter it already as it would convert `AdobeRGB > sRGB > AdobeRGB`. 

But let's assume the best in a very happy world and say the token can internally also just be AdobeRGB. If we apply our `lighter(x)` method, the math would still be the same: multiply each color component by factor 1.2, so it should produce the expected results.

And here is the pitfall with these methods, **because it doesn't** (and nobody not doing color management with pencil on paper as a hobby would assume it) -- AdobeRGB has a gamma value of 1, what makes numbers behave linear. `rgb(127, 127, 127)` in AdobeRGB is a 50% black, the exact mid point. sRGB has a gamma value of ~2.4. An increment of 1 unit near 0 is a smaller step than an increment near the end of the scale (255). `rgb(127, 127, 127)` in sRGB is a 79% black. Through the gamma compression (and other properties of the color space), the effect of making something 120% lighter can be perceptionally quite different.

And we not even started blending two colors defined in two different reference systems or tried to manage a considering the differences between adaptive and subtractive color models.

**Conclusion**
For this reason, it is important to not just define the color space and internal representation of color in a token, it is probably also desirable to standardize how methods which alter color (or in a wider extend any measure in tokens) work.

**Fun fact**
We cannot learn from Photoshop's well known blend functions here, as PSD it comes with the following restrictions:
- A PSD file always has one working color space (for good reasons)
- If you apply blend functions on layers and/or filters and then try to convert into another working color space in Photoshop without flattening all layers before, Photoshop will warn you about potential color deviation and tell you this is a destructive action you cannot revert (apart from undoing it immediately as long as the original is still cached in the RAM)


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


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

Received on Thursday, 15 October 2020 20:28:00 UTC