- From: Mounir Lamouri via GitHub <sysbot+gh@w3.org>
- Date: Sun, 25 Nov 2018 01:08:47 +0000
- To: public-device-apis-log@w3.org
> I have to agree with everything @HenrikJoreteg said. The only [use case](https://w3c-webmob.github.io/wake-lock-use-cases/) we have identified is "wake lock" (cooking a recipe, reading a book), and _optionally_ and _temporarily_ requesting full brightness (e.g., Starbucks, Eventbrite, and airline apps) ... we might not even need the timeout, it could just disable when the user performs and action such as turns off the screen, switches tabs, etc. Designed an API only based on use cases and not trying to expand from them seems dangerous and may end up with design flaws. Offering a larger ability will trigger new use cases we did not think of. One issue that may happen in the future is that full brightness will end up way too bright on some phones. With HDR getting more popular, display brightness will increase and we could end up in a situation where full brightness will simply be way too bright in some cases. Also, brightness changes on mobile OSes, as far as I can tell, are specific to the application (Activity, on Android, I believe). Similarly, brightness changes should only apply to the tab, ideally in fullscreen even. I wouldn't worry much about applications trying to change the brightness as they wouldn't have an effect unless they are visible and the UA could put min values to make sure they don't attempt to keep the screen black. -- GitHub Notification of comment by mounirlamouri Please view or discuss this issue at https://github.com/w3c/wake-lock/issues/129#issuecomment-441407574 using your GitHub account
Received on Sunday, 25 November 2018 01:08:48 UTC