Two Color Schemes, Four Modes: Native CSS Theme Switching.

Olga Urentseva — Tue, 24 Feb 2026 21:42:55 +0000

Frontend is finally moving toward vanillaization and that is the best thing that has happened to frontend since Wes Bos published his first courses. Native browser support for themes works absolutely fine and that can be enough for many projects, but I just wanted to have fun. I didn't want just one color scheme with light and dark variants. I wanted two, each supporting light and dark. Four variants in total. And the key is using native browser features. And it worked.

The Requirements:

Light and dark mode, handled by the browser natively
A second "spring" (or whatever) color scheme with a completely different palette
A toggle button to switch between default and spring
No flash of wrong theme on reload
No page reload needed to switch

The Specificity Hack:

:root:root:root

If you use styled-components, you've probably run into specificity wars where your global CSS variables get overridden by styled-components' injected styles. The fix is delightfully dumb, just repeat :root three times. Yes, I know, styled-components is outdated, so my future desire would be to get rid of it, but for now it is not the main topic of the conversation :)

:root:root:root {
  --color-background: light-dark(oklch(0.99 0.0105 320.98), oklch(13.709% 0.02553 268.319));
  --color-primary: light-dark(oklch(70.61% 0.085 271.69), oklch(0.79 0.1233 266.14));
  /* ...etc */
}

The browser picks the right value automatically based on the user's system preference. No JavaScript involved. You do still need color-scheme declared for this to work:

// index.html
<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <meta name="theme-color" content="#ffffff" />
    <meta name="color-scheme" content="light dark" />
    <title>Title</title>
  </head>
  <body>
    <div id="root"></div>
    <script type="module" src="/src/main.tsx"></script>
  </body>
</html>

Important thing. For browsers that don't support light-dark() yet, keep @media (prefers-color-scheme) fallback blocks below. The cascade handles it gracefully.

But you probably notice that I just mentioned 2 themes of 1 color-scheme. And the whole approach above is something that was highly used before. But let's add another one. And it's gonna be tricky (not really).

The Spring Theme: One CSS File, A Class on HTML Tag

For the second theme, I wanted to avoid dynamic CSS imports, because they're async, unreliable in production builds with Vite, and add complexity. I tried it, didn't work well. Instead, decided that both themes should be in one CSS file.
The spring theme overrides default variables using a .spring class on the element. The key insight is specificity: .spring:root:root:root beats :root:root:root because of the extra class:

:root:root:root {
  --color-background: light-dark(oklch(0.99 0.0105 320.98), oklch(0.21 0.037 271.06));
  --color-primary: light-dark(oklch(70.61% 0.085 271.69), oklch(0.79 0.1233 266.14));
}

/* this one wins when .spring is on <html> */
.spring:root:root:root {
  --color-background: light-dark(oklch(0.99 0.012 150), oklch(0.18 0.05 145));
  --color-primary: light-dark(oklch(56.316% 0.10067 150.907), oklch(0.72 0.2 145));
}

Light and dark still work automatically inside both themes and light-dark() keeps doing its job regardless of which theme is active.

The Toggle

classList.toggle() flips the class and returns the new boolean state. That's the entire toggle logic. No React state (or whatever you use), no context, no re-renders. The CSS reacts instantly because the class change is reflected immediately in the DOM.

// UI component
function handleToggle() {
  const isSpring = document.documentElement.classList.toggle("spring");
  localStorage.setItem("theme", isSpring ? "spring" : "default");
}

Applying the Right Theme on Load

This runs synchronously before the first paint. No flash, no layout shift, no useEffect timing issues.

// main.tsx
import "./themes.css";

const savedTheme = localStorage.getItem("theme");
document.documentElement.classList.toggle("spring", savedTheme === "spring");

ReactDOM.createRoot(document.getElementById("root")!).render(
  <React.StrictMode>
    <App />
  </React.StrictMode>
);

What I Tried That Didn't Work

Before landing on this decision, I experimented with @container style() queries — a newer CSS feature that lets you apply styles based on the value of a custom property on a parent:

@container style(--theme: spring) {
  body {
    --color-background: ...;
  }
}

And it worked! But in Chrome. Not even in Firefox Developer Edition. Don't even talk about Safari. So I dropped it. But it is worth keeping an eye on for the future. It would have been a much more elegant approach.

The Result

One CSS file with all four theme variants (light default, dark default, light spring, dark spring)
Zero JavaScript for color values, all colors live in CSS
No React context or state for theming
No page reload on toggle
No flash of wrong theme on load
Native browser dark mode support throughout

Netlify, Vite, deploy and “Page Not Found” error

Olga Urentseva — Mon, 07 Nov 2022 22:48:07 +0000

I know that a lot of people struggling with the problem when their web app works perfectly on localhost, but on Netlify server after refreshing page they got error “Page Not Found”. Why and how it should be fixed?

The key of this problem is not how Netlify works. Actually Netlify or something else is not matters, because it can be another server. The problem is the fact, that your server doesn’t know how to respond on your requests properly. Despite the fact that I’ll will refer to Netlify, you should keep in mind that it could be something else.

How Netlify [server] saves your files? — There is a dist directory with similar files:

dist
  index.html
  hash.js
  icon.svg
  favicon.ico

We have a Netlify server and we don’t have access to it, we cannot directly code that if a request comes to a specific address, server must give this specific file. We simply don’t have such an opportunity. But all that our Netlify server has is dist directory with bunch of files. So if there is a request to https://netlify.app/icon.svg, our Netlify server should respond with a file icon.svg from dist as well. But what if we want to get https://netlify.app/example/1? We do have this route in our SPA and everything works well on localhost, but we we’ll get “Not Found Page” error. Why? Just because there is no that file in our dist directory. Only thing that we have is index.html so we have to set up redirects, because we want to give responsibility of taking care of routes to SPA. So our server has to respond with index.html if there is no file in dist with matched name.

There is a bunch of ways to do it and of course as I want you to remember, there is nothing specific to Netlify till next approach. But if you’re using Vite I also recommend you read this Public Folder Documentation.

Well, if we’re considering Netlify, all I need is create netlify.toml in project directory:

// netlify.toml
[[redirects]]
  from = "/*"
  to = "/index.html"
  status = 200

And that’s it! Error is gone.

Honestly I don’t really like this idea when I can not control the server and creating files such as netlify.toml is the only way to hook “our” (not really our) server makes me awkward. But I guess this is another indicator that we need to move to something more low-level than Netlify, although it is really good for pet-projects.

And thanks for reading :)

DEV Community: Olga Urentseva