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

> ## 1. There are times where someone will care about and want to use multiple themes at the same time.
> Which is to say, it isn't always true that someone works with one theme at a time. A few cases that demonstrate this: a. One part of a page/view uses the "dark" theme, and a different part uses the "light" theme (see below) b. One part of a page/view uses both a "dark" theme, and a "high density" theme, and a "brand X" theme.

It seems I need to be more clear in the distinction I'm trying to make. Yes, we want to use multiple themes at the same time but I don't think anyone wants to _curate_ multiple themes at the same time. In order to create a light theme, I need to put my mind into the context that everything in this area is colored in "some light way". In any of these proposals, we can still apply multiple themes.

> ## 2. Theme metadata like features, tags, priorities, and theme types may be over-complicating the spec
> While the proposals by @gossi and @ddamato are very thoughtful and well-articulated, I worry that building too many new features into the spec is shifting complicated functionality from platforms up into the tokens format and into token translation tools themselves.

No matter what, the end of this thread will be suggesting a new feature.

> How interfaces are styled based on contexts — user-selected theme, accessibility preferences, localization, etc — varies widely from platform to platform. CSS, JS, Swift, Objective-C, Java, and Kotlin each have their own capabilities, quirks, and best practices for contextual styling. I think we should leave the complexity of understanding user contexts and applying styles to the UI to those platforms.

While I agree that the execution of the tokens against the UI will differ, I argue that the intentions do not. Declaring some part of the UI to be the "button background color" is persistent across interfaces, the way in which that is assigned is determined by the platform. What I recommend is that the tokens file describes intentions and the platforms ingesting these tokens know enough about their own infrastructures to make necessary transforms from there.

> The token spec can (and I think, should) provide a high-level map that can be used by the platforms, but to make interoperability easy, it should be as lightweight as possible.

Agree, except:

> ### Example: a dark theme and light theme with token aliases in a single file
> ```json
> {
>   "colors": {
>     "white": {
>       "$type": "color",
>       "$value": "#ffffff"
>     },
>     "black": {
>       "$type": "color",
>       "$value": "#000000"
>     }
>   },
>   "$themes": {
>     "light": {
>       "foreground": {
>         "$value": "{color.black}"
>       },
>       "background": {
>         "$value": "{color.white}"
>       }
>     },
>     "dark": {
>       "foreground": {
>         "$value": "{color.white}"
>       },
>       "background": {
>         "$value": "{color.black}"
>       }
>     }
>   }
> }
> ```

This single file is going to become unwieldy with the number of tokens and brands that some organizations possess. It seems fine for light and dark, but we've already had examples of other modes, markets, and experiments that simply should not coexist because their purposes are fundamentally different.

Returning to the basis behind my recommendation. Splitting each file by purpose focuses the curation exercise to the reason why this specific collection of token-value assignments needs to exist. This reduces the problem down to the one I mentioned above:

> _How do we encode the purpose for this specific theme into a well-defined schema?_

We can work with the spec as-is without defining this moving forward and still support theming. Systems need to request the appropriate file which represents the theme. What I proposed earlier is an attempt to standardize _how_ a system might determine which collection of token-value pairs to deliver. Since having an arbitrary key (ie. `light`) means a system must specifically look for this one theme versus a system looking for a best match. Again, not important to v1 of theming.

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


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

Received on Tuesday, 18 April 2023 16:00:06 UTC