Actors are overwhelmingly diurnal, overtime is expensive, and film emulsion struggles with limited light, so since the dawn of time Hollywood has been using a technique called “day for night” – shooting during daylight, and then darkening and blue-tinting in post to pretend it was night time all along:

It’s a method filled with nuance, as this 11-minute video describes really well. This TV Tropes page lists a lot of examples from movies you might recognize, and another video by Rob Ellis has a lot of practical advice.

Now that you know it, you might spot it in movies that use it poorly: the ones that darken everything too much, the ones where too bright of a sky gives it away, or the ones where the shadows appear lunatic in the wrong sense of the word.

In UX design, you can day-for-night your dark mode as well – long before proper dark mode was a gleam in someone’s bloodshot eye, operating systems allowed you to invert their screens – but the limitations of that approach are apparent very quickly:

Sure, black becomes white, white becomes black, and grays swap places. But in real life, shadows do not get brighter at night, and photos do not behave that way, either.

The “proper” answer is not to do anything automatically and to go all out with a perfectly hand-crafted dark mode that’s an equal partner to light mode: a distinct set of semantic colors, a new strategy for shadows and layering, and a second set of visual assets like icons and images.

Here’s a comparison of naïve inverting and a proper dark mode:

A lot of apps do that for colors and shadows, some even providing multiple dark mode flavors…

…but visual assets is where things get tricky. Yeah, vector graphics can use the same swappable color variables as CSS text and elements, although in practice it is quite a bit of work and from my experience SVG doesn’t make it very easy, either (here’s an example from my essay):

But when it comes to bitmaps, they are usually left alone. Overtime is still overtime, and producing each bitmap twice is a lot of effort.

Since swappable variables don’t exist in this context, the only automatic approach method left is inverting, but a) inverting an already- dark image can make things lighter,and b) inverting things like photos makes them look creepy and mixes up all the colors:

What explains the last part? This has to do with the fact that inversion happens in the RGB color space. R becomes 1–R, and the same for G and B.

Everyone who’s into gradients knows of a similar challenge that results in the gray dead zone effect. This is fixable if you convince a gradient to traverse through a different space instead, or coax it through the RGB space on a more… bespoke path (this is e.g. what Figma gradient plugins do).

Could we invert in HSL or OKLAB color space, then? Yes, we could. They both look similar – this is HSL:

You can see how the photos get inverted now, but the colors remain the same! Still a curiosity, perhaps, but the bottom of the above screen shows this technique feels really interesting for diagrams, screenshots, and things of similar nature. Here’s another bitmap that looks pretty great inverted this way:

Unfortunately, while there are techniques and plugins to do gradients in non-RGB color spaces, I am not seeing a lot of options for inversion customization anywhere. Neither the graphics apps I use, nor CSS offer anything here.

But there’s a trick: do a regular invert and then rotate the hue halfway through. Through the magic of math, this is the same as inverting just L in the HSL space, which means the colors are preserved. This is actually achievable in graphic programs…

…and, more importantly, available in CSS as a filter: instead of invert(1), use hue-rotate(180deg) invert(1).

So, if you have dark-on-light diagrams, bitmapped text, illustrations, or other similar things – or even vector graphics you cannot throw dark mode variables at – this day-for-night trick that can get you places very cheaply. (And for other bright bitmaps, just reduce the brightness by 25%.)

It’s the same as with Hollywood trickery: remember to add a bit more nuance in the right place, and you get something that feels bespoke for the price of only light – please excuse the pun – manufacture.

Before dark mode became mainstream in the late 2010s, there were two main customers of dark UI themes: programming and photo/​video production. But, to the best of my knowledge, they arrived at that preference from two very different angles.

Programmers’ fondness for dark mode was a result of decades of bad display technologies. The early CRTs were so awful, the burn-in risks so real, and the pixels so fuzzy and headache-inducing, that you wanted to see as little screen light up as possible – hence, defaulting to black background for everything computers did.

These challenges were there all the way through the 1980s, really, teaching generations of coders that computers meant light letters on dark backgrounds. Games moved away from being “in space” or “at night” as quickly as they could, text editing and spreadsheets went for paper-like livery soon after that, but programming never meaningfully existed on paper, and so the skeuomorphic pull wasn’t really there.

(Have you ever heard of a term “reverse video”? What’s kind of confusing about it is that its meaning was reversed around that time.)

AV professionals took a different route. They already had CRT calibration, gray walls, and monitor hoods so that light from outside wouldn’t contaminate content colors – and when computer UI started appearing on those CRTs, it was likewise best to keep it as dark and as neutral as possible.

Below are pictures of Avid Composer in 1990, Pixar’s Marionette/​RenderMan in 1995, and the first versions of Lightroom in 2006 where you can see the interface trying to at least gesture toward a dark theme:

Today, things are more flexible. Many people prefer one theme over the other for any of many legitimate reasons, most leave dark theming synced to daylight, and display technology can handle all themes so well that it jumped ahead of our brains, which still have some interesting asymmetries in processing light shapes next to dark ones.

As users celebrated dark mode appearing in popular apps and services in the 2010s, some had to catch up the other way: Apple TV added light mode (for some reason) in 2017, and Affinity apps celebrated new light UI option just earlier this year.

Most programming text editors still default to dark, but allow you to switch; as a software category they were probably the first to fully embrace color theming.

But what led me to writing this post was a delightful discovery today of this setting:

Why, of all apps, would iOS Photos allow you to switch to dark mode, and only while editing to boot?

I think this might be because of the above tradition of pro AV apps, where we learned it’s good for visuals to be surrounded by black; a little nod to its earlier professional roots – similar, perhaps, to the story of the Clear button in calculators.

But I had two more thoughts. First, for all the reasons above, to me at least dark mode still has connotations of “professionalism” and toggling the option makes me feel I’m a bad-ass pro whenever I’m editing a photo. I wonder if others also feel that way, too.

Second, dark mode looks different. Dark UI only when editing means it’s easier to spot whether I’m editing or just browsing, and be ever so slightly better oriented.

(In general, apps today are much more similar-looking, and I’m surprised neither iOS nor Android doesn’t allow you to switch the theme per app, just so it’s easier to know where you are as you move around quickly.)

This iPhone UI for dark/​light theme is doing something clever:

Ostensibly, there are two modes here:

• automatic, for when you want the theme to match the time of day
• manual, for when you want to keep one of the themes forever

But check out what happens when I am in automatic mode, but toggle the theme by hand anyway:

More rigid or less thoughtful interfaces would either disable manual changes when you’re in automatic mode, or understand a manual theme switch to mean “I want to turn off automatic.”

But here, iOS is quietly putting me in a temporary hybrid mode: a manual theme override until the theme catches up with what automatic mode would do, at which point it snaps back (I’m resisting very hard calling this rubber banding) to automatic mode.

What I think is clever is that this isn’t presented as a third mode – which could be more confusing than helpful – but the design simply reuses the existing Options field to set the expectations.

One has to be careful designing in shades of gray; once you enter the space you really have to commit to it and see it through. My go-to analogy is symmetry vs. asymmetry. Symmetry in visual design is usually easier and safer. If you venture into asymmetry you have to make an effort to make it work. The highs of asymmetry will be higher than anything symmetry can provide, but getting to those highs can be arduous and sometimes might even be impossible.

I thought this particular example was really nicely done and the team found a great balance. (I think Apple’s previous shade of gray – “Disconnecting Nearby Wi-Fi Until Tomorrow” – ended up slightly less successful.)

As a Mac user I naturally focus on that platform, but Windows 11 has had its own share of problems – and that list has grown so vast it’s hard to know where to start.

So let’s pick it up at random, with a post by Thom Holwerda with a great title “You can actually stop Windows Explorer from flashbanging you in dark mode”:

One of the most annoying things I encountered while trying out Windows 11 a few months ago was the utterly broken dark mode; broken since its inception nine years ago, but finally getting some fixes. One of the smaller but downright disturbing issues with dark mode on Windows 11 is that when Explorer is in dark mode, it will flash bright white whenever you open a new window or a new tab. It’s like the operating system is throwing flashbangs at you every time you need to do some file management.

I find the videogame-inspired nickname darkly – I’m sorry! – funny, but the problem is real. It looks like this (video via windowscentral.com):

It’s not a problem unique to Windows 11 – just the other night I saw this on Wikipedia on my iPhone, exacerbated by the delayed reaction of Liquid Glass buttons spastically adapting to the changing background:

But there is something about this that feels a notch more important than other visual and layout issues.

I think this is because dark mode is a contract – we’ll lower the brightness, and we’ll let your eyes rest. There’s a physiological part to it: a sudden flash of light when your eyes are not expecting to it can be actually physically painful. I think it’s worth thinking about it and futureproofing and sanding dark-mode views especially at their edges: loading states, error messages, signing in and logging off areas. The “flashbang” analogy is very apt, and especially so on bigger screens.