Re: [community-group] Conflicting language in "References and JSON Pointer Integration" (#383)

> That reference would have been much more reliable as e.g. {brand.primary.lightness} - a computed property that could be calculated for any color regardless of how you happened to define that color.

I want to point out, that this has nothing to do with JSON pointer syntax. Aliases have the same limitation—numbers are numbers, and not complex computed properties that translate across color spaces (which, I’ll add, is not even mathematically possible—translation between color spaces [is opinionated](https://bottosson.github.io/posts/gamutclipping/) which includes all components, not limited to lightness).

I think what you may be wanting here is something like [TokenScript](https://docs.tokenscript.dev.gcp.tokens.studio) or [DesignTokens Lang](https://docs.tokenscript.dev.gcp.tokens.studio), which are experimental examples of more complex computation than the current specification currently allows (which are very cool, by the way!).

> Either way, what can you do with a component value? Is this valid?
> 
> ```
>     "primary": {
>       "$type": "color",
>       "$value": { "colorSpace": "oklch", "components": [0.65, 0.18, { "$ref": "#/brand/hue/$value" }] }
>     },
>     "hue": {
>       "$type": "number",
>       "$value": 264,
>       "$description": "Shared hue for brand color family"
>     },
> ```

Yes.

> Is this?
> 
> ```
>     "primary": {
>       "$type": "color",
>       "$value": { "colorSpace": "oklch", "components": [0.65, 0.18, { "$ref": "#/brand/hue" }] }
>     },
> ```

No. That would embed the entire JSON pointer inside the array, producing a bad value. JSON pointers have a well-defined mechanism for how they work, and we haven’t changed that (the only thing we are changing, is the specification has recommendations on **when** these get resolved, so that the values are identical to aliases).

> This would seem a lot simpler for authors: … But at least in your example this would decouple you from the color declaration: … I don't know, JSON pointers seems to give you way too many options - it seems deceptively open-ended to me, a quick way to avoid specifying something more robust that doesn't couple you to protocol details.

I’m reaching here, but with your `"{brand.primary.hue}"` example, it sounds like you want something that’s a little more “magic” and offloads some details. But the very details you’re describing are what make aliasing so tricky no matter what the syntax or mechanism is. The very connections you yourself choose to make, and expose, and provide as “interfaces” for other tokens _is_ the tricky part! And trying to get a tool to make those decisions for you is impossible.

The JSON pointer syntax doesn’t really introduce any footguns here; they work exactly like aliases do. In some cases, the aliases simply prevented users from making some of these hard decisions, sure, but I wouldn’t say that’s an advantage. As stated elsewhere, we do want to lean into using JSON pointers because they have over a decade of prior art, there are hundreds of libraries and tools that already understand them, and are even built into most IDEs now (in the form of JSON Schema). But overall, you’re asking the right questions here of “what does this mean?” 🙂 I don’t interpret this as a problem with the syntax, rather, how we’d like folks to be exploring this.

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


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

Received on Sunday, 18 January 2026 17:50:27 UTC