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

> Theme switching should not be part of the spec

Fully agree with @equinusocio with emphasis on "switching", at least I assume that's what the emphasis should be on. How you switch between themes is heavily dependent on the output platform, and I feel like I should point out why with an example.

Let's imagine you have a button with light and dark mode, you might have the option to choose between two ways of outputting the CSS to accompany the way you switch themes in your site:

This example is the one I see most developers think of first:
```css
:root {
  --button-padding: 8px;
  --button-bg-color: #000;
}

:root[mode="dark"] {
  --button-bg-color: #FFF;
}
// or alternatively:
@media (prefers-color-scheme: dark) {
  :root {
    --button-bg-color: #FFF;
  }
}
```

That combines both modes into a single stylesheet, and following this pattern you would be including all theming options into 1 stylesheet. This is not ideal for performance reasons, your end users are downloading redundant kilobytes of CSS for rules that don't apply, because you can't both be on light and dark mode simultaneously. In the Web world, where initial load is super important for bounce rates (users leaving if sites load longer than 2 seconds etc.), the more ideal approach is to create different stylesheets:

`button.css`:
```css
:root {
  --button-padding: 8px;
}
```

`button-light.css`:
```css
:root {
  --button-bg-color: #000;
}
```

`button-dark.css`:
```css
:root {
  --button-bg-color: #FFF;
}
```

> Assume that the amount of CSS rules would be way more than 1, I'm just keeping the example simple, but the amount of KBs you save goes up fast with the amount of theme-specific CSS rules and theme variations you have in your output.

You'll have some utility that will allow theme switching to happen and for the stylesheets to be swapped out at runtime, [here's a demo of a run-time themable button](https://lion-example.netlify.app/) which applies this approach. [Here's the source code](https://github.com/tokens-studio/lion-example/blob/main/adjustAdoptedStylesheetsMixin.js) for the stylesheet switcher on theme toggle.

What this means is that the initial amount of KBs is far lower, because you're only loading the CSS relevant for the current chosen combination of themes/modes. Then, upon changing a theming dimension, you load the CSS needed for it on-demand. This minor delay when switching is the tradeoff versus a big delay on initial load, in Web context that is usually very much worth it considering that Web users tend to download your "app" on the fly, often coming from a search engine, and initial load matters a lot for whether they leave your site prematurely.

Now imagine Android or iOS apps, these are downloaded from the app stores, and the downloading is a conscious choice by the user where waiting a couple of seconds doesn't deter them from then using your app. Every variation of the app based on the theming dimensions is downloaded at once, making the switching between themes very cheap. This changes the "initial load" versus "switching delay" tradeoff in favor of the former, it's the opposite when you compare it to Web context. Putting all the themes outputs in the same file (e.g. a single `button.swift` or `button.xml` file) probably makes more sense for these mobile platforms, at least when you come at it from this particular performance/UX angle.

Hence a platform-agnostic design token spec should not have an opinion on the theme switching itself. I hope I've managed to make a good argument on why that is, why approaches to theme-switching is heavily platform-dependent.

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


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

Received on Monday, 19 February 2024 12:21:50 UTC