`[css-media-5]` - `prefers-reduced-data` question: special behavior when turned off and on post page load?

[argyleink]

During TAG review (found here w3ctag/design-reviews#705) a question/concern was brought up that should pass through the CSSWG for discussion:

should the prefers-reduced-data media query specify special behavior when users toggle from a low data preference to a high data preference?

The use case:
given a page has loaded and the user was in reduced data mode, then later turns reduced data off, what should happen?

1. we treat the media query like any other where users have control, and reevaluate the page, likely causing downloads
2. add spec prose that prevents automatic reevaluation only when users change their setting from low data to high data post page load; making users explicitly refresh to see the non-reduced data page and thus being in control of additional downloads
3. something else?

The concern:
A user might not expect/want the page to reevaluate, and be surprised when potential MBs of data begin downloading for the non-reduced data page. Maybe they thought they cached it and were good to turn off their reduced data setting and read or browse.

[argyleink]

given that prefers-color-scheme has no special toggling logic, which can download different artwork to match the palette (among other asset downloads), should it also qualify for this post page load behavior?

could adding this special behavior lead to a user wondering why the page is still in a reduced data state, even tho they just toggled save data off? they may test light and dark toggling and see the page update, and scratch their head when toggling save data doesnt?

[bramus]

Looking at the scripting media feature, it also doesn’t get updated on the fly. It retains the value that was returned upon reading it (for that matter: the whole page doesn’t update when flipping JS being available or not, the UA mentions that you should reload the page)

Maybe prefers-reduced-data would also be eligible to fall into this category of “read it only once”?

[SebastianZ]

Regarding prefers-reduced-data, I'd say, the opposite use case is probably the more important one.

Imagine, a user loads a page and sees that it drains their data. So they turn reduced data on.

In that case, the user probably expects the change to take effect immediately and further data transfer is reduced.

scripting is a special case, as turning scripting on or off requires a page reload to take effect on the JavaScript side. So CSS should follow that.

Other media features like prefers-color-scheme, prefers-contrast or pointer seem to me like they should also take effect immediately when changed, because those changes can happen dynamically.

And media features like update, dynamic-range, color-gamut or resolution are bound to the hardware and therefore mostly won't change dynamically.

Given that, I'd suggest to add an entry to the definition table of each media feature that indicates whether UAs are expected to adjust to changes immediately or not.

Sebastian

[frivoal]

Regarding prefers-reduced-data, I'd say, the opposite use case is probably the more important one.

I agree. Turning that feature on on a page that is done dowloading heavy assets shouldn't throw these away to download additional lightweight assets.

Overall, this concern was why we pushed back on having a bandwidth MQ, as this would dynamically change as the user goes in and out of rooms, tunnels… The expectation being that preferred-reduced-data is more of a semi-permanent setting, and as the occasional switch from one mode to the other is rare, it's not that much trouble.

That said, we could add an explicit permission for the user to apply discretion as to the timing of the switch, making it clear that it's allowed to delay it on a per-page basis for as long as the user hasn't navigated elsewhere (or reloaded). I think that's kind of implied by the current definition (since the mechanism for turning it on or off is undefined), but we could be explicit. Or do we need to go further, and require delayed application?

[tabatkins]

Agreed that (prefers-reduced-data) shouldn't trigger more downloads, but it is generally pretty static. I think an explicit mention in the spec allowing UAs to delay changing its value would be appropriate. (As Florian says, the spec doesn't technically need to say anything, since the condition is somewhat undefined anyway, but it's useful to hint to implementors what a good behavior might be.)

[frivoal]

Reopening: the edit that closed this issue is not backed by a WG resolution. The added wording seems generally reasonable to me (aside from the use of RFC2119 language in a Note). I am less sure about the removal of the inline issue though.

[argyleink]

Reopening: the edit that closed this issue is not backed by a WG resolution. The added wording seems generally reasonable to me (aside from the use of RFC2119 language in a Note). I am less sure about the removal of the inline issue though.

thanks Florian, I'm open to advice on how to be work better within the process and spec verbiage, and apologize for any churn adding the note caused.