yoavweiss
commented
4 years ago Thank you for the detailed feature request, but this spec: a) Has moved to https://github.com/httpwg/http-extensions/blob/master/draft-ietf-httpbis-client-hints.md b) Has passed WG last call. c) Defines the HTTP-level infrastructure, not the features that rely on it.
I agree that it would make sense to expose this (and other user preferences MQs) as a hint. There's an open CSS issue on that front. Would be good to concentrate efforts on missing use-cases there.
In the meantime, I think your use-cases can also be tackled in alternative ways:
- Switching the
faviconfor the page
Does
<link rel="shortcut icon" href="/dark_favicon.ico" media="prefers-color-scheme: dark"/>
<link rel="shortcut icon" href="/light_favicon.ico" media="prefers-color-scheme: light"/>work? If not, worthwhile to file browser bugs to see that it does (because it should).
- Applying different images for dark or light mode (block images - background images would be covered by media queries)
<picture>
<source srcset="dark.png" media="prefers-color-scheme: dark">
<img src="light.png">
</picture>
- Choosing App Manifest values based on dark or light mode (in particular, theme colors/swatches)
While this could take the same route as the favicon (and use the media attribute), app manifests are likely to see user preference changes throughout their lifetime, so neither MQs nor Client Hints seems appropriate. It would be better to bake in conditional values based on user preferences into the manifest format itself. Worthwhile to file an issue on https://github.com/w3c/manifest/issues
andydavies
tomayac
sgammon
Problem
It is difficult to tell if a given browser agent is using light or dark mode UI, and respond to that, without waiting for JavaScript to boot up, or applying a media query in CSS. These existing techniques cover most cases but don't cover all of them. In particular:
faviconfor the pageRationale
Switching the
faviconis a particularly salient example. With the transition to dark/light mode support, many companies - large and small - are now caught with dark icons that don't work well with dark-mode UIs. Below, an example of "getting it right" vs. not:If you squint real hard, you can see the Github icon, but Dark Mode doesn't make it easy. Google's approach - a field of white - works in all modes, but also pops when it doesn't need to:
Favicons are not settable via CSS, but they can, of course, be changed with JavaScript. The problems with this approach are likely the cause of both issues above.
Google, and companies like it, want a consistent favicon experience so that users can easily identify their properties. However, to account for the above contrast issues in dark/light mode, Google would be forced to adopt JavaScript code on every single property and page in order to appropriately serve or change the favicon. This is sub-optimal for a number of reasons:
Adding JS to change the
faviconincurs a runtime code increase, across all pages and properties, regardless of whether the user ever changes their theme, and for the marginal benefit of afaviconthat lives in harmony with the world around it. This is already a tradeoff most developers quite sensibly wouldn't make.Even worse, this approach is unable to be proactive, because the browser won't wait for JS to load a
favicondeclared by markup, or one served at the root of the site. In fact, waiting will yield an error by default on some page-loads (at least in Chrome - a 404 for/favicon.ico). At best, there are workarounds (serving a transparentfaviconand then substituting with JS), but no optimal way to simply serve the right icon the first time.As usual, the exclusive advantage of JavaScript here is event-based programming. However, what percentage of users change dark/light mode while on a given web page, versus landing on that web page with dark mode and later leaving, having not changed it? Many fewer, of course, which mitigates this advantage almost entirely.1
Potential Solution: Client Hints
Meanwhile, there is a new feature in HTTP land that seems well-suited to help solve this problem: Client Hints! Let's suppose there was a new
Themehint.Now, my examples might look like this:
Browser:
Google:
Browser:
Google: *serves an epic icon for dark mode*
This approach could, of course, be extended to stylesheets and scripts which can now be aware of the theme and serve other resources appropriately. Images aside from the favicon could choose to invert transparency or perform other tricks, and stylesheets/scripts have a chance to adapt as well.
This CH-based approach accomplishes a solution to the favicon problem with a much less invasive approach: (1) the document endpoint must serve
Accept-CH(already true), and (2) the assets that change must honor the new hint. Although this change isn't universally trivial, it only touches assets that change, rather than every page on every property, which is a crucial win.Privacy Concerns
Technologies like Client Hints present an inherent risk of information leakage (i.e. HTTP fingerprinting and related mitigations). Of course, balancing these risks with legitimate performance/experience concerns is always a challenge.
However, Dark mode/Light mode likely doesn't present much of a risky change from a privacy standpoint, for a number of reasons: 1) Dark/light mode is a function supported across most modern operating system UIs (macOS Mojave+2, Windows 10+3, GNOME 3, iOS/iPad OS 13+4, Android 10 (API level 29+)5).
2) There are multiple ways to end up with Dark mode1 (i.e. it is not only a consequence of a static setting chosen by the user). This eliminates any meaning of categorical value for a Dark mode hint from a given client, because for an increasing number of browsing agents, it may simply be the result of a temporal condition (i.e. the time-of-day where the user is).
3) Many users opt to use dark mode full-time. I do not have access to statistics describing how many opt into this feature, but the Chrome team might (
( ͡~ ͜ʖ ͡°)). What I can tell from outside Google is, Dark mode has been supported directly since Chrome 73, which was released in February 2019 (over a year ago, as of this writing). Chrome 73+ (again, as of this writing), represents about 63.21%6 of the entire browser-agent footprint internet.4) Aside from Chrome, Safari 13+ brings in an additional 12.95% of the internet, bringing the total to 76.16% of measured browsers (from Can I use) that could feasibly have dark-mode enabled via a static setting. I bring up this point to illustrate the lack of fingerprint value in a dark mode Client Hint, even when combined with other CH values like RTT, in terms of identifying the approximate location of the user emitting the hints. That is to say, it is perhaps no less risky than the RTT or Theme hint, sent on their own.
5) The Client Hints Delegation proposal on W3C's Feature Policy spec might further mitigate these concerns in a substantial way.
I know this is just a rough start estimating the privacy implications, but I anticipate this may be a concern, so I wanted to surface some thinking on it to get the ball rolling.
Prior Art
I could not locate an existing issue or proposal relating to dark/light mode Client Hints, but of course, I could have missed something.
Citations
1: macOS now supports dynamically switching from dark/light and back based on the current time-of-day, so this may happen more often now. 2: "How to use Dark Mode on your Mac" 3: "Windows 10 dark mode is here. Turn it on now" 4: "iOS Human Interface Guidelines: Dark Mode" 5: "Android Developers: Dark Mode" 6: "Can I use: Browser Table"