Re: [csswg-drafts] [css-mediaqueries] Expose User Preference Media Queries as HTTP Client Hint or HTTP Header (#4162)

The CSS Working Group just discussed `Expose User Preference Media Queries as HTTP Client Hint or HTTP Header`.

<details><summary>The full IRC log of that discussion</summary>
&lt;AmeliaBR> Topic: Expose User Preference Media Queries as HTTP Client Hint or HTTP Header<br>
&lt;AmeliaBR> github: https://github.com/w3c/csswg-drafts/issues/4162<br>
&lt;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.<br>
&lt;AmeliaBR> …If you want to make changes on first display, need that before the page downloads.<br>
&lt;dino> q+<br>
&lt;AmeliaBR> …Idea is to pass this info to server as a client hint &amp; server can respond with the good stuff<br>
&lt;AmeliaBR> …Some debate on the invalidation logic. The settings can change over the course of a session.<br>
&lt;astearns> ack dino<br>
&lt;AmeliaBR> …But overall, idea seems reasonable. But I'm not well versed on client hints.<br>
&lt;AmeliaBR> dino: My pref is that this shouldn't happen. Media queries are supposed to be dynamic &amp; can cause page changes.<br>
&lt;tantek> +1 dino<br>
&lt;AmeliaBR> …Changing which JS you download doesn't seem to conform.<br>
&lt;AmeliaBR> …Could also make pixel tracking techniques even easier.<br>
&lt;drousso> q+<br>
&lt;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.<br>
&lt;dino> q+<br>
&lt;florian> q+<br>
&lt;astearns> ack drousso<br>
&lt;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.<br>
&lt;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<br>
&lt;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.<br>
&lt;AmeliaBR> TabAtkins: I suspect this is similar to state handling in many JS based apps, but I'm not an expert.<br>
&lt;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<br>
&lt;astearns> ack dino<br>
&lt;AmeliaBR> drousso: Would probably need to add query parameters to CSS so that it can be invalidated.<br>
&lt;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<br>
&lt;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.<br>
&lt;astearns> ack florian<br>
&lt;AmeliaBR> TabAtkins: Sounds reasonable. Can you add these comments to the issue so we can close it with reasons?<br>
&lt;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.<br>
&lt;astearns> ack dbaron<br>
&lt;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<br>
&lt;AmeliaBR> dbaron: I am also generally skeptical. But I think some arguments given here aren't correct &amp; 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.<br>
&lt;AmeliaBR> …I'd also want more details on proposal anyway before accepting.<br>
&lt;dbaron> s/tracking is not as easy/designed so fingerprinting is active rather than passive/<br>
&lt;AmeliaBR> astearns: OK. So let's follow-up on issue.<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4162#issuecomment-528136108 using your GitHub account

Received on Wednesday, 4 September 2019 23:47:40 UTC