// HACKER NEWS — CYBERSECURITY
In defense of two-state theme toggles
In case you haven’t kept up on the most recent bikeshedding discussion in frontend: there’s a lively debate going on over the merits of a simpler two-state theme toggle (light/dark), vs. a more explicit three-state toggle (with dark and light, plus a third “system” option), and whether the clarity of that third option is worth the additional complexity it introduces.
But let’s back up to where this discussion started, and talk a little bit more about the details and tradeoffs those two approaches, before I start weighing in on what I think is (and is not) ideal, and why.
A couple of weeks ago, Lea Verou published an excellent post titled Dark mode toggles: two states are enough. (Evidently, this discussion had been ongoing for a good while prior.)
The post is thorough and insightful. Dr. Verou lays out her case that a two-state is enough most of the time, in the case of a switch that’s part of the main site UI. That last part’s important:
In most cases, users aren’t looking for that third “system” option, and aren’t likely to find it useful. They’re just looking for the light switch.
In most cases, users aren’t looking for that third “system” option, and aren’t likely to find it useful. They’re just looking for the light switch.
There are, of course, exceptions. For example, in a dedicated settings page, where the mental model is less “what do I want right this second” and more “what do I want this app to be like in the future?” a three-state toggle makes more sense. Dr. Verou’s post makes this abundantly clear, and I tend to agree.
Aside from the binary vs. trinary discussion: I find Dr. Verou’s two-state implementation particularly clever. 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.
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.
Otherwise—or should the user toggle the theme once again—rather than storing the newly selected theme (which now once again matches their OS preference), the saved preference is simply deleted, causing the site to once again default to the device preference. This is important, because a common criticism of binary light/dark controls is that they lock you into one or the other, with no way to get back to your system preference; this two-state toggle neatly avoids that lock-in.