Variable references for CSS

[azan-n]

CSS Variables are declarative which allows the client-side JS to do quite a lot with just a few (or one CSS variable).

I am generating ramps/palettes for an application using a single hue value and OKLCH, which I then allow the user to change and save for their personal accounts. Which would mean I have ramps defined like

--primary-hue: 240;
--swatch-1:  oklch(0.99 0.003 var(--primary-hue));

I'd like to emulate this using Cobalt where {ref.value} implicitly creates a CSS variable. This also helps greatly for when you have variable type scales, widths, rounding, et cetera that you want to change on the client (my best wishes for the people who built CSS variables).

{
    "color": {
        "primaryHue": {
            "$type": "dimension",
            "$value": "240"
        },
        "primary": {
            "10": {
                "$type": "color",
                "$value": "oklch(0.99 0.003 {color.primaryHue})"
            }
        }
    }
}

I also tried an alternate approach where I could possibly say

    "color": {
        "primary": {
            "60": {
                "$type": "color",
                "$value": "oklch(60% 0.216564 var(--primary-hue))"
            }
        }
    }

which returns a Error: invalid color "oklch(60% 0.216564 var(--primary-hue))"

[drwpow]

I see what you mean, but unfortunately this isn’t currently possible. The reason is that w3c aliases aren’t allowed just anywhere (they can’t be in the middle of another value); they have to be either the entire $value, or if the $value is an object type, it has to make up an entire property (composite types only). So I don’t think an alias in the middle of a string would ever work.

Similarly, there may be a way to hack the CSS var(…) syntax, but IMO that should be avoided because that means your tokens could only ever be used in CSS (at which point, why not just define them there?).

The spec authors have been playing around with an expanded color type that would allow aliasing individual channels, like so:

{
  "primaryHue": {
    "$type": "number",
    "$value": 
  },
  "primary": {
    "10": {
      "$type": "color",
      "$value": {
        "colorSpace": "oklch",
        "channels": [0.6, 0.216564, "{color.primaryHue}"],
        "alpha": 1
      }
    }
  }
}

but sadly there’s nothing close to consensus on this yet so there’s a high likelihood this syntax as-written never ships (so I wouldn’t want to make Cobalt depend on it)

---

The only workaround today is to just copy + paste everything manually. Which at first sounds like it’s antithetical to what you want to do. But when you realize many palettes hue shift as they move up/down the scale it might not be such a bad thing. In another sense, locking one axes of your palettes may not be as flexible as you might think!

But again, I do think that it’s likely the spec will allow for more color operations soon as it’s the most-requested feature. So there will be a way to do what you originally asked for, but it’s unclear what that would look like today. A proposal may just have to reach more consensus before I’d want to support it in Cobalt (which, by the way, proposals can come from anyone—maybe one you propose will be the right syntax!).

[drwpow]

As an aside, a visual editor for color palettes is something I’m actively working on now, and hope to be able to share before the end of the year 🙂

[azan-n]

Similarly, there may be a way to hack the CSS var(…) syntax, but IMO that should be avoided because that means your tokens could only ever be used in CSS (at which point, why not just define them there?).

Yes, that makes no sense. I was just thinking out loud.

but sadly there’s nothing close to consensus on this yet so there’s a high likelihood this syntax as-written never ships (so I wouldn’t want to make Cobalt depend on it)

That would be interesting and would also solve issues with alpha values but I guess it still is a long shot based on what I can tell from the discussion.

But when you realize many palettes hue shift as they move up/down the scale it might not be such a bad thing. In another sense, locking one axes of your palettes may not be as flexible as you might think!

I recognize that but with the current complexity of the software and issues with maintenance, I think the hue shift isn't as bad as generating ramps on the fly on both client and server side with different toolsets.

As an aside, a visual editor for color palettes is something I’m actively working on now, and hope to be able to share before the end of the year 🙂

I'm looking forward to it. I've been following this project for a while and will be glad to help out with any dev work with the other as well.