[css-mediaqueries] Expose User Preference Media Queries as HTTP Client Hint or HTTP Header #4162
Comments
|
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.) |
|
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:
|
|
This seems pretty reasonable to me overall. I'm not experienced in working with HTTP headers, tho: what group typically specifies them? |
|
@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.) |
@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. |
@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)? |
|
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.
@tabatkins Question to the CSS WG: are you fine with spec'ing such a header or client hint here? (Updated per #4162 (comment))
|
|
|
|
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? |
|
Agenda+ to see what the rest of the group thinks. |
|
Is Client Hints restricted to secure contexts? It seems bad if a client broadcast this fingerprinting material over a cleartext channel. |
Yes, as of draft 05. |
|
@tomayac |
|
Thanks, @Malvoz, this is very valuable information! For the CSS WG consideration, here's the relevant deep link of @mnot's post linked from Fetch Metadata Request Headers. |
|
The CSS Working Group just discussed The full IRC log of that discussion<AmeliaBR> Topic: Expose User Preference Media Queries as HTTP Client Hint or HTTP Header<AmeliaBR> github: https://github.com//issues/4162 <AmeliaBR> TabAtkins: Idea is that some of the preference media queries trigger fairly substantial changes to a page. E.g., reduced motions might trigger more than just CSS fix-ups. <AmeliaBR> …If you want to make changes on first display, need that before the page downloads. <dino> q+ <AmeliaBR> …Idea is to pass this info to server as a client hint & server can respond with the good stuff <AmeliaBR> …Some debate on the invalidation logic. The settings can change over the course of a session. <astearns> ack dino <AmeliaBR> …But overall, idea seems reasonable. But I'm not well versed on client hints. <AmeliaBR> dino: My pref is that this shouldn't happen. Media queries are supposed to be dynamic & can cause page changes. <tantek> +1 dino <AmeliaBR> …Changing which JS you download doesn't seem to conform. <AmeliaBR> …Could also make pixel tracking techniques even easier. <drousso> q+ <AmeliaBR> TabAtkins: I disagree that changing downloads is a minor benefit. Could help make sure that initial payload is as small as possible, good for many use cases. <dino> q+ <florian> q+ <astearns> ack drousso <AmeliaBR> …Already, sites can *try* to do this by setting server cookies based on previous MQ results. That's more likely to mess things up than using HTTP headers. <tantek> CSS is a tiny fraction of what G sends down compared to the heaps of JS. Not buying the "send less CSS" argument as a practical impact here <AmeliaBR> drousso: Using the example of dark mode, downloading only a slimmed-down dark mode CSS. If that MQ changes, then the cache invalidation must need to handle the change in state, to know what to download. <AmeliaBR> TabAtkins: I suspect this is similar to state handling in many JS based apps, but I'm not an expert. <tantek> LMK if there's a noJS version of G properties that has well designed CSS for normal/dark mode and what % of the page download that would impact <astearns> ack dino <AmeliaBR> drousso: Would probably need to add query parameters to CSS so that it can be invalidated. <tantek> +1 dino thanks for making the right argument. sending both normal/dark CSS rules are tiny compared to all the rest of the page load size <AmeliaBR> dino: I think the savings for cutting out a bit of CSS is probably not worth the overhead. Cookie tracking might not be that bad an alternative. <astearns> ack florian <AmeliaBR> TabAtkins: Sounds reasonable. Can you add these comments to the issue so we can close it with reasons? <tantek> I'd say, the additional fingerprinting from Client Hints for this are not worth the fractional anticipated performance gain by less CSS compared to the massive JS in practice. <astearns> ack dbaron <AmeliaBR> florian: Another concern is privacy. If we allow this on HTTP as well as HTTPS, preferences get leaked everywhere. Also, logged on all sorts of servers <AmeliaBR> dbaron: I am also generally skeptical. But I think some arguments given here aren't correct & what to make sure those are clarified. Client hints spec integrates with vary headers, so that caching can handle it. And tracking is not as easy as suggested. <AmeliaBR> …I'd also want more details on proposal anyway before accepting. <dbaron> s/tracking is not as easy/designed so fingerprinting is active rather than passive/ <AmeliaBR> astearns: OK. So let's follow-up on issue. |
|
Apple/WebKit is pretty strongly against this.
|
|
@dbaron I am not convinced about the active vs passive distinction: it can very easily become a "best practice", possibly propagated by some popular framework, to always ask, and then the distinction goes away. |
|
Thanks for discussing this proposal. Some remarks based on the IRC logs.
Google Search in a not logged in session currently contains… …about 23kb of inlined CSS.The idea of this proposal definitely is to still support dynamic switching, simply by deferring the loading of CSS for the currently not needed mode.
Keeping the initial payload small is indeed crucial for high traffic sites like Google Search.
Very much true, especially now that automatic color scheme switching has become a thing in both Catalina and iOS 13, and now that Android 10 toggles dark theme when battery safer is on, we expect the preference to change non-predictably, so storing the value in cookies definitely would make things worse.
You can try support.google.com, which has a manual theme mode switcher (at the very bottom). It does a full refresh, though.
Client Hints currently makes the following requirements (emphasis mine): "The opt-in SHOULD be persisted and bound to the origin to enable delivery of Client Hints on subsequent requests to the server’s origin, and MUST NOT be persisted for an origin that isn’t HTTPS".
As outlined above, we see this as an advantage (i.e., the argument being to keep the initial payload small).
This can be circumvented by leveraging the Happy to try to answer more questions the group may have. Apologies if the above responses potentially were a bit off, it was hard to get the full gist regarding the caching discussion by looking at just the IRC logs ("Some debate on the invalidation logic."). |
But those are fetched regardless, aren't they? |
Very much true, but for the Update 1: For the Update 2: The |
|
It is correct / intended probably, as the load of the outer It could probably be optimized to not block rendering, though it probably requires spec changes. |
|
I think it's fine to not block, please see https://crbug.com/1001078. |
|
Sure, in that simple example. But if you have mixed import rules, per spec you need to process the Anyhow I don't think as is https://html.spec.whatwg.org/multipage/semantics.html#interactions-of-styling-and-scripting allows that, though as I said it seems reasonable to change that, maybe. |
@frivoal
That is not accurate:
Vary headers solve that problem. Variants will enable solving it with better granularity in the future, but since we're talking about exposing a single bit here, I doubt they matter for this discussion. |
|
@tabatkins I think we've tried to come up with answers to the questions and concerns that were brought forward here on this thread as well as on IRC (based on the logs). The Google Search team are still eager to follow through with the overall idea described in the initial comment. Could the CSS WG maybe discuss this again based on the provided answers? Thanks in advance. Also happy to join a call if this would be helpful. |
|
FWIW, the |
|
igrigorik/http-client-hints#73 seems relevant as a detailed request for a |
|
@tabatkins Any chance this could be |
|
I'd just like to add my support to this proposal. Calibre is a tool to help teams test and monitor the performance of their pages. If there were headers set by the browser, our customers would easily be able to set headers for page testing conditions — then they'd get metrics and feedback about their sites in more user conditions. This'd be especially useful for turning off animations (so that metrics are more accurate) as well as better supporting accessibility efforts. Huge 👍 from me. |
|
I'd like to add my support as well. We're 100% committed to supporting specifically the prefers-color-scheme accessibility feature, but with our SSR setup it's currently practically impossible to prevent the default theme being briefly rendered on first load before the view is hydrated on the client-side, unless we sacrifice time to first contentful paint by displaying the page only after hydration. Getting this information in the request header would allow us to properly render with the expected color scheme right away. I understand that we could use CSS variables and ship both light and dark themes with the initial rendered HTML, but we're using styled-components as a CSS-in-JS styling solution, as many others do. Systematically, this means our theme is rendered using JS so we have no way to render the page properly without knowing the user preference on the server render. Unless we invest weeks into changing our styling toolchain, that is… |
|
I support the proposal too. If a request can contain the color-scheme information, we can provide not only optimized stylesheets but also optimized images based on the preference. As clients can provide DPR, viewport-width and etc. for similar purpose, I believe providing color-scheme is not that far from that. |
|
Together with the |
|
FYI, we have started the TAG review process for a new set of User Preference Media Features Client Hints Headers, for example, |
|
To close the loop on this: we have introduced the |
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-schemeand 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-CHresponse 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 titledMedia-Featurehint, 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-Dataheader is suggested to be exposed through aprefers-reduced-datamedia 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-Lifetimeheader 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-Featureheader (obviously likewise only a tentative name) rather (than a client hint), similar as what has happened withSave-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:
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/
The text was updated successfully, but these errors were encountered: