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: [css-mediaqueries] Proposal: "prefers-reduced-data" w3c/csswg-drafts#2370
• Security and Privacy self-review²: [css-media-queries-5] Add security and privacy section to "prefers-reduced-data" w3c/csswg-drafts#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:

• 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]

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.