This is a great blog post to build awareness of the prefers-color-scheme feature.
But I don't think it's safe to assume that someone who sets a dark UI also wants web pages displayed like that.
I set dark mode in macOS to have the UI fade into the background and reveal the content; I don't want or expect that websites will present white text on a dark background too. That's fine for coding but can be less readable for long form articles depending on the ambient lighting.
As a counterpoint, I find a white app or webpage jarring in dark mode and much prefer light/white text on dark background. I’m happy that the rest of the os is catching up with how I’ve run my IDE for years.
it is but it's not feasible for the system theme to change the styles of websites.
Just ask any Linux user that uses dark themes and you will find out what happens when the system theme messes with the site theme.
I myself always set a light theme in my Firefox config so I don't get a black on black text/background issue.
With how customized the styling on sites is every site needs to implement their own dark version otherwise you will run into situations where the styling is broken.
>it is but it's not feasible for the system theme to change the styles of websites.
Just ask any Linux user that uses dark themes and you will find out what happens when the system theme messes with the site theme.
It is done completely different fashion than it was done on gnu/linux, on linux it was probably done by changing user agent style sheet (changes default bg color on body etc), when here it is done with media query (which webdev must explicit implement on his part so he can make sure that everything works).
That I agree with, and this "responsibility" ultimately falls on the webmaster/content provider to allow a dark theme in a method similar to this post...
I found that black background with white text is great when you have perfect eyesight but once your eyesight starts to go and you start needing glasses white background with black text is easier to read.
it's quite odd. It could be just a personal thing though.
I'd assume this is intended for web pages/apps to allow their in-page controls/navigation to fade into the background, revealing the content.
E.g. in a crud app with top/side nav, and then a form in the main section, the nav bars can be rendered as pale/dark to suit the user selection, while the main content area retains the focus.
Just personally don't want to read 2,000+ word articles of white text on a dark background just because I like the browser UI to be dark. Others might, though — hopefully browsers will offer a setting for dark mode independent of the OS-level setting.
I think it'll be a while before most sites even consider adopting this (it's not even listed to check support on caniuse.com), and even if it does become widespread, reader mode has style-override controls to make the page more suitable for long-form reading just as it does now.
Don't you use websites that have a dark theme more instead. I always preferred websites that allowed me to select a dark theme and it seems to be more and more popular to do that.
It's really a matter of preference. I personally would be happy if my PDFs would automatically display in "dark mode" (not that I expect that to be implemented). Perhaps browsers just need a setting to toggle this.
On Linux I use MuPDF which can also invert. (Although this isn't really "dark mode", since most PDF documents are black text on white, it gets the job done.)
It is nice to have the option of map pdf colors to correspond to one's color theme.
I like to read pdfs in emacs alongside my notes, and I am very pleased that emacs' pdf-tools allows me to map colors as I choose (kind of - there are only two colors, foreground and background).
Why not? I have a chrome extension to darken and/or invert webpages and PDFs, and I have SumatraPDF setup white text on black background for editing LaTeX?
This is why I think they should focus on exposing the dark mode setting in Javascript instead of CSS.
Sites that support dark mode should (and will almost always) have a toggle for it. It'd be better if this setting helped _inform_ the default initial state rather than _forcing_ a choice on you. To me, that's a lot easier done with a Javascript API than CSS.
You have all the choice in the world. Use whatever tech you want (browser js, server side templating, client side xslt, etc) to have an attribute on the body element indicating opt-in status, and use that in your media query to target only the users who want it.
With the css solution it’s doable on a site that has no javascript.
The right place for the switch in this case is the browser. The browser should have a button for light/dark/system, defaulting to system. And CSS should follow that.
JS should not be involved, and we don't need every site to have its own version of the switch, located in a different place and looking different.
You don't need Javascript to implement a switch that changes from light mode to dark mode. That can be easily done in CSS. I've done it on web sites to switch to a high-contrast color scheme for people with vision difficulties.
> But I don't think it's safe to assume that someone who sets a dark UI also wants web pages displayed like that.
If it's done well, absolutely it's safe to assume.
I am extremely excited to research and start using this feature. I don't want to force anyone to use dark UIs that don't want them, but simultaneously I can't bring myself to make more light-themed apps and pages when I want exclusively dark themes for everything that runs on my machine.
"But I don't think it's safe to assume that someone who sets a dark UI also wants web pages displayed like that."
I don't think it's safe to assume they don't. I can't stand web pages in general that are white background/black text.
I've coded in black background / white (or coloured) text for about two decades now, and I'm so glad Apple is making the dark theme a standard at this point. There's literally thousands of articles about the eye strain that's caused from the poor decision to present information this way. We don't need literally at this point millions of photons screaming light at our faces at more than 300 nits every moment.
Also while it's very cool that they support this in Safari, I highly doubt someone will do CSS adjustments JUST for Safari users like this. Either your page already has a dark theme or you won't really bother about this.
Also on Linux GNOME has had a popular dark mode for its default theme (Adwaita) for ages now, and KDE has a bundled dark theme bundled by default (IIRC, haven’t used KDE in ages).
I think Android has this option too?
Basically, it’s not just a “macOS thing”, lots of systems now have dark modes.
If you can justify dozens of CSS adjustments for IE11, it isn't much of a stretch to spend half that amount of time making something cool for (typically) higher value Safari users as well.
What do you mean by "higher value"? Getting IE11 to work will net you an extra 2.85% of the market, but adding a very minor feature that's only usable by Safari users doesn't seem to be profitable at all.
I'm not sure I can take it anymore. Websites are just getting too complicated to design and build.
First it was desktop with mouse -- easy. Then responsive design requiring both desktop and mobile layouts, as well as interaction design with both mouse and touch. Now what if users start expecting both light and dark versions of websites? "We show the mobile version of the menu with its own hover on small screens only, but the hover only appears if JavaScript detects a mouse, but wait we need a different hover color when it's in dark mode!"
Not to mention other standard things like making sure it works in all major browsers, or even that interactive things like comments or voting have non-JavaScript fallbacks, or that the order of elements is appropriate for screenreaders.
I love using dark mode at night, and as a user would love for every website to follow it too. But as a developer, there are just too many combinations to design and test for, and it's growing exponentially!
I think the largest issue with this is it is currently a Safari-only, and an early Safari-only release at that. And that the latest MacOS right now is the only major commercial OS offering a dark theme to the extent that it does.
A quick look at Safari's desktop browser market share reveals it to be about 4% right now. When this kind of standard makes its way into Chrome and/or FF, it'll be relevant.
Until then, it's a toy, and nothing more. Nobody could ever realistically expect this kind of thing. It doesn't increase the complexity of web design by that much. If you think adding CSS exceptions for inverted colours is the straw that broke the camel's back on web complexity for you, perhaps you just feel like we should've stuck with the late 90's or worse, early 00's web standards?
Many websites, even YouTube, already have a 'night' or 'dark' switch. It makes a lot of sense, and genuinely is not that hard to implement.
Websites aren't really getting complicated to design if you treat them the way they were originally designed: As a network of documents.
It's once you try to app-ify them that things break down. Though really, with this new dark mode I just wish I could set a max whitepoint. I code in the dark but too much of the web is bright and I constantly have to change my brightness going between the two. I don't want a third party pluggin. I just want Apple to do it. The have it on the iPhone and it works great there.
Multiple alternative CSS files were a thing in early 2000s. But browsers never developed support for them. Now some sites offer switchable "themes", tough.
As usual Apple has set off a major change in the way we do business. Newspapers, Apps, Slack, everything is going to start supporting dark mode. I think the original way we tackled "custom color schemes" of the OS was too much - we allowed people to set individual colors for everything. Once again apple has simplified that to just light mode and dark mode. And that's how the rest of the industry will finally tackle custom color schemes (no choice but light or dark) and the OS will now dictate that setting automatically much like en-US, es-MX etc..
Not really. Slack would have to have a real, native app that used exclusively stock OS controls. I very much doubt they'd do that, so there would still be a lot of work required to implement dark mode.
It's honestly not much dev work at all (took me a couple days on a medium size app). The real time sink is with design, because virtually any custom color you're using in the application will need a dark variant.
Yea and this is purely driven by Apple needs. For e.g on Apple the UI is desturated so dark mode just means go darker. But for e.g on Linux with Arc theme, dark theme has a blueish tint, so the website using dark theme will look bad on Arc theme desktop.
We should at least add the option hue & saturation to light/dark setting. Then the app/website would at least fit color-wise with the theme of the OS. But only dark/light is assuming all themes are desaturated which is true for Apple but not necessarily for other platforms
Actually Mac OS was always pretty restrictive in what you could customize - in some ways they've actually doubled the number of choices you now have :)
This is a very interesting step, considering that Apple's interface guidelines prefer that application "content" remain regularly styled (e.g. as Pages does). This seems to show that Safari's web view has been changed from being merely content to being part of the user interface, as it would in say web applications. Presumably document creation websites e.g. Google Docs would be encouraged to maintain a light-themed document while darkening the interface.
Another interesting point is this might lead to yet more fingerprinting surface area. But overall, I think I'll take that over blinding myself at night.
However, Mail does have a dark stylesheet for the viewer when Dark Mode is enabled. I guess this can be done when there's a concept of a base stylesheet which people can the overwrite if needed.
Word processors don't have this concept, and what you see is (supposed to be) always exactly what you get. So Pages doesn't display dark documents because the output then should be a dark document.
Apple is proposing a new CSS color-filter property [1], which would do the same thing as Mail does for its content. Actually, Apple is already using color-filter internally in the Mail app.
Safari allows setting user style sheets in its Preferences: Advanced > Style sheet, so one could perhaps add a user style sheet with color-filter.
There are several safari extensions available already which bring dark-mode to websites. Based on the results I beleive at least some of the one I’m using must be using a filter (rather than using say manually mapped colours in a hash).
I was reading in iBooks the other day and it changed the content to be in dark mode as well. I didn't find it jarring, but it is simply text so I was okay with it.
If I was on a website/app though, I think I'd prefer an option provided by the site/app rather than having the OS dictate what happens.
I’ll have to check Apple Books for this when it makes it into release WebKit. Currently we’re using :root[__ibooks_internal_theme*="Night"] to target the dark mode there (inverting black and white SVGs, etc.), but if we can use a more standardised media query that’d be a benefit.
I think this is great. No-one is forcing you to implement this and if you do change a few colours here and there to benefit those users who use dark mode - it'd be hugely appreciated.
And for those worried about adding weight to your page just explicitly use the media query and put the over-rides in a separate file:
I recently heard about the Dark Reader extension for Chrome, which lets you toggle dark settings per website in a fairly intelligent way. https://chrome.google.com/webstore/detail/dark-reader/eimadp... I'm really liking it, and I'd be interested to hear about something similar for Firefox.
I'm not familiar with Dark Reader, but I'm guessing it's along the same lines. I've used it with Firefox Mobile for a couple months and have been happy with it.
This will turn everything into dark mode, except images and video. And you don't have to care if site has that line in CSS. Also, when you switch back - everything is in "light mode" again, including OS UI.
FYI: Been using these extensions (or similar) for years to combat the white background fascists that took over the web and removed control of the GUI theme (in all 3 OSs!) in the last decade:
I, for one, am tired of web pages being able to know things about the environment in which I view them outside of their sandbox. Orientation, battery, point:pixel ratio, user-agent, referer- now UI display preferences.
I should be able to turn all of these off and make my browser indistinguishable from any other save for IP address if I so choose. This stuff just keeps rolling down the fingerprinting hill. Pretty soon they won’t need cookies at all.
Canvas fingerprinting along with most of these issues were solved with Safari 12 on both Mac OS and iOS. If you don't want to be fingerprinted, consider switching to it.
Obviously there are some things that aren't yet anonymized in Safari 12, but it's good enough.
Safari’s code exec history (compared to Chrome) is enough to keep me from switching back, even if it is better at privacy in the not-execing-malicious-code typical use case.
The prefers-contrast media query is even better for accessibility [1]. It allows checking if the OS is in high contrast mode and adjust the colors appropriately.
I think the idea is to replace the Microsoft's proprietary -ms-high-contrast media query [2]. It means that prefers-contrast will work in Mac and Windows. Unfortunately, Safari Technology Preview 68 doesn't seem to implement it.
That doesn’t always work though. Some people need to adjust their colours for lower contrast, for example: https://accessibility.blog.gov.uk/2016/05/26/accessibility-a... . Ideally sites would also work properly if the user changes the foreground and background colours to suit their needs.
This is great news. And as the author mentioned suitable for “web apps” rather than something devs should add to general websites but certainly special use cases where it could make sense there too.
I love me a good dark mode but what I can’t stand is when designers get lazy and think dark mode = jet black with white text. Latest tweetbot is a great example.
Yeah, I don't even care about dark mode, but that is very nicely done. I really like that they care enough to actually implement dark mode all the way from OS to the browser.
For those that are unaware: Firefox still supports alternative style sheets [0]. Unfortunately it's pretty well hidden, and I think it's unsupported by other browsers. One of the things I love about this feature is that it gives users the choice.
It's a damn shame that CSS System Colors [1] was deprecated. There's also System font values [2], even if it's barely used. I really like my system styles and I wish more web services could use similar element sizes and colors. A few years back using the system font for UI elements started to gain a bit of popularity [3] [4]. WebKit even added improved support for using system fonts in web content [5], although I don't know what state that's in. I understand that exposing more system information can be used for fingerprinting, but why can't I be the one to decide what information I expose? You could expose standard color values by default and allow me to whitelist trusted websites to access real system styles.
I've thought about this a bit, and I wish websites could have different "modes" which you could switch to. I think it would make it much easier to develop and design websites that target devices with drastically different requirements. You usually want a desktop mode which is designed for use with a keyboard and mouse, and a mobile mode which is designed for use with a touch interface. The closest thing we have is the "desktop mode" switch on mobile browsers, but I think that depends on user-agent sniffing which is incredibly hacky.
I'm typically not a fan of mobile first designs, since it usually leads to a worse experience for desktop users. Using media queries with viewport size break points is usually not what you want. For example, sometimes I want to reference some API docs so I'll resize the window to be incredibly narrow and place it next to my editor. Tons of websites take this narrow screen size to mean that I'm on mobile and drastically blow up the size of the text and UI elements, causing me to lose my position in the document. This is incredibly frustrating.
Things are improving, though. Now you can use CSS media feature tests to check if the user has a pointing device [6] and if they can hover over elements [7]. Although I still think designing a website that handles all variations well is nigh impossible. Even worse, these values cannot be changed by the user! For example, imagine an advanced image editing app meant for use with a mouse. If I'm on mobile the browser could let me interface with it by providing a virtual trackpad. It might not be a great experience, but if the operation I'm doing is really simple it might be enough.
I think I'd prefer it if you could use a link tag to expose different versions of the same document, and allow the user to chose which version they prefer. Aside from providing a desktop and mobile version you could also link to an API or data view which is designed for easier consumption by computers. Another neat use for this could be to provide EPUB or PDF links for online books; you can keep reading the online version or download the full version for later.
Firefox has the option to set default colours based on your theme, so mine are set to dark colours. However, I find that many sites become unusable because they assumed the user defaults would be black text on white background. I use Stylus to override things which sometimes works but not always. Is there actually a way to fix this?
No. This is a different thing. The problem is when people haven't coded their CSS correctly and assume default background is white and then set a non default foreground of black or something. Those sites will still break for dark themes even with this API.
In fact, if people actually understood the first C in CSS, this thing wouldn't even be necessary.
In the color preferences, set "Override the colors specified by the page with your selections above" to "Always". By default Firefox does this automatically when the OS is in high contrast mode.
But I don't think it's safe to assume that someone who sets a dark UI also wants web pages displayed like that.
I set dark mode in macOS to have the UI fade into the background and reveal the content; I don't want or expect that websites will present white text on a dark background too. That's fine for coding but can be less readable for long form articles depending on the ambient lighting.
https://ux.stackexchange.com/q/53264/