In defense of two-state theme toggles

> Despite spending hours a day looking at her phone, she literally had to check it to find out what her default color theme is; it’s that invisible to her.

Sounds like a good reason to make it automatic then, because if users have to find your state toggle in some hamburger menu, they're not going to use it if they don't even know the system has a theme applied.

>Under the hood, rather than explicitly toggling between “light” or “dark”, it toggles between falling back to the system setting, and the opposite of the system setting.

Not sure I like this. Suppose my system is in dark mode because of low battery, but I want to read a page in light mode, so I change it. The next time I open the page with full battery (and thus system light mode), the page will render dark again...

> Despite spending hours a day looking at her phone, she literally had to check it to find out what her default color theme is; it’s that invisible to her. (Interestingly: she herself was surprised to find out she’s actually been looking at dark mode this whole time without even realizing it).

My wife’s phone has been in dark mode since before I married her, but most of the apps she cares about either don’t support dark mode (at least on her version of Android, older Samsung) or she has manually chosen light mode. The system preference and ability to swap it at night time or whatever is thus a bit of a mockery. (I mentioned it once, but didn’t change anything.)

> That is: rather than saving either a light or dark theme preference permanently in localStorage, Dr. Verou’s implementation stores your preference only if that preference is different than your device setting. In that case, the site saves whatever theme that happens to be.

Ironically enough, with the dark mode CSS, the inline code span is unreadable.

If the site defaults to system (which isn't guaranteed), very few people will need the toggle, at which point it can be omitted, or at least hidden deep in settings, and there is no need to put so much thought into its design.

I read this up until the monospaced use of the term `localStorage`, which for me (Firefox on Android) got rendered with a white background but did not invert the font, making it unreadable without highlighting it. I don't think I'm interested in someone's take on light versus dark theme if they don't seem to actually know how to make their own website work right with dark theme.

Having a light mode and a dark mode as the target of the setting, makes it impossible to use a light area versus a dark area to meaningfully suggest visually which one is selected. This stymies the designer completely, apparently.

There is a weird appeal to authority randomly added at the end of the article. Just because someone with a PhD has an idea on what may be good for users doesn't prove it actually is. Such a decision should be grounded in user studies and telemetry.

It annoys me to not be able to reset a preference so I always give the third option: for light/dark and for the language.

Why are UI people so determined to make apps as opaque and unusable as possible?

> rather than explicitly toggling between “light” or “dark”, it toggles between falling back to the system setting, and the opposite of the system setting.

Absolutely NOT.

> this unavoidably indicates that some number of users don’t even know what their system theme is—or might not even understand what “system” means in the first place!

Especially these people should NOT be given two state setting that depends on something third they do not know about. Yes, some people do not care about dark vs light setting. Let them not care.

I think I'd just separate the two things:

``` Theme ( ) Light (•) Dark

[x] Follow system Dark — currently controlled by system ```

When "Follow system" is on, the theme choice is greyed out.

Feels simpler to me, and it scales better if themes ever become more than just light/dark.