-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
prefers-reduced-data
CSS Media Query
#705
Comments
Hi @argyleink, We looked at this today during one of our weekly breakouts, and we noticed there is no explainer and no response to the Security & Privacy Questionnaire. Could you please update us when these are ready so we could take another look? Thank you! Useful links: |
Despite use cases being somewhat obvious, we encourage use of the explainer template in order to capture all the other important bits in a single place - other considerations, code examples, privacy, security and a11y considerations etc. Can you please write one? Reviewing the linked issues and discussions during our TAG hybrid F2F, @LeaVerou, @plinss and myself were wondering - What is the expected behavior of this capability in case when low data settings flip on and off, change halfway during loading, etc? |
explainer created and added! 🙂
Like other media queries, the value styles contained in the query unapply or apply respectively. Flipping it on won't cancel any network requests, nor with flipping it off. Generally safe to say that flipping it off will cause network events to send, while flipping it on less likely to do so. That helpful? Should the spec or explainer define this? Seems like something media queries, which can change URLs and assets, has already defined somewhere? |
should I copy/paste questionnaire answers into this issue? at the bottom of the issue description? |
Hi @argyleink sorry for the late reply - thanks for the updated explainer. You can simply put the questionnaire responses in the same repo in a separate markdown doc and link to it from here. |
i've done my best! |
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? |
We looked at this again today during a breakout. 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. |
agree 👍🏻
Gotcha, so the spec (or the proposal?) should have some prose around what happens when the media query changes post page load, and the suggestion is to reevaluate the page if the data mode switches from high to low, but not low to high? This is in an attempt to save a user from accidentally incurring high data usage once they've already loaded the page with reduced data? Sounds good to me. |
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 this API, since you know the use cases of the API you are designing better. 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. |
I like the user focused intent of y'all's feedback. While it's new for a media query to guard like this, and the spec draft will need an update to reflect it, I do think this spec design detail is meaningful and not just implementation of feedback. Find the updated notes in the explainer here 👍🏻 |
@argyleink just to be clear, our feedback was a strawman to start a discussion, not a specific design proposal (and we're fairly certain it's not sufficient on its own). We want to be sure this issue gets proper discussion within your working group and the relevant factors get due consideration. Please let us know when you have a real design for this behavior we can review (also feel free to tag TAG members in to your discussions as appropriate if you need more feedback on our concerns). |
Working group issue was raised and comments led to a bit of prose added to the spec. The added note speaks to the User Agent's freedom to handle toggling cases with their own discretion, while also supplying 2 scenarios to help inform their implementation and user centered consideration. |
Braw mornin' TAG!
I'm requesting a TAG review of CSS
prefers-reduced-data
.This feature indicates explicit user opt-in for a reduced data experience that when communicated to origins allows them to deliver alternate content honoring such preference - e.g. smaller or no images, less/no web fonts, smaller video resources, alternate markup, etc.
Further details:
We'd prefer the TAG provide feedback as (please delete all but the desired option):
💬 leave review feedback as a comment in this issue and @-notify @argyleink and @yoavweiss
The text was updated successfully, but these errors were encountered: