This is not that blog post. I’m saying let’s say you were.
This is not a knock any other blog posts out there about Dark Mode. There are lots of good ones, and I’m a fan of any information-sharing blog post. This is more of a thought exercise on what I think it would take to write a really great blog post on this subject.
- You’d explain what Dark Mode is. You wouldn’t dwell on it though, because chances are are people reading a blog post like this already essentially know what it is.
- You’d definitely have a nice demo. Probably multiple demos. One that is very basic so the most important lines of code can be easily seen. Perhaps something that swaps out
background-color
andcolor
. The other demo(s) will deal with more complex and real-world scenarios. What do you do with images and background images? SVG strokes and fills? Buttons? Borders? Shadows? These are rare things that sites have, so anyone looking at designing a Dark Mode UI will come across them. - You’d deal with the fact that Dark Mode is a choice that can happen at the operating system level itself. Fortunately, we can detect that in CSS, so you’ll have to cover how.
- JavaScript might need to know about the operating system choice as well. Perhaps because some styling is happening at the JavaScript level, but also because of this next thing.
- Dark Mode could (should?) be a choice on the website as well. That serves cases where, on this particular site, a user prefers a choice opposite of what their operating system preference is.
- Building a theme toggle isn’t a small job. If your site has authentication, that choice should probably be remembered at the account level. If it doesn’t, the choice should be remembered in some other way. One possibility is
localStorage
, but that can have problems, like the fact that CSS is generally applied to a page before JavaScript executes, meaning you’re facing a “flash of incorrect theme” situation. You might be needing to deal with cookies so that you can send theme-specific CSS on each page load. - Your blog post would include real-world examples of people already doing this. That way, you can investigate how they’ve done it and evaluate how successful they were. Perhaps you can reach out to them for comment as well. If there are some bad examples out there, you should cover those too, sometimes learning is best done by learning what to avoid.
- You’ll be aware of other writing on this subject. That should not dissuade you from writing about the subject yourself, but a blog post that sounds like you’re the first and only person writing about a subject when you clearly aren’t has an awkward tone to it that doesn’t come across well. Not only can you learn from others’ writing, but you can also pull from it and potentially take it further.
- Since you’ll be covering browser technology, you’ll be covering the support of that technology across the browser landscape. Are there notable exceptions in support? Is that support coming? Have you researched what browsers themselves are saying about the technology?
- There are accessibility implications abound. Dark Mode itself can be considered an accessibility feature, and there are tangential accessibility issues here too, like how the toggle works, how mode changes are announced, and a whole new set of color contrasts to calculate and get right. A blog post is a great opportunity to talk about all that. Have you researched it? Have you talked to any people who have special needs around these features? Any experts? Have you read what accessibility people are saying about Dark Mode?
That was all about Dark Mode, but I bet you could imagine how considering all these points could benefit any blog post covering a technical concept.
I’d add the considerations …
what the benefits of Dark Mode are,
how it’s linked to a High Contrast Mode,
if it’s not just a stylish hype set in motion by apple,
what the OS does automatically if a user has chosen Dark Mode as default,
and when it’s worth the effort.
Maybe spice it with some figures about the readability of white text on black background.
But I didn’t find sufficient answers to this questions yet, so no blog post by me so far.
I would definitely read a blog post like that ;)
I’m not arguing that there isn’t, but what would the use case be for announcing a theme change? Isn’t that strictly visual? I understand how it could apply to most accessibility-related things, like sighted users using a keyboard or other navigation device, and therefore needing the toggle to be focusable and etc.
But aural feedback? I guess you could say, “Well some sighted users still like to use screen readers”. And while that’s definitely true, theme changes still aren’t really a matter of content, but rather visuals.
I know this isn’t a blog post about dark mode so this may not be the right place for the discussion, but I thought it was interesting nonetheless. I’ve run into other situations where I wondered if something should be made straight-up inaccessible (at least in terms of aural feedback), precisely because it was strictly visual, but it just feels wrong to do. Just not sure why. So maybe this is a whole topic in and of itself.
Just drop here to say that for JAMstack sites, the best way to make toggle-able dark mode is pre-rendering HTML in ServiceWorker and use IndexedDB instead of LocalStorage to save users’ state.
Client-side toggle-able dark mode is either has Flash of Unstyled Content or blocking page rendering until LocalStorage and JavaScript are available–both are plain bad for user experience. Using ServiceWorker and IndexedDB will mimic the behavior of Server-Side rendering with cookies instead.
It’s very tricky and hacky since mostly replacing string on JavaScript mostly done synchronously, and ServiceWorker can only run async functions most of the times–one trick that I’m using is chaining string
.replace()
innew Response()
when returning a response for fetch event in service worker (after checkingContent-Type
in the header, of course).You can see how it works on my site that I’m currently developing. Option for Dark Mode toggle (and color theme) is on the top right corner.
https://prognovel-staging.netlify.com