Hi Ryosuke, all,

I'm still soliciting a feedback.

Thanks!

For now, I can say we're very much concerned about any impact on battery life since that's no.1 thing our users care about. Since even a few percentage point of battery life regression would be a major concern, there needs to be extraordinarily good reasons to add this API;

As pointed out earlier, there is a workaround of playing an invisible video to keep the screen awake, and people are (ab)using it: https://github.com/mozilla/standards-positions/issues/210#issuecomment-576203235.

This proposed API could be a proper way of having this feature, allowing user agents to display appropriate indications (see https://blog.tomayac.com/2018/12/18/experimenting-with-the-wake-lock-api/#closing-thoughts for my ideas).

Since the screen is visibly on, the impact on battery life is very tangible; since there's no hidden background activity or anything that an app couldn't do anyways. Actually, iOS has started to show (add to home screen) Web.app activity in the Battery stats, so users can even trace battery consumption back to web apps.

I just don't think any of the use cases listed in https://w3c.github.io/wake-lock/#introduction are compelling enough to meet such a standard.

Looking at the _screen_ wake lock use cases:

* Use turn-by-turn navigation while walking and driving and not interacting with the phone.

Apple/Google Maps do that and need that on native. Both web apps could use this as well (Apple Maps is available on the web https://goo.gle/apple-hq-on-apple-maps, navigation isn't, but here's a navigation link for Google Maps: https://goo.gle/old-apple-to-apple-park-google-maps ).

* Allow an external device to read a boarding card with a barcode on a phone.

Starbucks have publicly requested this feature (combined with the capability to boost the screen brightness to the maximum brightness: https://github.com/w3c/wake-lock/issues/129#issuecomment-439713499). Their PWA is used by many of their customers.