Re: [community-group] Adding technical report: Resolver (#289)

I wanna bring up another edge case / potential issue on order of resolution between sets.

Say I have the following resolver:

```jsonc
{
  "tokens": [
    // Sets my.only.token to #ff0000
    "base-set.json",
    {
      "type": "modifier",
      "name": "theme",
      "context": [
        // Sets my.only.token to #ffcccc
        "light": ["light.json"],
        // Sets my.only.token to #660000
        "dark": ["dark.json"]
      ]
    },
    // Sets my.only.token to #0000ff
    "token-set-that-messes-everything-up.json"
  ]
}
```

What should the value of `my.only.token` be when there is no mode? When in light or dark mode? 

I personally expect that resolutions should always be chained sequentially, because that gives me full power to decide on who has authority over the final value of a token. So I expect `my.only.token` to be `#0000ff` in every mode in this scenario.

Issue 3 on the spec makes it sound like mode precedence should be declared/decided regardless of the order in which modes are defined; whereas I believe the last-declared mode should take precedence, on a token-per-token basis.

So, if I have a resolver like:

```jsonc
{
  "tokens": [
    "org-wide/base.json",
    {
      "type": "modifier",
      "name": "color-scheme",
      "context": [
        "light": ["org-wide/light.json"],
        "dark": ["org-wide/dark.json"]
      ]
    },
    {
      "type": "modifier",
      "name": "client-brand",
      "context": [
        "client-a": ["product-foo/clients/a.json"],
        "client-b": ["product-foo/clients/b.json"],
      ]
    },
    {
      "type": "modifier",
      "name": "color-scheme",
      "context": [
        "light": ["product-foo/light.json"],
        "dark": ["product-foo/dark.json"]
      ]
    },
  ]
}
```

There could be some tokens overridden by the client brand that then still get overridden by the more specific color-scheme mode sets. Maybe for instance a team enforces a specific outline color in dark mode to fix a contrast issue, which was previously customisable by clients but only worked in light color-schemes. But most tokens overridden in client brands ought to be preserved.

And so:
* color.border.focus set in `org-wide/dark.json`, `product-foo/clients/a.json`, `product-foo/dark.json` and prioritises color-scheme modes
* color.background.foo set in `org-wide/dark.json` and `product-foo/clients/a.json` and prioritises brand modes

If mode precedence was handled outside of the order in which sets are defined, and if it wasn't handled on a token-per-token basis, we'd then be unable to actually override any token after it's been tainted by a mode.

Or we'd have to say that tokens can only belong to a single mode to prevent these scenarios altogether (which reintroduces combinatioral explosion of modes when combining color blindness support, theming X white-label and color-scheme preferences).

The implication of what I'm requesting is dire, though: CSS outputs can preserve the prioritisation outlined in a chain of resolved sets. But Figma cannot yet. Tailwind and friends cannot yet. They'd need to find their own ways to handle specificity/priority in how a token value is set.

-- 
GitHub Notification of comment by Sidnioulz
Please view or discuss this issue at https://github.com/design-tokens/community-group/pull/289#issuecomment-3362163458 using your GitHub account


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

Received on Thursday, 2 October 2025 16:54:04 UTC