Why this, why now

On 2026-11-03 the WebKit team announced Adaptive Dark Mode in Safari 27.3 beta. When the user turns it on, the engine repaints "light" sites that have no dark mode of their own. According to WebKit, almost 40% of page loads come from users in dark mode, yet only about 10% of page loads support it. The idea is to close that gap from the browser side.

The announcement drew 496 points and 259 comments on Hacker News and around 30 points on Lobsters. Opinion split cleanly. One camp said "as a web developer, this is a nightmare: the site will look different to different people." The other replied that "the web has never been a fixed canvas" and that the user agent works for the user. A third argument formed around the fact that JavaScript querying CSS colors gets the original colors back, which some called the browser "intentionally lying."

This piece is not a tour of a new Safari feature. It is about the model the feature rests on: color-scheme negotiation in CSS Color Adjustment. That is how the author's and the user's wishes are matched through color-scheme, and who wins in the end. Chrome on Android has run an Auto Dark Theme inside the same framework since 2021. Automatic darkening is no longer just an extension trick; it is becoming legitimate, in-spec engine behavior. It is worth understanding the negotiation properly now.

The problem

Dark mode has always involved three parties with different interests.

• The user doesn't want to be blinded by a white page in a dark room. Others, for example people with astigmatism, can't read dark pages at all (plenty of them spoke up on HN).
• The author wants brand colors and figure contrast to look as intended.
• The user agent wants to honor the user, but if it recolors a page into something unreadable, the blame lands on the browser.

The naive approach breaks things. Say an author sets a pale cream page background and leaves the text color unspecified, expecting the default black. If the UA flips its default text color to white for a dark-preferring user, you get white text on cream. That is why the baseline rule has been: unless the page explicitly opts in, the UA doesn't even darken the colors it controls (form controls, scrollbars, system colors).

Adaptive Dark Mode and Chrome's Auto Dark Theme take the exception path out of that baseline. Only when the user asks strongly do they transform the author's own colors on a page that never opted in. Where that is allowed, and how authors can stop it, is the subject here.

How it works

1. The vocabulary of the negotiation

CSS Color Adjustment Module Level 1 (a CR Snapshot was published on 2026-10-30) defines these inputs.

• Color scheme preference (the user's side): no preference, a preference for light or dark, or an overriding preference (a strong wish that comes with overriding colors).
• Color scheme support (the author's side): null (nothing declared), or an ordered list of supported schemes. The list can carry a sole support flag, meaning "only these."
• Authors declare it page-wide with <meta name="color-scheme" content="light dark"> in HTML, or per element with the CSS color-scheme property.

The grammar of color-scheme is normal | [ light | dark | <custom-ident> ]+ && only?. Because of the &&, both light only and only light are valid. The WebKit post writes the former and Chrome's article writes the latter.

2. How the used color scheme is chosen

Here is the spec's "determine the used color scheme" algorithm, rephrased so the intent is clear.