[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.