How might I better manage alpha values

[snicol21]

If I have an entire color palette, and want to somehow take a color at 80% transparency, I was hoping to be able to do something like this:

"overlay": { "$value": "{color.gray.90}{alpha.80}" }

but sadly this didn't work. the thought was that I could take a list of alpha values and attach them to the end of my hex values:

"alpha": {
  "$type": "alpha",
  "80": { "$value": "cc" }
}

any thoughts on the best way to do this ... aside from duplicating my entire color palette 9 times?

I also recognized that the culorijs library can easily handle alpha values, wondering if there's a way we can attach an alpha percentage to a color and let the culorijs library handle it

something like this:

"overlay": { "$value": "{color.gray.90}", "$alpha": 0.8 }

and then let the normalizeColorValue method that uses culorijs attach this for you?

[snicol21]

As a workaround, I had to write a script that generates a bazillion opacities for my entire color palette, essentially rendering something like this

{
  "_color": {
    "$type": "color",
    "gray": {
      "10-10%": { "$value": "#f2f5f71a" },
      "10-20%": { "$value": "#f2f5f733" },
      "10-30%": { "$value": "#f2f5f74d" },
      "10-40%": { "$value": "#f2f5f766" },
      "10-50%": { "$value": "#f2f5f780" },
      "10-60%": { "$value": "#f2f5f799" },
      "10-70%": { "$value": "#f2f5f7b3" },
      "10-80%": { "$value": "#f2f5f7cc" },
      "10-90%": { "$value": "#f2f5f7e6" },
      ...
      "30-10%": { "$value": "#c1ccd61a" },
      "30-20%": { "$value": "#c1ccd633" },
      "30-30%": { "$value": "#c1ccd64d" },
      "30-40%": { "$value": "#c1ccd666" },
      "30-50%": { "$value": "#c1ccd680" },
      "30-60%": { "$value": "#c1ccd699" },
      "30-70%": { "$value": "#c1ccd6b3" },
      "30-80%": { "$value": "#c1ccd6cc" },
      "30-90%": { "$value": "#c1ccd6e6" }
    }
  }
}

But does seem to clutter up my tokens a bunch.

[drwpow]

Yeah this is a great question! There’s some current debate over how to take this approach. As you’ve discovered, the only way to embed opacity is in the token itself, which makes it unwieldy.

It’s also probably not a good usecase for Cobalt modes because you likely want to use multiple opacities together in a palette like your script is doing ☝️.

I don’t think there’s a one-size-fits-all solution to this problem, but here are all the ways I can think of to deal with it:

1. Manually generate all values (above solution). This shifts the burden of opacity onto the DS designer to engineer the solution. This probably was done using an external tool like Leonardo. While this works, it’s hard to get this right first attempt, and is hard to edit/maintain. Probably more a limitation of tools than the preferred approach.

2. One-off modifiers. The most mature example of this I’ve seen is Token Studio’s Color Modifiers. This is great for single values, and even modes (e.g. shifting a color subtly for dark mode). But if you need an entire scale of this can be just as hard to edit/maintain as the previous one.

3. Code overrides. This is the “anti-token approach” because it overrides the token at the code level. And must be done in one-off fixes that erode the usability of the DS itself. But you could always manually modify opacity in CSS with:

   background: color-mix(in oklab, var(--color-gray-90), 20% transparent);

   But again, this is more of a temporary bandaid than a holistic solution.

4. Automatic ramps. Tools like ColorBox, chroma.js palette helper, and Leonardo can all be baked into the tool itself, but the problem is choosing one! Does the scale optimize for a11y contrast or hue spread? Does the ramp use sRGB or Oklch? Should the ramp use easing curves (and are these even useful)? There’s a danger of a tool leaning too hard in a certain direction and alienating the designers that need something different (or accidentally shoehorning designers into creating the same ramps as each other because the methodology is flawed).

   Sidenote: I know color ramps don’t explicitly refer to opacity, but I see opacity as just a different type of color ramp—albeit slightly more complex as it involves layering

   There’s also a bit of a chicken-and-egg problem where coding design token tools can generate color ramps/opacity adjustments easily, but most designers that create the DSs aren’t using code. But the color ramps are the DS itself, and need to be incorporated in the design program. Ideally in the future we’d see a flattening of DS tooling where DS creation and token management are all the same tool.

   TL;DR this is the “holy grail” of solutions but this isn’t a solved problem by any stretch

---

As it relates to Cobalt, I’d be open to thinking about supporting 2. One-off modifiers as a relatively-safe solution that would be easy to implement (something like $extensions.transformColor) and wouldn’t conflict with the specification if it came up with a different solution. We could also even allow this at the group level as well to cascade to all children (e.g. if you had a color.gray.alpha.* group, you would have to manually name & alias all the individual tokens underneath but would only need to declare $extensions.transformColor once at the group).

I quickly scanned through the open W3C Design Token issues and didn’t see a solid proposal re: color transforms but will look again before attempting to add something (and if this becomes a thing in Cobalt I’ll open a “what we’re trying” discussion thread there just for visibility & feedback).

4. Automatic ramps is front-of-mind for me (if you couldn’t tell) but I haven’t come across “the one true way” to generate color ramps purely programmatically; I believe this does have to have a GUI component in order to be usable. The only GUI Cobalt interfaces with is Tokens Studio, but as this is OSS (and will always be) I don’t know if that’s sustainable because even one-off color modifiers is a paid feature 😓 (I’m not involved with Tokens Studio and wouldn’t encourage people spend any $ on a private tool).

[drwpow]

Ah for 2. One-off modifiers there is a good discussion on this! Pre-defined composite type for refering color modifications (e.g. rgba). And this references alpha exactly as you mentioned.

Several comments mention a suggestion of an $operations key (most recent comment here):

{
  "primary-color-overlay": {
    "$type": "color",
    "$value": "#fffc00",
    "$operations": [
      0.5,
      ["String.match", "$value", "#([0-9A-Fa-f]{2})"],
      ["String.match", "$value", "#(?:[0-9A-Fa-f]{2})([0-9A-Fa-f]{2})"],
      ["String.match", "$value", "#(?:[0-9A-Fa-f]{4})([0-9A-Fa-f]{2})"],
      ["Math.parseInt", "$1", 16],
      ["Math.parseInt", "$2", 16],
      ["Math.parseInt", "$3", 16],
      ["String.concat", ",", "$4", "$5", "$6", "$0"],
      ["String.concat", "", "rgba(", "$7", ")"]
    ]
  }
}

This would make sense to me. Of course, I’d still probably lean toward $extensions.operations just as a safeguard as this still feels too early to bank on (and the worst-case scenario is if Cobalt adopts an API for $operations but the spec decides to use that key for something else or a completely different API)

[snicol21]

Once again, I really appreciate the thoughtful response. This is exactly the type of thing I was looking for. It's a little unclear to me how this $operations example above would work. Reading through the community group discussion there were multiple options proposed and I think i like this $operations idea, but do you have an example of how this would work in my scenario with a base color of like {color.gray.90} with an operation that adds an alpha value of 0.8?

[drwpow]

Yeah agreed this API is unclear. Speaking personally this would be my nightmare to try and edit. And I think doesn’t hit the goal of the Design Token spec being “human readable and writable.” Not married to this or anything but a simpler approach (inspired by another comment earlier in the thread) might be better:

{
  "primary-color-overlay": {
    "$type": "color",
    "$value": "#fffc00",
    "$operations": {
      "alpha": 0.5, // optionally could alias a `number` token
      "mix": {
        "colorspace": "oklab", // @see https://github.com/design-tokens/community-group/issues/79
        "color": "{some.other.color.token}",
        "amount": 0.5 // also could alias a `number` token
      },
      // (other operations here)?
    }
  }
}

This would be more limiting, of course, but would be sane to use. I also think this could apply to groups as well if you wanted it to cascade to all children (or maybe you just set an empty $operations: {} key on a child if you wanted to exclude it).

Again, just thinking out loud; not super tied to any of these concepts yet.