Re: [community-group] Native modes and theming support (#210)

> so the token can take 144 permutations in this example - if there was a value for all of them (which in reality I wouldn't expect).

Definitely agree! That's one of the reasons why we are pushing for fallback definitions for each mode, as well as overrides being optional. You shouldn't have to define all permutations.

> Modes is the wrong word to this

Modes is the wrong word if you're only supporting color. What complicates things is that design tokens are used for _many_ use cases, color just being one of them. We originally were using `theme` and `color-scheme`, but we found it didn't apply for other use cases of tokens. Here are the use cases we came up with that we felt the terminology should support:

- visual themes (i.e. light/dark)
- product/brand themes (i.e. docs/sheets/slides)
- accessible themes (high contrast, colorblind modes)
- dimensions and platform size differences (mobile/desktop/tablet)
- UI string translations / alternatives (i.e. english/spanish/german)
- and likely more in the future! What happens with depth is a factor for VR/AR?

In the end we found that `color-scheme` simply didn't work outside of color (i.e. a mobile color scheme doesn't convey that you're talking about differences in padding), anything that's specific like that also encounters issues of not being scalable for future use cases. 
`theme` was great for color as well, but it didn't work well for things such as translations (i.e. a "German theme" feels like you're going to have a bavarian/oktoberfest vibe, not having strings translated to German). We ran a survey among a few different disciplines and users, and found that `mode` was the least-bad option for a generic term. It was the 2nd choice among the 3 cohorts we tested: visual designers, content designers, and those working explicitly on dimensionality - not their first choice, but one that still made sense for their use case. 

---

The permutation structure you suggest is interesting - treating each permutation as a flag rather than an individual grouping. I'm not a huge fan of the readability of it (though I'm not sure if that matters for an interop format), but I see the value. Would be curious on the needs of this vs explicit modes. One thing to call out is with this approach you'd need some very explicit logic around missed finds, as with this approach it's possible for no correct value to exist. 

As an example, if you had:
```
{
  "$name": "intent-action-base-background",
  "$value": [
    {
      "$value": "white"
    },
    {
      "$value": "darkgrey",
      "color-scheme": "dark"
    },
    {
      "$value": "black",
      "color-scheme": "dark",
      "color-contrast": "high"
    }
  ]
}
```

And you queried for: 

```
const token = tokens.find(t => t.name === 'intent-action-base-background');
const value = token.value.find({ 
  colorContrast: 'high' 
});
```

Would you return `black` or `white` in this case? There's no explicit definition for `color-contrast: high` without dark mode defined. Do we then return the dark mode value? Or do we return the light value? 

If invalid queries like this aren't allowed, validations would be non-trivial as they'd be exponential in nature to test. A flag based approach is definitely going to need more thought. 

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


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

Received on Wednesday, 29 March 2023 23:22:25 UTC