The problem is that this doesn't let the user toggle dark mode on/off.
If you want the user to be able to toggle dark mode on your site without changing their Operating System preferences, then you'll need to implement your dark theme as a class (eg. body.theme-dark) since there's no way to dynamically set the media query.
const darkMode = window.matchMedia('(prefers-color-scheme: dark)')
if (darkMode) {
document.body.classList.add('theme-dark')
}
If you have to write your dark theme CSS as a separate class, then there's no sense in duplicating that logic inside the media query and having to override it when the user toggles it. So I ended up using that Javascript instead of putting the styles in the media query.
It's a shame, I would've preferred a pure HTML/CSS solution.
To me it seems like now that all browsers support the prefers-color-scheme media query, it’s no longer a best practice to allow/force users to toggle between light and dark theme separately from the OS. Centralization of config is a good thing, freeing people from rote work.
I strongly disagree. Users should be able to control their preferences by application, and not be locked into an OS setting.
My suggestion of still using classes doesn't eliminate centralization of config, it just means moving the dark mode CSS outside of the media query and into a class, and adding a couple lines of Javascript.
What I’m hearing is, “My precious snowflake app is so important, users must manage its appearance independently of the OS.” Once you allow the possibility of a different app setting, you effectively require them to continue managing it separately. You can’t respect both OS- and app-level settings, so you're going to ignore the OS.
If your app really just has light and dark theme choices, you should get rid of the toggle and move all your dark class styles into the prefers-color-scheme:dark media query instead.
Uh, no. What you're saying is "My user should not be allowed to customize the appearance of their application."
You want the user to have less freedom? Great, good luck with your app development, but I sure hope you're not in charge of developing anything I use.
Also if you read my original comment you would've seen that I am still reading the OS setting. The difference is that rather than locking the user into their OS's setting, I default to the OS's setting and give the user the freedom to change it as they see fit.
How is that going to work? User arrives at site, OS is set to dark, site is toggled to dark, so far, so good (assuming the toggle is smart enough to be set appropriately at this point).
1) User toggles OS to light, is your site going to switch back?
2) User toggles site to light, and back to dark to see what that does, now there's a persisted app setting. User later realizes they don’t like dark, toggles OS to light, and then has to think about your app's unique way of toggling it back.
To me, that's just unwieldy for very little gain. Why would I want your app to be inconsistent with everything else, other than a poorly executed dark mode?
While there’s a good chance you won't be using my current apps, I’m confident I won’t be the only one to reach a similar conclusion, so you'll likely have to get used to the behavior.
Your name here seems quite appropriate, as that was a weasel tactic, rephrasing the opponent's words to modify their intent. Not to mention you also used a quite inflammatory tone towards someone who's strongest words were "I strongly disagree".
I never saw any assertion that the user must manage apps individually, only that they should be able to. Easy way to do that - by default, the app echoes the system setting. If and only if the user manually changes the setting, does it diverge from that. Somewhat simple way around having a persistent setting get stuck - if the user switches back from the opposite mode, then you go back into "system" mode. So really, instead of needing two toggles, you would have one that has two states - "Respect system setting" and "Use the opposite mode from the system" (which probably need to be worded way better). The only snafu there that I can think of, off the top of my head, would be that if the user changes the system setting, the app state would likewise change.
It's also completely valid if someone doesn't wish to use system-wide dark mode (say, due to specific applications they use that may not function or render correctly in dark mode) but yet wishes to have specific apps in dark mode. I run Windows, which does have a dark mode nowadays, but that only works for certain apps that specifically use it (Windows Explorer does, not that I use that, along with many of the "modern" style apps that ship with Windows), and yet in apps like Discord I still prefer to use the dark mode, and I also have a dark mode extension for my browser.
For what it's worth, the site did correctly detect my dark mode setting in Windows, and display the dark style. As well, I don't necessarily disagree with any developer that does wish to exclusively use the system setting. However, I do see room for both approaches.
After some more thought, I’ve realized that should you want to allow but never force a user to manage appearance separately, you could give the toggle three options, ‘System setting’ (default), ‘Light’, ‘Dark’.
I don't particularly care for dark mode in web pages, however iOS apps which allow theming should allow the themes to be set independently of iOS.
For instance, the first version of Tweetbot for iOS 13 wouldn't allow you to choose a dark theme if iOS was set to use a light theme.
This was quite frustrating because I like Safari in light mode, but I like Tweetbot, iBooks, Kindle, etc in dark mode. This always has always worked and I'd see a different behaviour as a regression. That said Tweetbot fixed the issue very quickly (in a day).
Why do you like Safari in light mode, or dislike it in dark mode? Are you referring mostly to the app chrome or to the content of the sites you visit?
I would tend towards ease of configuration and consistency, and would only make exceptions for apps/sites with more theme choices than just light/dark.
I think if most of the pages were also dark like the surrounding chrome, because they implemented a dark theme with the prefers-color-scheme media query, that we would find the experience more agreeable. We’re in the early days, but once the dust settles and most sites have implemented dark mode, I’d expect the dark web browsing experience to improve.
Yes, although doing things without JS is old school web. I think you'd be hard pressed to find any clients that don't support JS in this era.
Anyway, to accomplish this you would split your styles into seperate CSS files and then have a drop-down that does an HTTP POST/GET to a server side script that will then set a cookie on your browser with your preferred choice.
Each time a request comes in from the client you just check that cookie for which style they want and then change the HTML that's sent to include a different stylesheet.
There's also alternative style sheets (https://developer.mozilla.org/en-US/docs/Web/CSS/Alternative...), that can support the media queries on the tags, but I think Firefox is the only browser still exposing the ability to switch the styles, and it sadly don't persist between sessions or even a page navigation/refresh.
We have a design system that supports both black text on white and white text on black (as a contrasting block of content).
If we want to support dark mode now we have to support four different options. Writing that with a combination of classes and media queries is going to be a nightmare:
.default-theme h2 { background: white; color: black }
.inverted-theme h2 { background: black; color: white }
@media (prefers-color-scheme: dark) {
.default-theme h2 { background: black; color: white }
.inverted-theme h2 { background: white; color: black }
}
Your trick might make this a little more palatable.
If you want the user to be able to toggle dark mode on your site without changing their Operating System preferences, then you'll need to implement your dark theme as a class (eg. body.theme-dark) since there's no way to dynamically set the media query.
If you have to write your dark theme CSS as a separate class, then there's no sense in duplicating that logic inside the media query and having to override it when the user toggles it. So I ended up using that Javascript instead of putting the styles in the media query.It's a shame, I would've preferred a pure HTML/CSS solution.