[css-mediaqueries] Expose User Preference Media Queries as HTTP Client Hint or HTTP Header

[tomayac]

Problem Statement

CSS media queries, and specifically user preference media features like prefers-color-scheme, have a potentially significant impact¹ on the amount of CSS that needs to be delivered by a page.

Focusing on prefers-color-scheme—but highlighting that the reasoning in this issue applies to other user preference media features as well—it is a best practice to not load CSS for the particular non-matching color scheme in the critical rendering path, and instead to initially only load the currently relevant CSS. One way of doing so is via <link media>.

However, high-traffic sites like Google Search that wish to honor user preference media features like prefers-color-scheme and that inline CSS for performance reasons need to know about the preferred color scheme (or other user preference media features respectively) ideally at request time, so that the initial HTML payload already has the right CSS inlined.

Potential Solutions

Client Hint

HTTP Client Hints defines an Accept-CH response header that servers can use to advertise their use of request headers for proactive content negotiation, colloquially referred to as "client hints" (demo, try it in a current version of Chrome). One such potential client hint that could help with the above scenario might be a tentatively titled Media-Feature hint, which would notify the server about, for example, the currently preferred color scheme.

• Meta note 1:
  This is somewhat of the inverse of what is being proposed in [css-mediaqueries] Proposal: "prefers-reduced-data" #2370, where the Save-Data header is suggested to be exposed through a prefers-reduced-data media query.

• Meta note 2:
  HTTP Client Hints as of draft 07 no longer includes the concretely supported client hints as it was still the case with 06, which is why I decided to file this here in the csswg-drafts repo.

• Meta note 3:
  The Accept-CH-Lifetime header field was likewise removed in draft 07. This header would have enabled delivery of client hints on subsequent requests to the server's origin (and not just sub-resources).

New HTTP Header

Given the changes in Meta note 3, an alternative approach could be to introduce a whole new Media-Feature header (obviously likewise only a tentative name) rather (than a client hint), similar as what has happened with Save-Data, which up until draft 06 was a client hint before being promoted to the Network Information API.

Proposed Syntax

The header in both cases (Client Hint or New HTTP Header) could look something like in the example below, with the concrete user preference media features as a comma-separated list:

Media-Feature: prefers-color-scheme=dark, prefers-reduced-motion=reduce

Privacy Considerations

The fingerprinting discussions in Client Hints likewise apply.

——
¹ "Implementing Dark Mode took over 1,000 lines of CSS"—https://webkit.org/blog/8892/dark-mode-in-web-inspector/

[ithinkihaveacat]

Is there a way for this header to be controlled (activate) via a per-site user preferences? Most of the sites that support dark mode today do so via explicit user preferences (i.e. cookies) and I would expect this to continue.

(Overall the situation seems somewhat analogous to the Accept-Language, which is technically the "right" way to support multiple languages, but which is routinely ignored by various sites in favor of explicit user preferences.)

[tomayac]

Persisting the user preference doesn't make sense for the subset of users who set their preferences automatically (and thus unpredictably). For example, iOS 13 allows for sunset-based automatic dark or light appearance:

[tabatkins]

This seems pretty reasonable to me overall. I'm not experienced in working with HTTP headers, tho: what group typically specifies them?

[ithinkihaveacat]

@tomayac Yes it can be controlled by the system but I don't think the site-based preferences will go away any time soon (if ever), and it seems like this platformy mechanism will go unused if there's no way to "merge" the two settings. (Similar to the way Accept-Language is generally ignored.)

[plinss]

@tabatkins https://httpwg.org/http-extensions/client-hints.html

[tomayac]

Yes it can be controlled by the system but I don't think the site-based preferences will go away any time soon

@ithinkihaveacat The idea here is to allow for both, people to manually override their system settings (e.g., have their OS in dark, but their Google in light), but to also honor people who have their (potentially automatic) system setting determine everything else.

[tomayac]

This seems pretty reasonable to me overall. I'm not experienced in working with HTTP headers, tho: what group typically specifies them?

https://httpwg.org/http-extensions/client-hints.html

@yoavweiss, @igrigorik Given Meta note 2 and Meta note 3 in the comment above, is https://httpwg.org/http-extensions/client-hints.html the right place to start a discussion about (or even land) the described client hint (or new header)?

[yoavweiss]

https://httpwg.org/http-extensions/client-hints.html defines the infrastructure but not the headers that use it. Those are defined elsewhere (e.g. https://wicg.github.io/netinfo/)
So you could define those headers either here (if the editors and the WG are OK with that) or as a separate spec.

[tomayac]

https://httpwg.org/http-extensions/client-hints.html defines the infrastructure but not the headers that use it. Those are defined elsewhere (e.g. https://wicg.github.io/netinfo/)

@yoavweiss This was my understanding, thanks for confirming.

So you could define those headers either here (if the editors and the WG are OK with that) or as a separate spec.

@tabatkins Question to the CSS WG: are you fine with spec'ing such a header or client hint here?

(Updated per #4162 (comment)) One important remark: since Accept-CH-Lifetime was removed from draft 07 (I think this is the relevant discussion that caused its removal), currently a client hint would not suffice, as it would only be sent for subresource requests, but not the main document (which would be needed for the inline CSS use case to be covered). Quoting from the demo: "If the Accept-CH-Lifetime duration is omitted, then the opt-in only applies for subresource requests of the document advertising the Accept-CH policy".

Given the above, we are left with defining a whole new HTTP header that gets sent unconditionally (like Save-Data), or the HTTP WG needs to reconsider the Accept-CH-Lifetime decision. Please advise, @yoavweiss and/or @igrigorik.

[yoavweiss]

Accept-CH-Lifetime was removed, but its persistency features were not (it was removed as it was suggested that implicitly setting persistency for the lifetime of the session would provide the same benefits and would lower complexity).

[tomayac]

Oh, great, in that case a client hint definitely is still an option (and probably the preferred option).

So question to @tabatkins and the CSS WG: are you fine with spec'ing this here?

[tabatkins]

Agenda+ to see what the rest of the group thinks.

[MatsPalmgren]

Is Client Hints restricted to secure contexts? It seems bad if a client broadcast this fingerprinting material over a cleartext channel.