Notes on implementing dark mode | Hacker News Reader

Notes on implementing dark mode

brandur.org

50 pointstln20 comments

We are working on a W3C proposal to hopefully improve both the DX and UX of setting dark/light so that developers can avoid hacks around FOUC, doubling up all CSS and needing JS on every page load to check the state.

You can read more about it here: https://github.com/WICG/web-preferences-api

Feedback is welcome

How about some colour ? Not everybody loves black and white (or dark gray and light gray).

The main thing I feel here is that generally people want the ability to have site specific preferences for dark mode / light mode and this doesn’t seem like it enables that.

Also the problem it’s solving is not that big, it’s literally less than a dozen lines of JS. These “hacks” are exceptionally well documented solutions that exist for about every possible framework or library.

Idk maybe I’ve just built out the solution for it too many times and now I think it’s easy. I am still learning how to better implement the solution, including using inline JS to avoid the color change. But still I have a hard time understanding how moving this logic into the browser would help people.

The first thing I noticed is that the site didn't respect my dark mode preference because I have JavaScript disabled.

So there's still some work left here until I'd call the implementation "great".

(A simple css check for prefers-color-scheme handles this.)

Something I don’t understand is: why do we need to allow the user to explicitly set dark mode or light mode? Why can’t we just check prefers-color-scheme and leave it at that?

Because I don't universally prefer light or dark in all cases at all times?

I'm also part of multiple organizations (in different contexts, as a subcontractor at work I have two orgs to answer to, for instance). I use customized settings to distinguish Work A from Work B when accessing the same application but with different user accounts. Yeah, I prefer dark mode but I'll use light mode for my actual employer (used the least) if I don't have other customization options.

Surely there is a browser plug-in that will allow you to prefer light mode for some sites and dark mode for others? Or even add a toggle to the browser UI?

I don’t see the value in having this implemented by individual websites.

Your average user wouldn't even know that there's a standard css property that a plugin could potentially control; though, yeah, it being a browser toggle would make it rather obvious (...assuming it's front-and-center somewhere, which is a rather high ask). Definitely won't find a location to place it that requires one click to toggle on mobile browsers, though.

Having the in-browser toggle would also be rather questionable for anything that has more than just "light" and "dark"; the options suck - either having the browser-based toggle be a "shortcut" for one toggle in your main theme settings (which likely means users are less likely to notice the full settings), or abandon the browser toggle entirely (which likely means a significant amount of users would assume there's no theming at all). And neither really fits for something that has, instead of just "dark" and "light", an additional "high-contrast" mode (which, depending on what the site's designers bothered to do, could be an extension of "dark", or a toggle combinable with either light or dark); so you'd want the browser-based toggle to be at least somewhat customizable. Also worth considering is that if there's some fixed set of things that the browser-level theme toggle can do, sites would be very heavily disincentivized from adding any other things as those would then require an entirely custom theming setting panel.

I'm exaggerating somewhat, sure, but I don't think you'll find any way to have a browser-level theme toggle that doesn't end up pretty bad in a significant number of cases.

At our product we allow to the user to set his specific preference light/dark, or have it be set by the browser setting

Because it turns out that while this might sound like the easy, simple, convenient, right thing to do, if you try it (as we did), what happens is that people will forget or not understand they set it, and be unhappy and complain: https://gwern.net/design-graveyard#auto-dark-mode

(You can do the fallback to the CSS prefers setting, to try to not break dark-mode users, but if at all possible, you do want some sort of widget or toggle - at least for now. I am hopeful that in maybe 5 years it can be removed and users assumed to understand it.)

:-(

I prefer my OS in dark but every website in light, it's always a hassle when a website decides for me based on my OS setting which I wouldn't want to extend beyond the OS chrome.

Sounds like a problem both caused and solvable by your web browser.

At least with Firefox it is possible to style it dark while setting prefers-color-scheme to light.

But then how would everyone know that you've implemented dark mode like everyone else? You'd be a laughing stock with your pre-2019 website.

For the next version of my site I'm not going to include the toggle. It's not worth it.

Overall pretty neat. Not a huge fan of the three-way toggle though. Two-way toggles are plenty confusing already.

Yep, this is the way. You can test it works in Firefox dev tools by forcing the dark/light browser settings (you can set it to print too to test your print stylesheet).

It's a shame there isn't a standard high contrast setting, though. That seems more important than dark mode. Oh well.

There's one more detail along the lines of theme changes in other tabs and theme preference changes from the OS/browser: activating the correct theme following history navigation. When I navigate to another page of the author's site, change the theme from light to dark, and then use my browser's back button, I get the light theme again. On my own site I use the `pageshow` event to fix this (https://github.com/meribold/meribold.org/blob/afe6885/_inclu...).

The extra effort is only needed on Firefox and Safari, though. Chromium already handles this somehow.

Nicely done. Very thorough.

Now I have to check if my implementation supports cross-tab changes...

Are you the author? I am curious about how people write TextMate grammars. I can't really find (good) resources on it and I find it hard to reverse engineer existing grammars to understand them.

Reply on news.ycombinator.com