Intent to Prototype: prefers-reduced-data

[Adam Argyle]

Contact emails

arg...@chromium.org, yo...@yoav.ws

Explainer

https://github.com/w3c/csswg-drafts/issues/2370

Design docs/spec

Specification: https://drafts.csswg.org/mediaqueries-5/#prefers-reduced-data

https://drafts.csswg.org/mediaqueries-5/#prefers-reduced-data

TAG review

Summary

Support to be added for the CSS media query prefers-reduced-data. This will detect if the user has set "data saver," or other platform equivalent, in their system, and give developers hooks into this user desire when loading or styling a page. This is for users who prefer to use minimal amounts of data on their device, and for developers to adapt to this preference. 

Motivation

Client hints and Javascript already have access, let's give it to CSS as well

Risks

Interoperability and Compatibility

Could fail to become an interoperable part of the web platform if other browsers do not implement it.

Firefox: No public signals

Edge: No public signals

Safari: No public signals

Web developers: No signals

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux,

Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes

https://github.com/web-platform-tests/wpt/pull/21731

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5922192355229696

This intent message was generated by Chrome Platform Status.

[Manuel Rego Casasnovas]

On 12/02/2020 01:04, 'Adam Argyle' via blink-dev wrote:
> Risks
> Interoperability and Compatibility
> Could fail to become an interoperable part of the web platform if other
> browsers do not implement it.
>
> Firefox: No public signals
> Edge: No public signals
> Safari: No public signals
> Web developers: No signals

I guess it'd be nice to reach more vendors and check their feelings, it
seems initial proposal on the CSSWG was seen as something positive, but
I guess it'd be good idea to come back and check the feelings from the rest.

Apart from that I found this interesting article by Yoav: :-)
https://www.smashingmagazine.com/2013/01/bandwidth-media-queries-we-dont-need-em/
There he explains some issues if the bandwidth changes and you need to
re-download an image in lower quality (when you already have a better
image downloaded).
Would this be still an issue with this media-query?
Is the browser going to realize there are changes on bandwidth quality
and trigger this, or it's going to be something only triggered manually
by the user?

Bye,
Rego

[Yoav Weiss]

On Thu, Feb 13, 2020 at 1:05 PM Manuel Rego Casasnovas <re...@igalia.com> wrote:

On 12/02/2020 01:04, 'Adam Argyle' via blink-dev wrote:
> Risks
> Interoperability and Compatibility
> Could fail to become an interoperable part of the web platform if other
> browsers do not implement it.
>
> Firefox: No public signals
> Edge: No public signals
> Safari: No public signals
> Web developers: No signals

I guess it'd be nice to reach more vendors and check their feelings, it
seems initial proposal on the CSSWG was seen as something positive, but
I guess it'd be good idea to come back and check the feelings from the rest.

Indeed. Your proposal (on the issue) to bring it up in a CSSWG meeting SG.

 

Apart from that I found this interesting article by Yoav: :-)
https://www.smashingmagazine.com/2013/01/bandwidth-media-queries-we-dont-need-em/
There he explains some issues if the bandwidth changes and you need to
re-download an image in lower quality (when you already have a better
image downloaded).
Would this be still an issue with this media-query?
Is the browser going to realize there are changes on bandwidth quality
and trigger this, or it's going to be something only triggered manually
by the user?

Thanks for pitting past-me against me :)

Past-me is still correct - bandwidth fluctuations will make any bandwidth based media query impractical.

This is why I don't think we should try to create a media query version of e.g. the NetInfo API.

At the same time, this MQ is not about bandwidth, but about user-preferences.

While it's possible that users will play around with their settings while a site is loaded, it's less likely than e.g. screen orientation, and not likely to happen a lot.

So, I think the particular problem I was pointing out regarding bandwidth MQs doesn't exist here.

Bye,
  Rego

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/719bb9ba-0a08-4f4a-81e4-e5f40213bb95%40igalia.com.

[Mathias Bynens]

Have you considered DevTools and Puppeteer support? 

Concretely, CDP already has a Emulation.setEmulatedMedia method which is meant to emulate all CSS media features through its features param. For prefers-reduced-data and other media features that are added from now on, it would be nice to ensure they play nice with this mechanism.

The DevTools team can then provide a UI to emulate the new media feature, and work on exposing this to Puppeteer as well.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b2c933a3-13f6-4f42-97c7-9e28139d4f9a%40chromium.org.

[Adam Argyle]

Yep, devtools integration/emulation was on my radar 👍

I was hoping I could add the option to the dropdown where the rest are and follow the patterns there for reduced-motion, but sounds like I'll need to get some assistance from DevTools to complete the ux? Help me find the best way to collab and engage y'all, I'll follow the proper processes. Thanks!

[Mathias Bynens]

Glad to hear DevTools is on your radar :) Awesome, thanks! Definitely open to collaboration; you know where to find us!