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

Oh, so wonderful thoughts in your answer :) 

PS. While typing my answer @c1rrus also posted (I will read his post after I posted mine). This is a response to @jjcm 

I think, `permutation` (as odd as it sounds) is the word I used most for to describe those varying token values. It is not as much as opinionated as mode - wdyt? Perhaps not necessary, as values might be best as an array?! 😅 

---

I thought about validation and fallback a bit more after posting here. Here is a bit more of what's in my head. 

Do we want to have a fallback for the sake of having a fallback, because we _want_ to have it or because it _must_ be there? I think we are going with fallback, because we _want_ to have it to avoid dealing with the complexity that awaits us. And is fallback even a _correct_ value then?

About features, these are defined by your product/theme/design system - they may or may not live within the token file. The bonus of having it is to that you can validate the file by itself, which I'd actually in favor of having - or this can be set as reference:

```json
{
  "$reference": "path/to/features.tokens"
}
```

I think, having validation _is_ important. I'm author of [theemo](https://theemo.io) and am currently working on v2 which actually is about letting designers define their features and then provide a UI for letting them define values for a token based on features - sounds familiar?

Here is the challenge: Let's say you defined two features, color-scheme (light/dark) and color-contrast (low/high) and you have a color token with a given value. Now you want this token to support color-scheme. Your UI splits into two input fields one for light one for dark and copies over the value from before into the two new input fields. Let's say the value from before was set for light color-scheme, the designer now will choose a value for dark color-scheme.
The token stays valid as long as there are two values present. The original value before this token support color-scheme feature is no longer relevant (=> no fallback needed, the fallback became the light color-scheme value). The UI can validate if the token has support for all values based on the features the token shall support.

Next up: Let's make this token support color-contrast feature. We will be presented with a 2 x 2 input matrix. Same drill again for the designer. However, if low contrast was considered the default, then the designer would only change the values for high color-contrast. 
The values for low color-contrast can even be omitted. This is the "none" case in the picture above. The fallback here are the two color-scheme values without color-contrast.

That is a token is valid as long as permutations of a supported feature are matched with permutations of other supported features - hell, this is a heck to explain in words. I'm having [truth tables](https://en.wikipedia.org/wiki/Truth%20table) in my mind here, where you can cluster groups.

What's important to note here is, that features will have a default, which would ease building UIs and help validate (from my research before, I never find a case where there is no default, this will always ever be provided by someone - the OS at last). Let's say our default for color-scheme is light and revisit the process from above. The designer would choose to support color-scheme for a token, the previous value is copied into light color-scheme (the default) and leaves the designer to fill out only the dark value. Same for color-contrast set to low as default, when supporting color-contrast on the token, the UI would only show the option to the designer to fill out values for high color-contrast.

Which brings us back once more to fallbacks: The fallbacks are the default values of a feature.

That is a fallback for the entire value set is wrong, think this: If you have a fallback value (that was set for light color-scheme and low color-contrast) and as a user you want to experience a product in dark color-scheme and high color-contrast. If there is a value given for dark color-scheme but low color-contrast and the fallback value - which one to serve to users?

Which brings us to your question:

> 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?

I think there are two options here to answer this:

1. That's an invalid token, as the request you are having cannot be answered - because explicitely matching your query does not work
2. Assume the default for `colorScheme` and combine it with the query for `colorContrast` to return the appropriate value


When _authoring (build time)_ we are in need of defining a default (this is truly a _mode_ <sup>*<sup> here). Whereas in _experiencing a product (runtime)_ as a user, a preference is given (by the the default from the product, by the platform (browser) or latest by the OS). With that preference present the correct token value can be found.

<sup>*<sup> maybe this was the case for calling it `mode`? 

---

I have been playing around with typing this to work on `theemo` - as typing is a good way to prototype this and figure out problems. In the `next` branch (I gave it a push right now), there are types in [`@theemo/core`](https://github.com/theemo-tokens/theemo/tree/next/packages/%40theemo/core/src) - I've been playing with only the features the web offers through media queries (`color-scheme` and `color-contrast`), but potentially could be more.

A theme in theemo would be to it's current state defined as:

```json
{
  "name": "super theemo",
  "features": {
    "color-scheme": {
      "behavior": "adaptive",
      "default": "light"
    },
    "color-contrast": {
      "behavior": "mode",
      "default": "low"
    }
  } 
}
```

`behavior` is for the implementation on the product (ignore, see post above) but `default` will be used for constructing the UI for designers to pick a proper value as well as the algorithm to find the correct token value.

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


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

Received on Thursday, 30 March 2023 09:14:14 UTC