-
Notifications
You must be signed in to change notification settings - Fork 673
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[media-queries-5] should "prefers-reduced-data" be binary or not #4833
Comments
The MQ as currently specified maps the JS API into CSS. If it were to be extended in the future, what would prevent us from extending it at that point in time? |
Research shows me we're on track with a binary toggle. The user is flipping a switch to indicate the preference, just like Windows has ways to limit data, but doesn't have a system wide switch for it. Would love to hear if there's plans for it or not. Worth noting too that these data saver modes can be toggled much easier than reduced motion, they're accessible from "quick settings" areas of each platform. |
Agenda+ to see if there's anything new on this topic, or if we should close in favor of the binary toggle status quo |
The CSS Working Group just discussed
The full IRC log of that discussion<fantasai> Topic: prefers-reduced-data<fantasai> github: https://github.com//issues/4833#issuecomment-663555808 <fantasai> argyle: This is about preference for reducing data <fantasai> argyle: Can be expressed in headers <fantasai> argyle: and this feature exposes as MQ <fantasai> argyle: .. <fantasai> argyle: can see what Chrome plans to reduce <fantasai> argyle: Goal is to send less bits over the wire to users that have that set <fantasai> florian: Currently it's a binary preference <fantasai> florian: Earlier we wondered if it needs to have multiple leves <fantasai> florian: State today, the JS API being proposed along with this, there are only two levels <fantasai> florian: So should only have two levels for now <smfr> q+ <fantasai> florian: This feature can be used as boolean, so if we want to add more values later can <fantasai> florian: but current proposal is to close as no change, leave as a binary <fantasai> argyle: OSes don't have degrees, just binary switch <fantasai> argyle: can expand later if needed <fantasai> smfr: More levels is more fingerprinting surface <fantasai> smfr: Apple already have concerns about this <fantasai> smfr: allows targetting ppl on low-bandwidth, which is often poorer community <fantasai> smfr: e.g. <fantasai> florian: There is a privacy fingerprinting warning issue in the spec about this, and it is visible in the spec <fantasai> astearns: So consensus seems to be keep binary for now <fantasai> RESOLVED: prefers-reduced-data remains binary <chris> q+ after florian <chris> sigh <astearns> ack after <astearns> ack smfr <chris> q+ |
Spec Link
During the WG call it was requested/proposed that confirmation and research be done to ensure that data-saver shouldnt feature enums (low, medium, high, etc) or a range/spectrum/etc instead of a binary preference. The concern is that the current spec is only solving the current state of data saver preferences, and potentially isn't thinking enough about future queries that developers may need.
This issue is to hold the discussion around the values accepted for the media query
prefers-reduced-data
.The text was updated successfully, but these errors were encountered: