Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Theme switcher proposal #703

Open
theetrain opened this issue Oct 29, 2024 · 3 comments
Open

Theme switcher proposal #703

theetrain opened this issue Oct 29, 2024 · 3 comments

Comments

@theetrain
Copy link

Currently, the theme toggle indicates when light mode or dark mode is active, but not 'system' or 'auto' user preference.

svelte.dev theme toggle

I propose we switch this to a 3-button switcher: light, dark, system (default). I can contribute this change if it's agreeable.

@Rich-Harris
Copy link
Member

It will respect the system preference if you select the mode that matches it (i.e. if your system is in dark mode and you're somehow in light mode, switching to dark mode will then mean that if you later switch the system to light mode the site will also switch to light mode).

If you set the site mode to something other than the system preference, it will persist across system preference changes.

While that's slightly convoluted when you say it out loud, in practice I think it works well. If someone switches their system to a different mode and is annoyed that svelte.dev followed suit, their annoyance will only last as long as it takes them to flip the toggle — thereafter, things will behave as they want.

To me that makes more sense than having a more complex UI, where you either need a dropdown (which is annoying from a design perspective — the edge of the current button lines up with everything else using var(--sk-page-padding-side)!) or a button that cycles through three different options (which is weird by itself) and where one of those transitions appears to have no effect beyond changing the icon on the button (and what's a universally understood icon for 'system preference'?). So at that point we're talking about tooltips, which aren't ideal on mobile, and more complicated code.

I'm open to being outvoted on this and I'd be curious to see successful prior art, but my gut tells me this isn't worth it.

@brunnerh
Copy link
Member

brunnerh commented Oct 29, 2024

Some examples, not sure about how "successful" they are. I suspect that they fall into the "decent enough" category.

YouTube
YouTube top menu

YouTube theme sub-menu

StackOverflow
StackOverflow preferences page

GitHub
GitHub appearance settings
(Kind of complex, you can choose from different themes that are used for either the light/dark settings of the system or set it one fixed theme.)


Given that the automatic theme should work for most people, I don't think clicking twice is too much of a hurdle for the few people that do want to switch to manual. I would go with either a simple dropdown or a small dialog.

The icon also does not need to be able to represent all states if you don't cycle on click, it can just be one icon symbolizing themes in general or one theme.

(Note by the way that SO & GitHub offer separate high contrast modes/themes for extra accessibility.)

@Rich-Harris
Copy link
Member

It takes 6 clicks to change the settings in GitHub, 3 in YouTube and Stack Overflow (took me a while to even find the settings there) compared to 1 for us. If we were to add high contrast modes etc then maybe the extra complexity would be worth it.

Our peer websites (React, Vue, Solid) generally have the same UI we do — a toggle — though React and Solid don't respect system preference, while Vue doesn't respect your site preference if it differs from the system preference as soon as the system preference changes to match the site preference.

So I think we're already in a good spot. There are many pressing concerns on the site and I don't think this is one of them to be honest.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants