DEV Community 👩‍💻👨‍💻

Cover image for Detecting dark mode on every request 🌓
Bryce Dorn
Bryce Dorn

Posted on

Detecting dark mode on every request 🌓

I'm a huge proponent of dark color schemes! Aside from causing less eye strain due to emitting less blue light, dark pixels drain less battery life (for devices with OLED screens) and make nighttime usage much more pleasant. I immediately look for the option when opening a new app and love when it's implemented well.

Recently I came across an experimental approach to help simplify dark mode adoption on the web and wanted to share with others as it resolves a related frontend issue.

That annoying flicker 💡

If you've ever implemented dark-mode in a frontend application, chances are you've encountered the "flickering" issue when loading the page. This is because the client doesn't know whether to render the light or dark version of the UI initially, causing it to flicker from light to dark if the user prefers that color scheme.

With SSR it's possible to get around this by storing the user's theme preference in document.cookie; enabling the server to check this preference on a request before responding with HTML. But even with this approach, the cookie can only be set after the user first loads a page (detecting via prefers-color-scheme and setting this cookie), still causing the page to flicker if they prefer things to be dark.

This can also become tedious if your application spans multiple subdomains, as the cookie may need to be set for each one.

Detecting on every request 🪄

Luckily there's a solution here! (For Chrome at least, more on that later.)

As of Chromium 93, the Sec-CH-Prefers-Color-Scheme client hint header enables attaching this preference to HTTP requests. By specifying that your server allows this header:

response.headers["Accept-CH"] = "Sec-CH-Prefers-Color-Scheme";
response.headers["Vary"] = "Sec-CH-Prefers-Color-Scheme";
response.headers["Critical-CH"] = "Sec-CH-Prefers-Color-Scheme";
Enter fullscreen mode Exit fullscreen mode

You can then get the user's preference from the request:

const theme = request.headers["Sec-CH-Prefers-Color-Scheme"];
// "dark" | "light"
Enter fullscreen mode Exit fullscreen mode

And send the appropriate markup to the client! Possibly via a class on the body tag:

return (
  <body class={theme}>
    ...
  </body>
);
Enter fullscreen mode Exit fullscreen mode

Or an inlined CSS variable:

return (
  <body style={{ `--color-scheme: ${theme}` }}>
    ...
  </body>
);
Enter fullscreen mode Exit fullscreen mode

Or it can integrate with the style library you're using assuming it generates styles server-side.

This is great though! No need to track color-scheme preference on the client or in your database; it can be set once on the user's device and included without any interference.

Some limitations 💭

Unfortunately this is currently only supported on recent (93+) versions of Chromium-based browsers. As we know Chrome dominates browser share, so this translates to roughly 70% of the web.

WebKit and Mozilla have requests pending to implement. Until support reaches 100% it can't (and shouldn't) be used in production, but I'm hopeful that since this delivers real value to the user experience it will get traction soon.

More information about other client hints can be found here, as well as links to examples. If this interests you spread the word and hopefully we can see this implemented across all browsers soon!

Top comments (14)

Collapse
 
darkwiiplayer profile image
𒊩Wii 💖💛💚💙💜💝💟

Wouldn't it be easiest (and most widely supported) to just insert a bit of blocking javascript at the start of the page that optionally adds a class to the <body> element?

Collapse
 
bryce profile image
Bryce Dorn Author

That would still cause a flicker as described above. The header would enable the server to generate the appropriate static content so there's no client-side blocking.

Collapse
 
darkwiiplayer profile image
𒊩Wii 💖💛💚💙💜💝💟

That would still cause a flicker as described above

How so?

Thread Thread
 
bryce profile image
Bryce Dorn Author

For the blocking javascript to run (via <script> tag) the browser needs to load the HTML for the page. This HTML won't have a theme initially applied to it, so the page could switch from light to dark after this script runs.

Thread Thread
 
darkwiiplayer profile image
𒊩Wii 💖💛💚💙💜💝💟

This HTML won't have a theme initially applied to it

Yea but that's the point of the javascript block; apply the theme as the page is loading, how would that still cause any flickering?

Thread Thread
 
bryce profile image
Bryce Dorn Author

as the page is loading

The JS doesn't run until the page is loaded. Here's an example.

Thread Thread
 
darkwiiplayer profile image
𒊩Wii 💖💛💚💙💜💝💟

The JS doesn't run until the page is loaded

...are you sure you don't want to double-check that before making that statement in public? I really recommend doing that.

Thread Thread
 
bryce profile image
Bryce Dorn Author

No need to be snarky. Feel free to share a codesandbox demonstrating a blocking client-side script that doesn't flicker.

Thread Thread
 
darkwiiplayer profile image
𒊩Wii 💖💛💚💙💜💝💟

I am not familiar with how codesandbox does its loading, so I'm not going to go tinkering with that. For a simple index.html that you can just throw on a localhost and try it out:

<style>body.dark{background:black}</style>
<body>
   <script>
      document.body.classList.add("dark")
   </script>
</body>
Enter fullscreen mode Exit fullscreen mode
Thread Thread
 
bryce profile image
Bryce Dorn Author

Yes, that contrived example will load quickly enough to not have a noticeable flicker. But inlining logic directly inside a script tag isn't a good practice, nor is it always possible. If you pull that out into a file and load it via src you will notice a flicker, which is what the codesandbox example I shared demonstrates.

Thread Thread
 
darkwiiplayer profile image
𒊩Wii 💖💛💚💙💜💝💟

So your point is that an inline script won't work because it won't work anymore if you don't inline it? Do I need to explain how that doesn't make any sense?

As for inlining a script being "bad practice", I couldn't care less. People have been using tools to inline critical CSS for ages (or even doing it manually) so the same could be done for JS. Inline critical JS snippets that need to be there instantly, then put everything less important in its own file.

And again, I don't know how exactly codesandbox loads its content, so I can't really comment on any results you're getting with it. But if the results don't align with using a small localhost HTTP server, I'll trust the actual server setup before the sandbox.

Thread Thread
 
mangor1no profile image
Mangor1no

Developers nowadays are running wild while talking about "best pratice" and "anti-pattern" makes me reconsider my basic HTML skill everyday. To summarize, there is no such thing that exists. Everything comes with their own advantages/disadvantages, why do we bother to make things become more complicated, just add a simple tag at the begin of the body and it will be loaded before the whole thing. How slow it could be to load this tiny script? Maybe 0.0001 second or even less?

document.documentElement.classList.add('dark');

Thread Thread
 
darkwiiplayer profile image
𒊩Wii 💖💛💚💙💜💝💟

Yep. If you want to be really fancy, you can even use that script to set up some simple loading spinner so the page loads more nicely. All in all you'd end up with maybe 10 lines or so.

Collapse
 
bluefalconhd profile image
Hayes Dombroski

Safari uses webkit. Safari will get this header really close to the time it is released in webkit.

Hacktoberfest is happening now!



It is a month-long celebration of open source. For a lot of devs, its their introduction to open source.


Check out the Hacktoberfest tag on DEV to keep up with the latest!