DEV Community

Cover image for Why Your Dark Mode Looks Weird (And How to Fix It)
Yue Geng
Yue Geng

Posted on • Originally published at gengyue.site

Why Your Dark Mode Looks Weird (And How to Fix It)

#webdev #javascript #css #frontend

TL;DR: If you're using both prefers-color-scheme and a manual .dark class to toggle themes, don't forget to also control the color-scheme CSS property. Otherwise, native browser UI (scrollbars, selects, etc.) will stay light while your page is dark. And that looks broken.

Read Original Vesion in Chinese

You probably know that prefers-color-scheme lets you detect a user's OS-level light/dark preference.

@media (prefers-color-scheme: dark) {
  :root {
    /* dark variables */
  }
}
Enter fullscreen mode Exit fullscreen mode

It's clean, it's native, and it even styles native form controls automatically — thanks to color-scheme.

:root {
  color-scheme: light dark;
}
Enter fullscreen mode Exit fullscreen mode

This tells the browser: "respect the user's preference, please."

But what if you need a manual toggle?

Many sites add a theme switcher button that overrides the OS setting. The common pattern? Add/remove a .dark class to the <html> element.

function toggleTheme() {
  const root = document.documentElement;
  root.classList.toggle("dark");
  localStorage.setItem("theme", root.classList.contains("dark") ? "dark" : "light");
}
Enter fullscreen mode Exit fullscreen mode

Then you write CSS like:

:root.dark {
  /* dark styles */
}
Enter fullscreen mode Exit fullscreen mode

Looks fine — until you notice that native UI elements (scrollbars, <select> dropdowns, date pickers) are still in light mode. Oops.

That’s the trap: color-scheme: light dark at the root still says "follow the OS", ignoring your manual .dark class.

The fix is simple

Don't let color-scheme listen to the OS if you're manually toggling themes. Let the .dark class control it:

:root {
  color-scheme: light;
}
:root.dark {
  color-scheme: dark;
}
Enter fullscreen mode Exit fullscreen mode

That's it. Now your native browser UI follows your manual toggle.

Real-world example: Memos

Memos is a beautiful open-source note app. But until recently, dark mode had a white scrollbar — jarring, right?

White scrollbar in dark mode

I opened Issue #5839, and the maintainers quickly fixed it by syncing color-scheme with the current theme:

const isDarkTheme = (theme) => theme.endsWith("-dark") || theme.endsWith(".dark");
document.documentElement.style.colorScheme = isDarkTheme(theme) ? "dark" : "light";
Enter fullscreen mode Exit fullscreen mode

If you're stuck on an older Memos version, drop this script into Settings → System → Additional script:

(function() {
  const isDarkTheme = (theme) => theme === "default-dark" || theme === "midnight";
  const updateColorScheme = (theme) => {
    document.documentElement.style.colorScheme = isDarkTheme(theme) ? "dark" : "light";
  };
  const observer = new MutationObserver(() => updateColorScheme(document.documentElement.getAttribute("data-theme")));
  observer.observe(document.documentElement, { attributes: true });
  updateColorScheme(document.documentElement.getAttribute("data-theme"));
})();
Enter fullscreen mode Exit fullscreen mode

So, do users really need a manual toggle?

Honestly? Most of the time, prefers-color-scheme + color-scheme: light dark is the best solution — zero JS, works everywhere, respects the user.

A manual toggle adds complexity. Ask yourself: is your user actually going to switch themes back and forth? Or are you just over-engineering?

Sometimes, less really is more.

What’s your take? Do you provide a theme switcher, or just follow the OS? Let me know in the comments 👇

Top comments (0)