`prefers-reduced-data` CSS Media Query

[argyleink]

Braw mornin' TAG!

I'm requesting a TAG review of CSS prefers-reduced-data.

This feature indicates explicit user opt-in for a reduced data experience that when communicated to origins allows them to deliver alternate content honoring such preference - e.g. smaller or no images, less/no web fonts, smaller video resources, alternate markup, etc.

• Explainer: https://github.com/argyleink/prefers-reduced-data-explainer
• Specification URL: https://www.w3.org/TR/mediaqueries-5/#prefers-reduced-data
• Tests: https://github.com/web-platform-tests/wpt/blob/master/css/mediaqueries/prefers-reduced-data.html
• User research: https://github.com/w3c/csswg-drafts/issues/2370
• Security and Privacy self-review²: https://github.com/w3c/csswg-drafts/issues/4832
• Questionnaire: questionnaire.md
• GitHub repo (if you prefer feedback filed there): n/a
• Primary contacts (and their relationship to the specification):
  • Adam Argyle, Google
  • Yoav Weiss, Google
• Organization(s)/project(s) driving the specification:
  • HJ Chen with this PR
• Key pieces of existing multi-stakeholder review or discussion of this specification:
  • CSSWG Github issue
  • Intent to Prototype
  • Related TAG review of saveData
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status):
  • Chrome Status

Further details:

• [x] I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: n/a
• The group where the work on this specification is currently being done: CSSWG
• The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): CSSWG
• Major unresolved issues with or opposition to this specification: adds a fingerprinting vector
• This work is being funded by: Google is implementing and HJ Chen did the spec work

We'd prefer the TAG provide feedback as (please delete all but the desired option):

💬 leave review feedback as a comment in this issue and @-notify @argyleink and @yoavweiss

[LeaVerou]

Hi @argyleink,

We looked at this today during one of our weekly breakouts, and we noticed there is no explainer and no response to the Security & Privacy Questionnaire. Could you please update us when these are ready so we could take another look? Thank you!

Useful links:

• Explainer Explainer
• Security & Privacy Questionnaire

[atanassov]

Despite use cases being somewhat obvious, we encourage use of the explainer template in order to capture all the other important bits in a single place - other considerations, code examples, privacy, security and a11y considerations etc. Can you please write one?

Reviewing the linked issues and discussions during our TAG hybrid F2F, @LeaVerou, @plinss and myself were wondering - What is the expected behavior of this capability in case when low data settings flip on and off, change halfway during loading, etc?

[argyleink]

explainer created and added! 🙂

---

What is the expected behavior of this capability in case when low data settings flip on and off, change halfway during loading, etc?

Like other media queries, the value styles contained in the query unapply or apply respectively. Flipping it on won't cancel any network requests, nor with flipping it off. Generally safe to say that flipping it off will cause network events to send, while flipping it on less likely to do so. That helpful? Should the spec or explainer define this? Seems like something media queries, which can change URLs and assets, has already defined somewhere?

[argyleink]

should I copy/paste questionnaire answers into this issue? at the bottom of the issue description?

[torgo]

Hi @argyleink sorry for the late reply - thanks for the updated explainer. You can simply put the questionnaire responses in the same repo in a separate markdown doc and link to it from here.

[argyleink]

i've done my best! added it to the issue detail, but here it is as well

[torgo]

Ok thanks @argyleink that's great. We're generally positive on the feature and the design. Can you let us know any information about multi-stakeholder support? Right now Chrome Status shows "no data" for Firefox, Safari and "Web Developer" support (although there is some info provided under user research - thanks for that). Is there any further info in this area?

[LeaVerou]

Hi Adam,

We discussed this again today, and in addition to our previous question about multi-stakeholder support, we had some additional concerns related to when this MQ is expected to change (which based on your previous comment seems to be left up to the implementation right now).

If it could change every time a user's connection speed changes, then this has the potential to be the worst of all worlds: both the low and high bandwidth versions of any CSS or HTML assets differentiated based on this MQ would be loaded, spending more of the user's bandwidth than if the MQ did not exist at all. We can see many well meaning authors doing things like:

.foo { background: url("4k.jpg");

@media (prefers-reduced-data) {
    .foo { background: url("hd.jpg");
}

Imagine a user that starts off high bandwidth when the website is loading, then gets a reduction in network speed later. Not only have they actually downloaded the high bandwidth version of the website (and potentially paid a lot for it), but won't even get to enjoy it because once the MQ flips, it will trigger the lowres version even if nothing is actually downloading when it changes! Not to mention how jarring it will be to experience the change.

While it's easy to address that by caching the value of the MQ when the page loads and using a corresponding root class, in general in Web Platform features, the simple syntax should not be doing the potentially harmful thing.

If assets are loaded imperatively, this is also not ideal, because you could end up with a website with mixed assets, which may not even work well together.

Lastly, there are also use cases where you do want the MQ value to reflect the most recent knowledge about the user's network speed or preference, e.g. in apps that load content continuously, so redefining this to remain fixed for the entire session duration would also leave a lot of use cases out. 😕

[argyleink]

oh, is there an operating system / browser that flips between reduced data or not on it's own based on connection speed? i'm only aware of settings where a user is in charge, where a manual change is done by the user. So a user could yes, switch the setting themselves and see the page update and get "the worst of both worlds" but I don't think there's scenarios where engines do this automatically?

is there a between the lines recommendation here to not have the page automatically update when the setting changes, rather only look at the setting on page load? couldn't this same effect happen with print stylesheets, where someone goes to print and ends up downloading much higher resolution images and paying for it, even though the page downloaded 1x images on initial load? this is a great conversation topic though I'd be interested in discussing further 🙂

[tunetheweb]

I think there's a confusion between bandwidth/ECT media queries (not being proposed here) and data-saver media query (which IS being proposed here).

Bandwidth media queries would have that issue (which @yoavweiss raised years ago in this article), but prefers-reduced-data shouldn't have that issue as it's an explicit user setting to turn off or turn on. And yes, if a user changes this setting mid-load (seems unlikely) then we should respect that change - even though it could result in another download of the lower sized asset (which may not "reduce data" for that particular scenario). But that's the same if someone changes their viewport size mid-load, or even after load, for traditional media queries.

[LeaVerou]

We looked at this again today during a breakout.

We understand that it's a user setting. However, our concern was that the user's device may try improving their experience by changing that setting when the user is in areas of low connectivity, effectively making this work like a bandwidth MQ.

Simply making it evaluated only on page load is not a solution, because for long-running apps this can end up being user hostile when the app loads in high data mode, then the setting flips (either due to user action, or other reasons). One solution might be that it can only go from high to low data mode during the lifetime of the page, and never the other way.

We would like to see this issue addressed in some way.

[argyleink]

Simply making it evaluated only on page load is not a solution

agree 👍🏻

We would like to see this issue addressed in some way.

Gotcha, so the spec (or the proposal?) should have some prose around what happens when the media query changes post page load, and the suggestion is to reevaluate the page if the data mode switches from high to low, but not low to high? This is in an attempt to save a user from accidentally incurring high data usage once they've already loaded the page with reduced data? Sounds good to me.

[LeaVerou]

Thanks for being receptive to our feedback. To be clear we want to encourage you to think about this problem and implement a solution that makes sense for this API, since you know the use cases of the API you are designing better. Please don't simply take our idea without discussion. We look forward to hearing what you come up with - please document it in your explainer and let us know.

[argyleink]

I like the user focused intent of y'all's feedback. While it's new for a media query to guard like this, and the spec draft will need an update to reflect it, I do think this spec design detail is meaningful and not just implementation of feedback.

Find the updated notes in the explainer here 👍🏻

[plinss]

@argyleink just to be clear, our feedback was a strawman to start a discussion, not a specific design proposal (and we're fairly certain it's not sufficient on its own). We want to be sure this issue gets proper discussion within your working group and the relevant factors get due consideration.

Please let us know when you have a real design for this behavior we can review (also feel free to tag TAG members in to your discussions as appropriate if you need more feedback on our concerns).

[argyleink]

Working group issue was raised and comments led to a bit of prose added to the spec. The added note speaks to the User Agent's freedom to handle toggling cases with their own discretion, while also supplying 2 scenarios to help inform their implementation and user centered consideration.