Skip to content
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

Should this be an HTTP header & CSS media feature combo? #2

Open
tomayac opened this issue Aug 7, 2020 · 4 comments
Open

Should this be an HTTP header & CSS media feature combo? #2

tomayac opened this issue Aug 7, 2020 · 4 comments

Comments

@tomayac
Copy link

tomayac commented Aug 7, 2020

We have a combo of a Save-Data HTTP header and a prefers-reduced-data CSS media feature (which, like all media features, is queryable from the page with window.matchMedia()).

Should this be similar? Also see w3c/das-charter#98 (comment), where I have proposed Save-Energy and prefers-reduced-energy.

@jpchase
Copy link

jpchase commented Aug 12, 2020

Another option would be using Document Policy, instead of a custom header.

This example:

<meta name="battery-savings" content="allow-reduced-framerate allow-reduced-script-speed">

Could become something like:

Document-Policy:  battery-savings=allow-reduced-framerate;allow-reduced-script-speed

That could avoid needing to define a new syntax/configuration mechanism. Document Policy currently only supports a HTTP header, not tag. The topic of configuring via markup, e.g. tags, has been discussed in the past for Document Policy.

Are there use cases that wouldn't work with an HTTP header?

@clelland

@chrishtr
Copy link
Owner

A problem with these alternatives is that there should be a way for the site to dynamically change its desired battery behavior. I think these don't allow dynamism right now.

@tomayac
Copy link
Author

tomayac commented Aug 17, 2020

A problem with these alternatives is that there should be a way for the site to dynamically change its desired battery behavior. I think these don't allow dynamism right now.

I think the premise is the reverse: the user communicating to the site (by the user or the OS activating battery safer mode) to consume less energy. Currently, it's formulated the other way round. Just like with dark mode toggles, there could still be an override (like opting in to the high-energy, but higher quality video codec).

@khushalsagar
Copy link

One of the motivation behind the current proposal being declarative hints from the site to the UA, instead of the user intent being directly communicated to the site (possibly through an event) is to enable mitigations that are not easy to do for the site. Reducing rendering overhead deeper in the stack or modifying CPU scheduling of script work as an example.

For opt-in vs opt-out, we can have both kind of options through the meta-tag. Depending on how aggressively the mitigation could hinder site performance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants