Safari introduces Adaptive Dark Mode in 27.3
webkit.org
webkit.org
https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/V...
Safari and Firefox are pretty small.
The underlying problem is Chrome exposes no (normal) setting to override the OS level setting at all, not necessarily that the preference shall always follow the browser's theme specifically.
So if the user sets dark mode in the browser, do they not explicitly express their preference for websites? How could they be more explicit about the setting?
[1]https://drafts.csswg.org/mediaqueries-5/#prefers-color-schem...
Chrome already has a setting to change a specific website's color-scheme, although it's only working when Developer Tools is visible (then with Cmd+Shift+P "Toggle CSS media feature prefers-color-scheme"), so CSS implementation actually follows respecting UA-level preference over OS-level setting.
But again, Chrome doesn't have a feature that lets users to choose which color-scheme they want to browse the web (so there is no bug, but it's a UX issue because their Appearance settings doesn't make it clear to the users what this setting changes) other than the setting they gave to developers. Honestly I would love to see all browsers have an option for how color-scheme settings should apply to websites.
However, your original comment was saying that prefers-color-scheme is bugged in Chrome is not true. It works as intended: it follows both UA-level and OS-level settings correctly.
The settings in Appearance tab is not a setting for preference when browsing the web. Many apps have a setting to choose if their app should change appearance when OS setting changed (or to override it), they could simply leave out this setting and let Chrome chrome (app ui) always follow the OS setting or always be in default light mode, instead they gave users to choose "how their Chrome browser will look like", not "how every website they visit should look like".
I was a theme junkie back in Windows 98 times, but stopped bothering since it became increasingly clear that Microsoft was not really interested in supporting them after XP.
- <meta name="color-scheme" content="light dark">
- :root { color-scheme: light dark }
- @media (prefers-color-scheme: dark) { }
- <picture><source media="(prefers-color-scheme: dark)">
.... and then we've got `light-dark()`, the goofy looking dragon hanging out to the side of these majestic, forward-thinking parts of the specification.Did they not look at the prior art and notice that "one of these things is not like the other?" All the other pieces of this puzzle, conceivably, could have one day had something like `:root { color-scheme: halloween }` or `@media (prefers-color-scheme: supercontrast)` but no, we're just going to cement `light-dark()` as the only two possible color schemes we'd ever want to switch between forever.
Also, prefers-contrast media query exists, which can be used in combination with the luminance modes (color-scheme): halloween-light, halloween-dark, halloween-light-high-contrast, halloween-dark-high-contrast.
It's not like CSS was pure and elegant to begin with, so why not add an oddity that is actually useful?
And by naming the function `light-dark()`, they explicitly left the door open to introduce something like you suggest in the future. Had they already named the function something more generic, it would limit the flexibility of any future API!
I wish Windows would steal this feature for the whole OS: I don't want Notepad to use dark for text, but per-app setting usually turns the whole app light.
But whether it is my os ui or my phone ui, I feel like I can't distinguish borders and boundaries in the UI as well as I can with light mode.
I guess we should thank Dang for this feature! :)
Hopefully Safari team would continue to get resources to fix and improve Safari. The final 10% is going to take some long grinds I am a little worry their new CEO will reduces resources.
chrome://flags/#enable-force-dark
Works great 99% of the every time.
I can't personally support light modes in my own software because I can't use/test them, but I'd still add an untested one and fix bug reports about it.
I'm just curious about what people mean when they talk about astigmatism in this context, because the term is usually thrown around without qualifications (plain "astigmatism" as opposed to "irregular astigmatism" or "uncorrectable astigmatism"). So I'm curious about the astigmatism of people for whom dark mode on glowing devices is a problem. Is it typically extremely severe? Is it typically uncorrectable? Is it that people's glasses or contacts are often subtly wrong/outdated? Are many astigmatics not myopic or presbyopic enough to wear glasses all the time anyway? Astigmatism is a broad category and I'm curious about the specific impairments people who avoid dark mode have, in part because I have astigmatism and nonetheless prefer (require, really) dark mode because of other vision problems.
It’d be great if Apple could try this hard in the iOS messages app where there the keyboard is now only dark mode when a background is set.
The preference, either way, is an important accessibility feature.
I don’t get the point at all (and don’t want to hear it, I’ve seen the arguments before).
It’s nice it’s there for people who want it but it baffles me it’s constantly treated like the greatest thing ever.
Because wood is bright and you can’t really print white ink on a black paper?
There might be a usability advantage but using black ink on white paper doesn’t really prove that, that’s just the easier option of the two possible choices.
I can't buy a white pencil or ballpoint pen that works as reliably as something from Ticonderoga or Bic. White Sharpie markers do not exist. White inkjet cartridges do exist, but they're specialized items that have a high ratio of solids and this produces far worse clogging issues than the CMYK we're used to using.
Apple soon started offering a dark mode as an accessibility feature https://kalleboo.com/linked/mac_closeview_control_panel.png
It was not an intended way to use things all the time for a large chunk of the user population.
Not the same.
When Apple introduced Liquid Glass, "reduce transparency" was also an accessibility feature.
But that’s still quite different to me to how people treat dark mode.
I promise you 20/30/40% of people or whatever were not using invert colors on the Mac or Windows.
That being that black paper is more expensive than white and that we're stuck with historical precedence?
Reading white text on a black background is much, much easier for me, and the few times I've had the pleasure of doing the same with paper, I still found it to be better. I haven't tried longer texts, since nobody's publishing actual books with black paper, but I'm willing to bet it I'd feel the same about those.
This just reads to me the 'serifs are important because they make reading easier (when reading of paper)', which doesn't reflect my lived experience at all. The only reason these phenomena seem to exist are historical accident and people being used to them.
- Dark mode is harder to read when it’s bright out
- Light mode is blindingly bright when I’m in a dark room (and turning the brightness sufficiently low makes everything look washed out.)
My devices change from light mode to dark mode at sunset and it’s basically ideal.
Also it’s nice to just have less artificial light as the sun sets, which makes falling asleep naturally a bit easier.
https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/A...
It's 2026, how does every single website, especially this one, not support this?
If/when flat design goes the way of the dodo and light themes are designed sanely once again I’ll pick them back up.
Back in the day (work from office lol) people would always pick on me for that, playfully of course.
It's good that it exists though. Some people have different work environments or other types of vision problems than astigmatism, and if dark mode works for them supporting it in more places is good.
Maybe we could also have a way to indicate that the user wants high contrast, but that starts becoming a lot of special cases to design for.
[1]: https://stephango.com/flexoki [2]: https://go.dev/blog/go-fonts#go-mono-fonts
P.S. the Duck browser literally has a universal dark mode setting, I don't recall a site it wasn't able to dark-force darkify for me (language is fun)
I also detest the conflation of OS dark preference, browser chrome theme preference, and website rendering preference. It should be obvious to anyone that these are three different concepts where people can have different preferences for each. The cargo-culting in silicon valley drives me nuts.
If the website is using modern CSS then the colors would be set via CSS variables instead of being set inline in lots of places.
> I also detest the conflation of OS dark preference, browser chrome theme preference, and website rendering preference. It should be obvious to anyone that these are three different concepts where people can have different preferences for each.
Most people definitely prefer consistency so I don't think it is unreasonable to default to following the system preference.
The fact that this website wasn’t capable of dark mode made me create a CSS overlay on desktop.
I am back to somewhat normal now with my eyes, but I feel really bad for anyone in the same position.
I know that the current exact HN is magic, but come on. There is CSS to detect the system’s theme. There is no need to create a button or anything.
I'd share my ruleset, however, I am missing one. Before I switched PCs (motherboard caught fire) I had one that made everything dark mode, didn't dim the text, and buttons/text inputs/other inputs were also properly inverted. I had to make it myself because googling Hacker News dark mode always led to the same broken themes. I forgot to back it up. Adding dark mode doesn't need a bunch of extensions, and while I'm sure the "stylus" extension is probably useful (I haven't used it, sounds like a CSS override extension), UBO does CSS and JS.
Just my thoughts. Don't mind me.
The latest Safari also supports creating limited extensions on the fly via AI.
it now has many dark themes, bloomberg is my favorite.
Where are the themes? (I might be missing on mobile)
I have no idea why all the fucking vibed websites that swank around the web these days are unable to do a simple thing:
* Have one or more "themes" with dark and light variants
* Query the browser for a preference of light or dark and offer the default theme with the probed variant.
There is also the rather wider issue of accessibility in general. I happen to be an older bloke with astigmatism and rapidly worsening ... fucked up focussing and glasses and that. I'm lucky to have both eyes and decent colour perception and general all around acuity (for a given value of acuity).It's 2026 FFS. Why on earth is this even being discussed as an issue? We have all these cool vibed efforts that can't even be bothered with simple basics.
If you go with a cheap enough colo provider, you can get it down to like $200/mo (depending on electricity prices and such where you are) with an initial cost of like $800 for some used server hardware.
I do appreciate how minimalist hackernews tries to be, but I think respecting the operating system's theme can be considered very minimalist
Javascript: https://pastebin.com/50EUfktL CSS: https://pastebin.com/nzEhxxBY
Personally I'm using an HN version of Twitter's Dim theme [3]
[1] https://soitis.dev/comments-owl-for-hacker-news
[2] https://github.com/insin/comments-owl-for-hacker-news/blob/m...
[3] https://imgur.com/a/comments-owl-hacker-news-dark-modes-iFSk...
iOS since 26 has been presenting parts of the system in dark mode despite having the device set to light only. One of the ‘best’ is that launcher groups switch to dark background, but they forgot to switch the text colour, so app names are unreadable. I had hoped iOS 27 would fix it, but no, so I'm switching to Android.
I added dark mode to my blog a while ago and it was a little trying to do properly.
You can implement a half-assed dark mode yourself by adding the following css.
@media(prefers-color-scheme: dark) {
body {
filter: invert();
}
}
All your images will be inverted as well, which doesn’t work well for photos. filter: invert() hue-rotate(180deg)
For images. Works better for illustrations to get the vibe of the original colours than actual photographs. color-scheme: light dark;
should be sufficient to enable dark mode for users who prefer dark mode.For icons, ideally they’d be SVGs controlled by currentColor, but that may not be feasible or convenient depending on your setup.
Sounds like the Noir dev is going to be the next victim of Apple's Sherlocking.
Worse: it’s attacking you
Worst: it’s attacking someone else as you
- Checking "Enable remote debugging" and "Enable chrome and add-on debugging toolboxes" in devtools settings, opening Browser Toolbox (Ctrl+Shift+I), and looking at the "Network" tab
or
- Enable add-on debugging and inspect the addon from `about:debugging`
The WCAG 2 contrast checker is known to be inaccurate, specifically for light on dark color combinations (i.e. dark mode) meaning 4.5:1 isn't always going to be easy to read so it's surprising they're not at least using a higher ratio. The APCA contrast checker (was being considered for WCAG 3) is more accurate at measuring readable contrast levels and the docs explain the problems with WCAG 2 more:
https://git.apcacontrast.com/documentation/APCAeasyIntro.htm...
Today it is!
https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/V...
https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/A...
I know some people care about dark mode (and that's why I bit the bullet to add it), but I'd honestly much rather have spent all that time working on actual features.
Because correct me if I’m wrong, neither of these features were in the Tech Preview.
And numerous features have been in Tech Preview that have never made it into mainline Safari.
Safari Beta is generally what you'd want to use to test features coming to the next Safari release.
And yes, features appearing in Technology Preview aren't necessarily guaranteed to ship in Safari.
To try it, go to chrome://flags and search for Dark Mode, then enable Auto Dark Mode for Web Contents.
Alternatively, you can toggle it on using the Chrome DevTools Rendering tab, as "Enable automatic dark mode"
Having built websites myself, I know how much attention it takes to make sure every page and component looks good in both light and dark mode.
It's not perfect yet. Even in the second demo, you can see that the chart remains white, creating a stark contrast with the rest of the page. But it's a great step toward making dark mode work across the web without requiring every developer to implement it themselves.
I'm sure there are designers that love dealing with two themes, and will do beautiful work within each theme.
But I'm really fine with letting the computer figure it out. CRM, back office tools, admin dashboards... many clients are approving one design and dark mode is an afterthought. Why can't the computer just... do it for me, and do a better than passable job at that.
The other was Github's icon. But `filter: invert(1)` does a pretty decent job of handling that as long as the icons are black and white.
In dark mode, any windows that aren't dark can be huge eyesores.
I recently made a menu bar utility to enable per-window color invert for this reason: https://github.com/pazimzadeh/WindowInvert/
It helps for apps that don't have dark mode yet (Pages, etc) and even some apps that do (Preview has a dark mode, but it doesn't work on old PDF's).
> It’s precisely because Adaptive Dark Mode is happening deep within the WebKit browser engine that we are able to find creative ways to solve the most complex challenges, apply the transformations with great speed and power efficiency
Besides Solarized Dark, GitHub’s Soft Dark theme is quite well done, but unfortunately it’s not the default for a logged-out user with dark mode. So with dark mode I need to log in to GitHub to get acceptable colors.
Now that I think about it, I need a feature to limit the darkness of colors anywhere on the page, background or text except images. Remap #000 to #222 and #fff to #ddd.
I use the Dark Reader extension's brightness and contrast settings to fix this often, or other times I use the Stylus extension and write custom CSS.
2. The site can always provide their own dark theme if the automatic one is broken.
Here is to hoping that is not the case, and they did a good job with the implementation in Safari, but I have my suspicions.
Yes, developers can solve this by simply implementing dark mode.
I use the brave beta appearance option "Dark Mode" and every now and then a site is almost unreadable.
But this Apple arrogance is also why they are Apple. And why you are using a software keyboard and a phone shaped like a dark mirror.
I just switched after being an Android user since the dawn of the smartphone era. There are some improvements over Android so I'll give them credit but holy hell is navigation just a complete mess. Every app seems to behave differently, and even within the same app you'll see inconsistencies.
Would it really be that hard to provide a universal back gesture that works across apps like Android has? It makes the phone so clunkly and slow.
• As a web developer: what a nightmare, now your website will look different to different people, as if having to support multiple browser engines and multiple screen rations, and multiple platforms, etc. was not a big pile of problems already.
• As someone who doesn’t like dark-mode due to eye strain: good-good… for people who like it ¯\_(ツ)_/¯
> The HTML <meta name="color-scheme" content="light only"> tag lets browsers know that 1) this page supports light mode and 2) should only be displayed in light mode.
(I say this as a designer who has spent countless hours on dark-mode palettes as well as someone who has the automatic circadian toggle enabled everywhere.)
That's what the web has always been. People don't all have the same display types, the same subpixel layouts, the same display sizes, the same DPIs, the same fonts, the same zoom levels... People use reader modes, global restyling extensions, per-site custom style sheets, full screen magnifiers, bounded/partial magnifiers, screen readers, OS high-contrast modes... the web has never been a fixed canvas that you get to paint on and then hand to users.
I wish the crusade to make everything dark would end.
So do others. https://xkcd.com/3227/
So… the browser is now intentionally lying now. Ain’t that great.
To the server. I'm 100% behind this. The unholy amount of control websites have over our web browser should go down, not up.
Especially when so many lack reasonable ADA compliance.
Don’t you love it when browsers lie to websites to enhance the user’s privacy.
Meanwhile this features is actually tired to a persisted device setting that doesn't get reset every time you go to a new page.
This is how you get designers to work around your browser's limitations. "This CSS won't work for Safari users with dark mode on, so let's use this combination of javascript frameworks instead"
Quite a few apps now requiring MacOS 26 or higher because of the AI hype train. It's frustrating.
MacOS 15 only came out 2 years ago and isn't end of life!
[0] https://appleinsider.com/articles/26/11/03/apple-brings-3-bi...
This has to be the result of some passion project by yet another whacko dark mode fanatic (you know who you are). Non-standard, assuredly buggy, and basically a maintenance nightmare. Good luck with that craziness.
Can we have another setting which turns dark websites into actually readable light designs for adults?
Personally, I find it close to perfect for Gmail and HN, among others
This sounds like it meets that threshold, it will just surely be a hit-or-miss mess. Hopefully if it makes it to iOS it will drive more site owners to adapt to `prefers-color-scheme`.