Dark mode changed how I thought about colour on the web.
Before system-level dark mode became a normal design conversation, colour decisions on most websites felt fairly fixed. A designer chose a palette, the website used that palette and the visitor experienced the same visual treatment regardless of their device settings. There were accessibility considerations and contrast decisions, but the theme itself was usually assumed to be static.
In 2019, with browser support for `prefers-color-scheme` becoming more visible, that assumption started to feel less complete. The website could now respond to a preference the visitor had already expressed at operating system level. That made colour feel less like a single decision and more like a relationship between brand, interface and context.
Colour Choices Became Conditional
The interesting part of dark mode was not simply making a black version of a website. That is the quickest way to make it feel like a theme switch rather than a considered design decision. A proper dark mode needs to think about contrast, hierarchy, imagery, shadows, borders and how the brand behaves when the background changes.
Some colours that work well on a light background become harsh on a dark one. Some subtle borders disappear. Some images feel too bright. Some shadows stop making sense because shadows rely on a lighting model that changes when the interface becomes dark. The design needs to be reviewed as a system, not inverted like a filter.
That made dark mode a useful reminder that interface decisions are contextual. A colour is not good in isolation. It is good because of where it appears, what sits around it and what the visitor is trying to do at that moment.
Not Every Website Needed It
I did not think every website needed a dark mode immediately. Some brands depend heavily on a particular visual tone. Some websites are simple enough that the extra design and testing effort is not justified. Some projects have more urgent accessibility, performance or content issues that should be solved first.
The decision needed to come from the use case. A dashboard used for long periods of time might benefit from adapting to a visitor’s system preference. A documentation site might be easier to read for some users with a dark option. A small campaign page with a short lifespan might not need the extra work.
That was the practical balance. Dark mode was interesting, but it should not become another feature added because it was fashionable. It had to make sense for how the site would actually be used.
CSS Custom Properties Made It Easier
CSS custom properties made this kind of thinking easier because colours could be described as roles rather than repeated values. Instead of scattering a background colour through the stylesheet, I could define a surface colour, a text colour and an accent colour, then adjust those values when the user preferred a dark scheme.
:root {
--colour-background: #ffffff;
--colour-text: #1f2933;
--colour-accent: #246bfe;
}
@media (prefers-color-scheme: dark) {
:root {
--colour-background: #121212;
--colour-text: #f3f4f6;
--colour-accent: #8ab4ff;
}
}
body {
background: var(--colour-background);
color: var(--colour-text);
}That structure makes the intention easier to maintain. I am not changing individual declarations one by one. I am changing the values behind the design roles. That is a much cleaner way to approach themes, especially as a project grows.
Testing The Small Details
The difficult part of dark mode is usually the details. Form fields need to remain readable. Focus states need enough contrast. Logos may need alternate versions. SVG icons need to inherit colour properly or use a sensible fallback. Images with transparent backgrounds need checking because they may have been created assuming a light surface behind them.
This is where I would slow down during implementation. It is very easy to create a dark mode that looks good on the homepage and fails inside a form, a table, an alert or an embedded component. The visitor does not experience dark mode as a homepage treatment. They experience it across the whole journey.
That means dark mode needs testing like any other interface feature. It has to work in the places where people actually complete tasks, not only in the polished areas that appear in a design screenshot.
Retrospective Thoughts
What interested me about dark mode in 2019 was that it made websites feel more responsive to the visitor’s environment. Responsive design had already taught us that layout should respond to screen size. Dark mode extended that thinking into preference and context.
The best implementations were not dramatic. They respected the visitor’s setting, preserved readability and kept the brand recognisable without forcing the interface to behave as if one colour scheme suited every situation. That made dark mode less about style and more about designing with a little more awareness of where the website was being used.