[css-mediaqueries] Proposal: "prefers-reduced-data"

[Malvoz]

Would CSSWG consider this proposal of detecting exposing if the Save-Data request header from the Client Hint HTTP extension is on/off to allow for usage with CSS?

The Save-Data HTTP request header:

...a signal indicating explicit user opt-in into a reduced data usage mode on the client, and when communicated to origins allows them to deliver alternate content honoring such preference - e.g. smaller image and video resources, alternate markup...

- http://httpwg.org/http-extensions/client-hints.html#save-data

Example model

The 'prefers-reduced-data' feature:

Name:	For:	Value:	Type:
prefers-reduced-data	@media	no-preference | reduce	discrete

Example usage:

.image {
  background-image: url("image/heavy.jpg");
}

@media (prefers-reduced-data: reduce) { 
  /* Save-Data: On */
  .image {
    background-image: url("image/light.webp");
  }
}

Relevant articles, including use cases:

• https://developers.google.com/web/updates/2016/02/save-data
• https://www.ctrl.blog/entry/http-save-data
• https://css-tricks.com/help-users-save-data/

[frivoal]

Well, this would not detect the HTTP header, since that is sent from the client to the server, and this runs on the client, but we could have this and trigger it on the same conditions that cause the client to send that header.

[css-meeting-bot]

The Working Group just discussed prefers-reducued-data MQ.

The full IRC log of that discussion

<heycam> Topic: prefers-reducued-data MQ
<heycam> github: https://github.com//issues/2370
<heycam> florian: I don't know for sure in which browser but I suspect in chrome, which has a new HTTP header which they can send if the user requested so
<heycam> ... which informs the web server that you would prefer lightweight content
<heycam> ... there has been a suggestion to have a MQ to match that
<heycam> ... in the same circumstances, the page author would also know that the user may be directly / through some heuristic, prefers some lightweight content
<heycam> ... images as a bg instead of a video, e.g.
<heycam> ... seems reasonable to me
<heycam> myles: how does chrome know when to send the header?
<heycam> philipwalton: I think it's from the OS on Android
<heycam> iank_: there's a setting Chrome, prefer lightweight data, then we send everything through potentially an HTTP proxy
<heycam> ... few other things as well
<heycam> florian: is it user triggered
<heycam> iank_: yes
<heycam> ... but I'm not sure, might be varied on country basis
<heycam> ... we run HTTP proxies where we'll send traffic through that, then do a bunch of compression for the user
<heycam> myles: so the proxy might turn on the header?
<heycam> iank_: no
<heycam> ... the proxy is one of the side effects from turning on this option
<heycam> ... and I think the bit of information that we give devs is on navigator.connection.saveData
<heycam> philipwalton: it's a client hints header, in the clients hint spec
<heycam> florian: somebody proposed to detect this via MQ
<heycam> fantasai: seems reasonable to me
<heycam> astearns: is that header, are there plans for other browsers to implement this?
<heycam> fantasai: wht values does the header have?
<heycam> philipwalton: I think it's just a boolean at this point
<heycam> ... but the spec is written in a way that it could apply additional values
<heycam> fantasai: I can imagine wanting three levels, i don't care, I would prefer if you didn't give me heavy things, I'm on a metered / dialup connection
<astearns> http://httpwg.org/http-extensions/client-hints.html#save-data
<heycam> iank_: quickly looking through the additional things we expose, we also give as headers (what we think is the effective) roundtrip time
<heycam> ... an estimate of the downlink speed
<heycam> philipwalton: and effective connection type
<heycam> heycam: mobile vs fixed?
<heycam> iank_: 3g, 4g, slow 2g, ....
<heycam> florian: don't think we'd expose all that
<heycam> ... via the MQ
<heycam> ... having something that can be used in a boolean context, where one case is no preference, and may have other "yes please" levels
<heycam> iank_: one thing I'd like to see here is use cases for where it's used in CSS
<heycam> florian: use image bg instead of video bg
<heycam> iank_: do that with script
<heycam> philipwalton: 1x vs 2x?
<heycam> florian: browser should do that already
<heycam> [side discussion about font-display:optional]
<heycam> philipwalton: with save data, 1x vs 2x, could be your device supports 2x but you only want a smaller version of the image
<heycam> florian: mostly you should not be using resolution MQ feature, but instead srcset
<heycam> ... then the load data preference could influence that
<heycam> s/srcset/image-set/
<heycam> myles: maybe terribly idea, can we extend that mechanism to allow switching between videos and images as backgrounds, instead of a MQ?
<heycam> fantasai: MQs are not only used in CSS
<heycam> emilio: responsive images
<heycam> iank_: I'm not saying no, but I want to see web developer demand for this
<heycam> astearns: that's the general tone I'm hearing
<heycam> ... sounds like it could be useful, but we'd need to have it motivated by use cases and I'd prefer to see this client hint get a bit farther on the track
<heycam> florian: sounds ok
<heycam> koji: this is an Android OS setting
<heycam> ericwilligers: it's both Android and a Chrome setting

[frivoal]

The CSS-WG has considered this, and thinks this sounds generally reasonable, but we would like to hear more about what this would be used for. The cases that were brought up during our meeting all already had solutions.

Valid use cases for this that aren't already addressed by any existing thing would be a good justification to add this, so we're looking for examples of that.

[Malvoz]

Adding example to use cases:
@import "this-awesome-large-theme.css" not (prefers-reduced-data: reduce);.

This and the initial use cases could potentially all be done using scripting, as would many existing @media queries too. Will just have to wait and see how other developers recieves this proposal. Thanks for considering this.

[tabatkins]

What's this-awesome-large-theme.css? Just a really big CSS file? So you'd presumably send a much smaller, more basic CSS file instead for the reduce case?

[Malvoz]

@tabatkins

What's this-awesome-large-theme.css? Just a really big CSS file?

In this example, yes. Styles that may be redundant/not essential in terms of site functionality and accessibility but rather improves the user experience with fancy designs.

So you'd presumably send a much smaller, more basic CSS file instead for the reduce case?

Yes. Or just keep the "app shell" CSS in that main file and simply not @import any extra styles (and fonts, images etc.) when a user prefers reduced data.

[tabatkins]

I think that's a reasonable use-case that can't be addressed by any other mechanism. @frivoal, what do you think?

[frivoal]

It seems sane to me. As for implementer interest, that's not for me to say. MQ5 is still a very early draft, so I don't think the implementer interest bar has to be very high, but I'd like to see at least a nod in favor of this feature before adding it. I guess you (@tabatkins) counts as one.

[addyosmani]

@yoavweiss and I were about to propose a prefers-reduced-data media query and saw that this issue had already been filed. @frivoal, I guess beyond Tab you are still waiting on interest from one other implementor?

[frivoal]

I guess beyond Tab you are still waiting on interest from one other implementor?

Yes.

[frivoal]

Then again, it's not strictly gated on multi-vendor interest. Clear interest from Google counts for more than just Tab feeling OK with it.

I would still appreciate a detailed list of uses cases, and why existing things aren't good enough to solve them. That would help make sure the feature actually solves the problem it is meant to solve. #2370 (comment) is a start, but it'd be nice to see more detail or more cases.

[ryantownsend]

@frivoal I was chatting about this with @yoavweiss at performance.now() conf and he sent me just this thread.

I have a use-case for prefers-reduced-data in that I’m avoiding loading webfonts and some iconography (instead leaving textual labels) based on this flag.

Currently, I have an inline JS script in my <head> tag which adds a CSS class to the document – it’s only a small script so it’s pretty performant but it would be far cleaner if I didn’t have to rely on that. My workaround also breaks in cases where someone is blocking JS to also double-down on data savings (given the minimal adoption of Save-Data).

I feel like this would be useful for websites without real-time image transformation CDNs or ones which do not respond to Client Hint headers – so it would be potentially useful if this media query was available to <source>.

Hope this is helpful, please do reach out if I can provide any further context.

[Schepp]

I find the use cases Ryan outlines very interesting. On top of <source> elements this could also help with controlling resource hints.

[mrego]

@frivoal shouldn't this be rediscussed withing the working group, it seems people was positive more than a year ago, we got some interesting use cases, but then the text was added to the spec without asking for review to the rest of the group. WDTY?

[mrego]

Also regarding the example, wouldn't be better to use the webfont example instead of the image thing that can be confused with use cases already covered by responsive images?

[css-meeting-bot]

The CSS Working Group just discussed [mediaqueries-5] Adding prefers-reduced-data as part of MQ5 FPWD, and agreed to the following:

• RESOLVED: Add three issues to the ED

The full IRC log of that discussion

<dael> Topic: [mediaqueries-5] Adding prefers-reduced-data as part of MQ5 FPWD
<dael> github: https://github.com//issues/2370
<dael> Adam: Inspired by JS having similar things. Access to information about users like data saver on your phone wher eyou can say at a high level you want ot lose less data. Can reduce background activities. In JS we can be aware of this just like we can reduce motion.
<smfr> q+
<dael> Adam: If they're in 2G or paying for data or something like that. Proposal is a flag in CSS so we can make adjustments. Proposal JS is granual but CSS just needs on or off. Do they want to reduce or carry on undefined
<dael> Adam: Good intro?
<astearns> ack fantasai
<dael> astearns: Sure
<dael> fantasai: Good idea to have a MQ for this. Concern there is different levels of less data. One is I'm on a slow connection, another is I'm paying small data and want reduced functionality. I'm wondering if need a couple of levels. Reduce data and another to comprimise functionality
<fantasai> s/functionality/functionality if needed/
<dael> Adam: Good question. Reminds me of li-fi which is where it says you have wifi but you don't. Frustrating for user b/c what do you do. People can use things like service worker for that. CSS I'm not sure if we need more. I like we're mimicaing the system binary
<dael> Adam: Most questionable part of MQ is around how hard is it to use. Examples people put is I have a big BG image and people want to do a color but then browser has already loaded your image. Lot of potenial to not work. CSS b/c how it loads there's potential to not get wha tyou want.
<dael> Adam: Need to have a say where it goes. Maybe needs to be in head. MQ often bottom of file
<dael> TabAtkins: I suspect we don't need more levels right now because I don't see it being likely you have much you can do besides if it's not in data saver I load and if it's in mode I load colors. There's not much useful in CSS we can do. I suspect we just need the two. Load or don't load images
<dael> Adam: Fonts as well. You can load expensive custom fonts. Put behind the MQ and only load if they don't have preference
<dael> TabAtkins: Yeah. Yeah. Fonts and images. There isn't a middle ground. Either load or not
<astearns> ack smfr
<bkardell_> idk, I do both TabAtkins
<dael> smfr: Apple main concern is this is more fingerprinting. It's biased fingerprinting toward low income with limited data. We're concerned this could be a targetting vector.
<dael> smfr: iOS does have a settings switch but adds more fingerprinting where it remembers you flipped this switch on certain wifi. That's a worry.
<dael> smfr: Would like to see security and privacy section added to the spec
<dael> smfr: Not objecting but we do have concerns. Discussing if we would impl
<dael> TabAtkins: Are you impl the header?
<dael> smfr: I think answer is no
<dael> TabAtkins: Okay. You're not doing client hints that's acceptable problem
<astearns> ack fantasai
<Zakim> fantasai, you wanted to point out that media queries are not just CSS
<dael> fantasai: MQ aren't just CSS. Can also be accessed in JS and HTML attributes to load files. Not jsut about CSS but also controls if you load a JS library.
<dael> fantasai: Also these days not about if it's a BG image people are loading lots of videos for decoration and that's data that's not needed. Can replace that with an image. But if you're even more resource constrained you'd want an image
<chris> s/li-fi/lie-fi/
<fantasai> s/an image/no image/
<dael> fantasai: If we dn't have multiple levels now we should design so that we can expand later. I think there is multiple levels here and it's not just about CSS
<dael> Adam: Good examples. I like them
<dino> I'm not sure if the type of person who would load a huge video as a background image would also provide a fallback that is a solid colour :)
<dael> astearns: Hearing we need security and privacy section. Second is we should have separate issue about needing more then a binary state
<fantasai> dino, I can see AirBnB doing that, frex. They get pulled down over roaming connections a lot.
<dael> astearns: One bit of background. THis is on agenda b/c intent to prototype in Chrome
<dael> smfr: Would have liked to see discussion in WG before PR merged
<fantasai> +1 to smfr, adding features should get WG resolution
<dael> astearns: I think there was some but I agree there could have been more.
<dael> astearns: Looking through issue and not seeing discussion before merge, just comments on the issue
<dael> fantasai: Remove it from draft or add annotation on issues or don't leave indication that there's an issue in the draft
<dael> TabAtkins: I don't think we should remove given client hints serves the same data. Exposing to CSS is user friendliness. Precise design open issues on that. So long as client hints is going through I think we should have this in MQ as well
<dael> fantasai: We should annotate the issues a bit in the draft
<dael> TabAtkins: Yeah
<dael> smfr: Are client hints more than one impl? THe comparision isn't valid if blink is only browser that impl client hints
<dael> astearns: Anyone know the status in gecko?
<dael> ??: I believe we impl that
<dholbert> s/??/heycam/
<heycam> s/I believe/I don't believe/
<dael> astearns: Three issues. Security and privacy section. Add issue for more than binary. Add this is still under discussion and maybe not ready to ship
<dael> astearns: accurate?
<dael> Adam: Yes to me
<dael> chris: Question. Agenda item talks about if this should be in FPWD. That was published yesterday so whatever we decide will impact the ED. I think it was published with this included. I jsut took the ED and went forward
<dael> astearns: Yes, that's what you should have done. We can take it out if need be
<dael> astearns: Enough for now? Add the three issues to the draft and add them as separate GH issues
<dael> astearns: Prop: Add three issues to ED
<TabAtkins> Even in the "video vs img vs color" scenario, I don't think there's a particularly useful line to draw there. Basically, I don't think there's a particularly useful "I have plenty of data, but I'm not the *sultan*" line to use, at least in CSS. JS can do more complicated stuff, but I think in such a scenario you should downgrade all the way to a gradient or a very small image, if people are requesting reduced data at all.
<dael> RESOLVED: Add three issues to the ED

[yoavweiss]

Regarding a privacy section for SaveData in general, there's https://wicg.github.io/savedata/#privacy-considerations
If insufficient, please open issues on that draft, and just point the relevant CSS spec to it.

Also, is there a privacy section for the prefers-reduced-motion MQ?