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

The mechanism and distribution of switching should definitely not be the
purview of the tokens, but the theming classification itself, 'what token
changes how for what theme', definitely should be the purview of tokens,
and specifically - I would prefer a solution better than multiple token
files and leaving the theming control on the filename than the tokens
themselves.

On Mon, 19 Feb 2024 at 17:52, Joren Broekema ***@***.***>
wrote:

> Theme switching should not be part of the spec
>
> Fully agree with @equinusocio <https://github.com/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:
>
> :root {
>   --button-padding: 8px;
>   --button-bg-color: #000;
> }
> :root[mode="dark"] {
>   --button-bg-color: #FFF;
> }// or ***@***.*** (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:
>
> :root {
>   --button-padding: 8px;
> }
>
> button-light.css:
>
> :root {
>   --button-bg-color: #000;
> }
>
> button-dark.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.
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/design-tokens/community-group/issues/210#issuecomment-1952337677>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AEKS36HOTXOBDX2LPLFVL2TYUM7WZAVCNFSM6AAAAAAWEORCF2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJSGMZTONRXG4>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>


-- 
GitHub Notification of comment by nesquarx
Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/210#issuecomment-1952765910 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 15:59:39 UTC