Lea: I don't see anything wrong with it, seems uncontroversial, reasonable media query addition

Rossen: from privacy point of view? Exposing the fact that you're ..

Lea: doesn't specify how it's set - automatically or user preference? Left up to implementations

Rossen: if you're roaming and you have to pay and you don't want to the devie can be aware and say reduce the data and it's going to propagate down to the UA. That makes sense

Lea: the OS itself could expose a setting so the user could explicitly opt in or out

Dan: they haven't really written a proper response to the privacy and security questionnaire. Simply pointed us to an issue which has a link to the privacy considerations section of the spec.. but no answer to questions...

Lea: no proper explainer...

Rossen: explainer is a link to an issue in the CSS WG

Hadley: a closed issue

Dan: privacy considerations section is minimal to say the least. We should ask for proper consideration of privacy qustionnaire.

Tess: the reason you write an explainer isn't because the TAG wants you to, it's for everyone. We might be who nag about writing them but it's really for a general audience to understand your feature, a background.

Dan: I do think they should spend time thinking about the issues raised in the questionnaire. Pointing to a random link where they'v ebeen discussing privacy shows they're dismissive of this bieng a privacy issue. We should hold off responding

Amy: questionnaire is to prompt them to think through important issues and report back. We might miss things from a surface level review

Lea: [writes comment]

Dan: they created an explainer. Use cases look reasonable.

Dan: asks for security & privacy review

Rossen: the answer is handwavey re: behaviour when the setting is changed between on and off. I wouldn't consider this as a fringe scenario. On mobile data you can be going between different places on wifi and off wifi as you're moving. Which will cause the experience to go between on and off. Response is quesitonable. Let's say I'm on an okay connection and I'm downloading a file that is really large. Then I go to roaming, in which case I need to save money and badwidth, and prefers-reduced-data kicks in. He's saying when it goes on it will not cancel the request, still downloads the huge file. Either he didn't understand implementation and how it works, or I'm questioning the design.I don't see this addressed anywhere in the explainer. Could be a development for the future. I'm sympathetic to use cases and handling this with a media feature makes sense to me. I'd caution as a strong design concern is this reliability and expectation of this and how much will developers try to fight it off vs use it.

Peter: he's describing the behaviour as running a network request to completion once it starts. I hear your concern but I'm not sure that doing it the other way would be much better. Say you've got a large file and a medium file and you're half way through the large file and you switch to low bandwidth, so you abort the large file and download the medium file.. then go back and it goes back to the large one and starts over.. if you flip back and forth and cancel requests, you're going to double your data. This is a rational behaviour.

Rossen: this is my concern. I understand. I'm not seeing any kind of mechanism around is this going to be reactive. What is the frequency of this. How reactive is this? My expectation is that it's going to be, if it matches any other media query, as soon as the system state changes that is going to be affected to the media query evaluation.

Peter: Right

Rossen: my point is sthat for network connections, especially on mobile, the frequency of change can be much greater than any of the other media features today. Prefers-reduced-motion, prefers-dark-mode - fairly infrequent user initiated system states. This one is not. So because it is not you're at th emercy of the frequnecy that you're moving with. Because this is much different than the other media features in terms of that frequency I want to see something that suggests that they were thinking about this and that they could suggest .. either accept it and say it could be a problem and it's low risk to high benefit. Or they can say yeah we will throttle it somehow and maybe once you're in one load session we'll run to some level of completion an dthen switch. Something along those lines. I don't see anything to suggest they're thinking about this.

Peter: I heard your original concern being that you wanted it to abort high bandwidth connections if you drop to low bandwidth mode. You just want them to address it?

Rossen: Yeah. My follow up would be what does tha tmean from user experience. Am I going to end u pwith mixed content or not?

Peter: I Think that's a bigger concern that you're going to end up with a page with half high bandwidth and half low bandwidth content

Rossen: UX is going to be questionable a lot of times. Responding to system state and affecting presentation through it gives me pause a lot more than other media features

Peter: are you suggesting that it may be better for the user if when the page load starts it picks a mode and sticks with it at least for a while

Rossen: basically yes. Reviews that .. what are they optimising for? For reducing cost to the user? Or for presentation? I don't think there's a middle ground, because that would be mixed content. [will leave a comment]. I don't want to over-design it. Overall approach is fine. I'll provide this feedback to CSS WG as well. I can close satisfied with concerns?

Dan: leave the comment pending external feedback

Rossen: worst part is when it comes to fonts. Affects a LOT of things.

...on from Breakout A.

Rossen: binary or a scale.. My feedback is starting with a binary and then extending is good... All in all it's a decent feature. I can see how it would be useful. It's being addressed by the right folks. I think we're close to closing.

Dan: there's no indication of consensus with any other party besides google / chromium, ?? and microsoft. Design sounds fine but is there any indication that anybody else is paying attention? No indication about web developer support, or from Safari. Where is this coming from? I feel like it's a good thing, but that's my anecdotal feeling.

Rossen: Great question.. ask?

Dan: okay

Ok thanks @argyleink that's great. We're generally positive on the feature and the design. Can you let us know any information about multi-stakeholder support? Right now Chrome Status shows "no data" for Firefox, Safari and "Web Developer" support (although there is some info provided under user research - thanks for that). Is there any further info in this area?

Lea: we told them to add an explainer..

Dan: good to see this.

Lea: since this basically a boolean - when is it supposed to be true? When you're on cellular data?

Rossen: it's the UA being in "data saver" mode.

Lea: the example is a signifigantly reduced user experience...

Rossen: anything that puts the user agent into data saver mode...

Lea: I wonder if 2 scenarios is granular enough... but maybe the boolean is the easiest way to go... but as a developer I wouldn't know what kind of experience to serve with this boolean. Remove images?

Rossen: all of it... Because it's binary it allows you to as an author reduce anything you want to reduce. You may want to completely restyle... loading no fonts, less images... we've had a back-and-forth about this API - what happens when you go back and forth in the consiumption capabilities... roaming case..

Dan: 2g to 5g connectivity just in the course of a half hour trainrride... happens to me all the time in London.

Rossen: the answer is a little vague.. don't want to rush this one... From TAG pov the use case makes sense,.. the way it's being approached makes sense... We need to consider more the implementation...

Lea: for me the main concern is lack of granularity...

discuss more at plenary

Dan: prefers reduced data .. Lea left a comment. Could lead to more data being used. We have responses. Which are that it's intended it's a user choice rather than based on network conditions

Peter: until ua adds that auto setting

Dan: exactly, that's what happened with dark mode. Pretty reasonable to make that.. what's in the spec to normatively say the ua should not be making this choice?

Yves: always the same issue - trying to figure out what kind o fnetwork you're on, which is always difficult, if you have a 4G base station, and you're on wifi, and you can't figure out..

Amy: also still doesn't solve the problem of the unspecified behaviour when switching between

Peter: what happens when the switch is flipped? they have to make the call. Does it only apply to future loads, or refresh everything, or not apply at all? one way or another they all have problems, but the spec should pick one and say it so at least it's interoperable. Are they thinking through all these implications? They need to. Is there a better approach?

Dan: I left a comment. We reviewed last week. Generally positive. Asked about multistakeholder. We were hoping they'd have come back with an answer so we could close.

Lea: I could ping the requester

Dan: great

Peter: revisit in plenary. Does this change during a pageload?

Lea: I think we concluded that it doesn't?

Dan: concluded it would be up to the UA to mediate the change to something that makes sense? Or up to the device, so the device has to .. it's a blunt instrument, designed that way. Up to the device not to flip it back and forth multiple times per second

Lea: are there any use cases of changing it throughout the life of a website or app?

Rossen: the default, you're moving. Changing cell towers. Bitrate varies.

Lea: I understand your bandwidth might change. but if you've already loaded the high bandwidth website is there any case where you might want to switch at that point? After you've already loaded all the assets.

Peter: maybe you haven't. If you've loaded them there's no pint in throwing them away

Lea: exactly

Peter: but if you're on a navigation site and you're moving it's goign to be loading new images of where you're go. Walk out the door from wifi to 3G. I have high res content, and now I start getting low res content. Or do I keep getting high res content because I initially loaded the page in a high bandwidth content?

Lea: so it can end up sending more bandwidth than either version?

Peter: if you reload assets yeah

Dan: but that would be up to the app designer

Lea; if you're writing css that loads certain background images under this media query you have no control, they just load

Rossen: my comment from March 22nd asks about that

Dan: I think it wasn't as explicitly obvious until I heard Lea articulate it. Might be worth raising separately in the issue.

Rossen: sure

Dan: I was thinking about it from the perspective of as Peter was saying, you're using a web app, scrolling and you certainly wouldn't want if the web app had already downloaded the high quality assets that it would throw them away

Lea: thinking of match media where you control through js.. but there are a lot of declaritive things that load when a media query matches. Fonts, background images, srcset.. all of that stuff is triggered automatically without any control. if the media query changes what it matches then you'll end up loading a bunch of stuff.

peter: you shouldn't reload something youv'e already loaded, but it's pretty easy to get into a state where you've got half the assets loaded under high bandwidth and some loaded under low. And maybe they don't match any more.

Lea: who is you? The app developer writes html an dcss that matches a media query, they are nto doing the loading. They migth think they're being nice and providing a low res version and end up loading both the high res version and the low res version because the user had some spike of bandwidth

Dan: that's not accounted for in their explainer

Peter: I'm concerned if it flips half way during page load. Half may not match.

RosseN: which could be changes to layout even

Peter: I could have said under high bandwidth I load a pretty background which measn I have to have my text be white, and on low bandwidth background is white and I get white text on white. One solution is you pick one at the start of page load and stick with it, but that could leave users loading high bandwidht content later

Dan: or what's the beginning or ending of a session. I coudl go to a webpage, ptu my phoen down, pick it up 15 minutes later and scroll on the same site. But in different network conditions.

Peter: or I start streaming a video at home, then walk out the door - switch to low bandwidth version in the middle?

Lea: valid use cases for both something that changes and something that doesn't. Maybe a media query is not the best approach here.

Peter: or the behaviour needs to be clearly defined so authors can reason about it. I remember we had these questions, was wondering if we got answers

Rossen: very wishy washy..

Peter: not so much thought through

Lea: should definitely not be up to the implementation. I think that's the worst of all worlds. Not knowing what you'll get.

Peter: agree behaviour should be clearly specified

Lea: also the simple syntax should not be doing the evil thing. I don't want to see well meaning authors wasting more bandwidth trying to do the exact opposite

DRAFT COMMENT:

Hi Adam,

We discussed this again today, and in addition to our previous question about multi-stakeholder support, we had some additional concerns related to when this MQ is expected to change (which based on your previous comment seems to be left up to the implementation right now).

If it could change every time a user's connection speed changes, then this has the potential to be the worst of all worlds: both the low and high bandwidth versions of any CSS or HTML assets differentiated based on this MQ would be loaded, spending more of the user's bandwidth than if the MQ did not exist at all. We can see many well meaning authors doing things like:

.foo { background: url("4k.jpg");

@media (prefers-reduced-data) {
	.foo { background: url("hd.jpg");
}

Imagine a user that starts off high bandwidth when the website is loading, then gets a reduction in network speed later. Not only have they actually downloaded the high bandwidth version of the website (and potentially paid a lot for it), but won't even get to enjoy it because once the MQ flips, it will trigger the lowres version even if nothing is actually downloading when it changes! Not to mention how jarring it will be to experience the change.

While it's easy to address that by caching the value of the MQ when the page loads and using a corresponding root class, in general in Web Platform features, the simple syntax should not be doing the potentially harmful thing.

If assets are loaded imperatively, this is also not ideal, because you could end up with a website with mixed assets, which may not even work well together.

Lastly, there are also use cases where you do want the MQ value to reflect the most recent knowledge about the user's network speed or preference, e.g. in apps that load content continuously, so redefining this to remain fixed for the entire session duration would also leave a lot of use cases out. 😕

Lea: This is exposing a system setting

Tess: that system setting can change during the life of a page...

Dan: I think the device could change it without the user's express action as the user and their device moves from areas of low connectivity to high connectivity, back again, etc... e.g. on a train and using a webapp. E.g. a whereby call...

Tess: webrtc already does some of that for you - in the webrtc context... Using this media query for that might not be the best approach.

Dan: you're right webrtc might not be the best example.

Peter: according to the article - the article is talking about a user setting, not an automatic detection...

Lea: a lot of comments we got is that there is no OS that currently does that. But I wonder if it would make sense to say "this media query is evaluated on page load and never changes.." that would prevent the concern if it flips halfway through the session.

Peter: don't like the argument that nobody has done it that way so we don't have to support that.

Tess: in this case, I'm not so worried - because the setting can change web devs can code to that ...

Peter: i think they need to specify it one way or another...

Tess: reminds me of page visibility API... you want to specify a floor. Don't want to over-constrain browsers ability in the future to do this in additional cases where they see a performance benefit... I suspec in this case you need leave some wiggle room. With page visibility developers started to use it in contexts where spec authors didn't expect... Metered connectionc case in this case - maybe if the browser knows you're international data roaming - maybe it should say "prefers reduced data" regardless.

Peter: what triggers it is probably outside the scope...

Tess: you need a floor - minimally it's a user setting.

Peter: even when they say "user not likely to flip" - what about long-running apps like PWAs... I'm still using the same app a month later...

Lea: so only examining it under page load is problematic...

Lea: what's the solution....?

Peter: I don't think locking it is the worst case scenario...

Tess: locking it on pageload kind of sucks... if you're on e.g. youtube... it keeps churning through bandwidth... If it's gonna fail you want it to fail towards using less data.

Peter: you could lock it one way and let it degrade but never let it go the other way... until you reload. we don't have to design it - we should just detail the issue and let them [the working group] work it out.

Lea: writes comment...

We understand that it's a user setting. However, our concern was that the user's device may try improving their experience by changing that setting when the user is in areas of low connectivity, effectively making this work like a bandwidth MQ.

Simply making it evaluated only on page load is not a solution, because for long-running apps this can end up being user hostile when the app loads in high data mode, then the setting flips (either due to user action, or other reasons). One solution might be that it can only go from high to low data mode during the lifetime of the page, and never the other way.

We would like to see this issue addressed in some way.

(Dan, Peter, Tess): +1

Dan: requester has responded to Lea's comment and indicated that .. I asked for some clarification, sounds good to me.

Lea: one of my issues is that we should have identified a problem but we weren't necessarily saying this is the solution, but that the issue needs to be addressed. I'm not sure what we proposed is a good solution, just something we came up with on a call. But sounds like they want to go with it. The crux of our feedback is they need to think about this problem, not here's how to fix it.

Dan: they seem to be receptive to the idea of fixing the problem. We could close the issue and say satisfied with concerns and say thanks for being receiptive, to be clear we want to encourage you to think about this problem and implement a solution that makes sense for you, please don't simply take our idea without discussion.

Lea: sounds great

Rossen: mixed .. loading different resources, potentially different fonts.. no answer to that. Answer in March was the query will evaluate however media queries evaluate. I get that. I don't get then what happens? Do you restyle the page? Or not?

Peter: the response does seem to be reload everything, not just continue in mixed mode.

Rossen: that's clear. Now I'm going back and forth between cell towers so my page is reloading every time I do that...

Peter: suggestion was you flip one way and never flip back. If they take that suggestion it's not an issue. I agree with you Lea, I'm not saying they should just do that.

Lea: it was not that you never flip back, it was that you only flip from high to low but not from low to high.

Rossen: don't understand. If I'm not able to see netflix in high res why wouldn't I flip from lower to high

Lea: it's not necessarily a good idea, that's my whole point! Not necessarily what should be implemented, I don't lik that they're going to run with it.

Dan: we shouldn't be coming up with a solution for them.. Close with concerns?

Rossen: problem is it's a very simple API that exposes holes with something we've been poking since the begining of the reivew. None of the feedback we provided seems to stick in a spec that makes for better user experience. But we want to rush and close it?

Dan: I'm not pushing to close. Agree we should be going for higher quality. Let's not close it if that's not right.

Peter: my suggestion is we ask them to re-open or ping us when they have a solution

Rossen: in which case I think we should make the closing resolution stronger than just 'with concerns'.

Lea: since they seem to be willing to work in it isn't our usual process to leave it open pending feedback? They can come back and tell us the change they made. Doesn't seem en par with our usual process to close and say reopen it.

Dan: let's leave a comment along those lines - we really think you need to come back with a solution and document it in the explainer

Thanks for being receptive to our feedback. To be clear we want to encourage you to think about this problem and implement a solution that makes sense for you, please don't simply take our idea without discussion. We look forward to hearing what you come up with - please document it in your explainer and let us know.

Dan: marked as proposed closed based on feedback from requestor - will close when Lea can join the discussion

Lea: we gave feedback - "for example do x"... They posted some updated notes. It's basically that idea...

Dan: minded to close it...

Peter: share your concern Lea that they shouldn't just adopt our suggestion...

Lea: i think there is a difference between web sites that load and that's it, and continuously downloading web sites... if you have high capability you want to get the higher-capability content at that point... what is there right now serving not either of those use cases?

... "if it's in high data mode and it switches to low data mode then apply a change if other way then do nothing"

Rossen: that sounds like a poor choice - e.g. a video call if you start in the outskirts of the city then you get better connection you don't want better quality?

Peter: understand but for video streams thats a bit of a red herring because video streams are adaptive.

Dan: WebXR environments? More connectivity e.g. web socket connections when you have a high data connection...

Rossen: we're trying to descretize the switch events... if it happens every 10 seconds that's disruptive. if it's once a minute then .. makes more sense...

Rossen: a timer for changing state...

Peter: one of our original concerns -- are people who use this feature design it so their page will still work in a mixed mode? Half-way through and it changes... will page just break?

Lea: i think a mixed mode concern only happens when they use the JS API. With media query it will be automatic...

Peter: if I'm on a high bandwidth mode then I switch to low data - so the page loads all the low data versions...

Lea: that was the basis of our original idea...

Peter: the other thing - we don't need to define it... so we should push back.... "Thanks for taking our feedback on board but..." I can write the comment.

no consensus to close at this point

Rossen: the timer thing is an idea... not sure if they talked about it...

Peter: they are saying they're not just taking what we're doing... not clear if it's a resolved decision...

Lea: problem with mixed mode, problem with having different resource if it changes, problem with...

Peter: I will send a ping. Still no feedback.

Lea: no updates - no responses... Someone said they'd ping Yoav?

Dan: i will send a note to Yoav

• Design Review: Speculation Rules (Prefetch) - @hober, @rhiaro, @atanassov

Agree to close.