Can token operations help with color spaces?

[marcedwards]

Hello Donnie! I’m opening this issue as per your request, to continue the discussion. I’m curious how token operations could assist with providing colour space information. Thanks!

[ddamato]

Certainly, based on the current specification, below is what a color token currently looks like:

{
  "Simple sage": {
    "$type": "color",
    "$value": {
      "$hex": "#b4d8a7",
      "$colorSpace": {
        "name": "srgb",
        "$components": [180, 216, 167],
        "$alpha": 0.75
      }
    }
  }
}

As demonstrated, the color is made up on several parts. These parts are eventually composed into a final result based on the target system. Let's say the target is CSS and the expected output is meant to use the color() function like this:

:root {
  --simple-sage-css: color(srgb 180 216 167 / .75);
}

What I propose is, instead of placing all of the pieces in a single token object that is highly specific to the type, we separate the pieces across tokens.

{
    "simple-sage-colorspace": {
        "$value": "srgb"
    },
    "simple-sage-component1": {
        "$value": 180
    },
    "simple-sage-component2": {
        "$value": 216
    },
    "simple-sage-component3": {
        "$value": 167
    },
    "simple-sage-alpha": {
        "$value": 0.75
    },
    "simple-sage-css": {
        "$value": "#b4d8a7",
        "$operations": [
            "{simple-sage-colorspace}",
            "{simple-sage-component1}",
            "{simple-sage-component2}",
            "{simple-sage-component3}",
            "{simple-sage-alpha}",
            ["String.concat", "color(", "$1", " ", "$2", " ", "$3", " ", "$4", " / ", "$5", ")"]
        ]
    }
}

The result would look identical to the above CSS result. The immediate feedback that you might provide is that this has too many token definitions to write. This is by design because what this approach lacks in concise authorship, it makes up for in customizability. If token operations were widely adopted, we wouldn't need to wait for spec authors to agree regarding the composition of any token, nor would we have to wait for tools to implement.

[ddamato]

Also note that you would only need to define the parts individually if you are targeting different systems, where the final result is expected to be in different formats. Then other tokens could be composed for Android, iOS, etc using these pieces.

[marcedwards]

Great, thanks for the additional context. I see where you’re going with this, and I can see why you’d want it.

For me personally, this puts a bit too much logic into the format itself and it strays away from being a nice way to interchange data, because it’d now require an expression solver and other things to be implemented for importing. It would also likely mean we never have full coverage in design tools.

[ddamato]

It would also likely mean we never have full coverage in design tools.

On the contrary, right now we're waiting. We still haven't had the color format fully agreed on and it's been several years since the inception of the DTCG. If we instead had the ability to do any transformation to any combination of tokens, there's no waiting. All tools would be able to transform any tokens however a person needed.

[marcedwards]

Would the plan be for for the format to also include a library that handles the operations? Is it worth creating a different spec that meets your requirements?

[ddamato]

No, the plan would be for folks to create their own operations that could be shared as mentioned here. It's important that any operation is customizable and sharable, not beholden to any specific expectation except the author's.

As for a different spec, that might be a next logical step. Much of my expectations are written in this repo, sans each operation. However, all I'd be looking for is String, Number, and Math methods which result in new primitive values. That's why this is just an extension of the normal JavaScript ones. I'll imagine any language should be able to do these very basic transformations. Then the last piece is the import operations. The one for importing operations is outlined here, while the one for importing tokens was not implemented yet in the first pass.