khusha...@chromium.org, chri...@chromium.org
https://github.com/chrishtr/battery-savings/blob/master/explainer.md
https://github.com/chrishtr/battery-savings/blob/master/explainer.md
There is no TAG review yet because we're still exploring the space and want to gather real-world data to justify APIs.
Adds a meta tag allowing a site to recommend measures for the user agent to apply in order to save battery life and optimize CPU usage. The mitigation targeted for this experiment is reducing the rendering frame rate.
https://groups.google.com/a/chromium.org/g/blink-dev/c/PQ9aDeWGUE0/m/qf07C9FDAgAJ
User agent measures to save battery and CPU may vary by agent, since this API is a hint rather than a description of an exact policy.
Gecko: No signal
WebKit: No signal
Web developers: Positive. Pre-prototype testing in the lab yielded positive results for video-heavy sites.
It should be very easy to adopt.
It should be very easy to adopt.
None
This origin trial will allow the site to opt-in to the "allow-reduced-framerate" mitigation, enabled based on browser heuristics. We will be partnering with developers (like Google Meet) who can run field trials and collect A/B data on the real-world impact on overall CPU utilization from the feature. These results will inform future spec discussions.
M86-M87
NA
None
Currently implemented on desktop only but can be supported for Android as well.
No None as yet
--
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/CAMLuWUx%3DCsCQdSMKeb30aPLNr0MKLL_BX2mf_BoQQJ3tY8VPkw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2B-LeH_CTVcukyFhXFW9CsPBifNFzMaTratHPP1pbQAQscwdBA%40mail.gmail.com.
LGTM to experiment.That said:1. I agree with Mounir's suggestion that asking the TAG for input would be excellent.
2. I would encourage y'all to evaluate alternatives to the `<meta>` delivery mechanism. Did you consider an imperative API, for instance? That avoids questions about the processing model for `<meta>` (changes to the attribute value, insertion of new tags, `<head>` vs `<body>`, etc), and seems simpler to explain.
3. What is the inheritance story? Is there an interaction with Document Policy/Feature Policy that could require embedded frames to respect the same policy as the embedder?
Thanks Mike and Mounir!On Thu, Aug 13, 2020 at 2:00 AM Mike West <mk...@chromium.org> wrote:LGTM to experiment.That said:1. I agree with Mounir's suggestion that asking the TAG for input would be excellent.I have filed a request for an early design TAG review here.2. I would encourage y'all to evaluate alternatives to the `<meta>` delivery mechanism. Did you consider an imperative API, for instance? That avoids questions about the processing model for `<meta>` (changes to the attribute value, insertion of new tags, `<head>` vs `<body>`, etc), and seems simpler to explain.My knowledge of the potential API surfaces here and associated implications is limited, I think chrishtr@ would be able to answer this better.3. What is the inheritance story? Is there an interaction with Document Policy/Feature Policy that could require embedded frames to respect the same policy as the embedder?I can't speak for interaction with Document Policy/Feature Policy but the general principle of whether the settings should apply to embedded frames is interesting. This hasn't come up in the use-cases we've considered so far but I expect we'll have more concrete thoughts on this as we explore more use-cases.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUzk%2BrkuhUCgqVTqhuv%2B%3DfzNPKk24H1XULTL%2B1Mse68m3w%40mail.gmail.com.
Part of this calculation will need to be the question "how important is it that subframes can't override their parent frame's setting?" If the answer is "not at all", then Document Policy could be a good fit for this API, as pages can generally set their policies independently of each other. If it is critical that a page with battery-saving mode enabled not have that setting reversed in any embedded content, then we could use Permissions Policy, declaring "can-use-excessive-battery" as a powerful feature, and granting that to all sites by default.I'm happy to discuss the different options if you want, on this thread, or in GitHub issues, or whatever makes the most sense.