Re: Standby API Specification Proposal

On 05 Feb 2014, at 12:52, Dominique Hazael-Massieux <dom@w3.org> wrote:

> Hello Dariel,
> 
> On mar., 2014-02-04 at 08:56 -0800, Dariel Marlow wrote:
>> Hello Device APIs working group. I wish to propose a way for web
>> applications to interact with device standby behavior. The app may
>> request that the device not enter standby should the user not provide
>> input via touch or peripherals. Hopefully I’ve provided the document
>> in an appropriate format. If not, or if this is the wrong working
>> group, please advise.

[...]

> * To justify the cost of going through this, we would want to get some
> clear interest from others, in particular browser vendors, that they do
> want to implement such an API.
> 
> Now, for some good news:
> * your document include use cases which seem pretty reasonable and that
> I can guess others would find interesting as well

The use cases and requirements described seem to be addressed on the native side of things on major mobile platforms and similar APIs are used widely e.g. by games (I have no data though to support my hunch). So this would be bridging the gap, if this type of functionality is a good fit for the Web, that is.

Looking this from another angle: do we have a reasonable use case for a web app be able to explicitly inform the UA that it *is fine* to optimize resource consumption? Currently, the visibility state of the page is the only hint exposed to the web content, and it cannot be programmatically altered naturally.

Browsers use various heuristics to identify inactivity (e.g. visibility state), but these heuristics do not always work, and the web app may want to explicitly let the UA know it is not doing anything performance critical.

> * Firefox OS ships an API with similar goals, navigator.requestWakeLock:
> https://developer.mozilla.org/en-US/docs/Web/API/Navigator.requestWakeLock
> 
> * likewise, Chrome Apps have a requestKeepAwake API available to them:
> https://developer.chrome.com/extensions/power.html
> 
> So there are clear precedents in this space, and maybe this thread can
> serve to gather confirmations that browser vendors would be interested
> on this; I'll try to gather feedback on this in other avenues, and
> hopefully you could as well try and get such feedback.
> 
> Now, on your specific proposed API, there are probably a number of
> changes that would be required to make it more Web-idiomatic; and given
> that there are other APIs out there, it might be that we would start
> from one of them rather than this specific approach.

Just an idea, this could be tied to the Fullscreen API. That is, a user could request a page to be fullscreen and "always on”. We could reuse the permission model.

> Hopefully this clarifies how we would go about such a proposal, as well
> as how you could help in making it happen. 
> 
> Let me know if you have any question on this.

Thanks,

-Anssi

Received on Wednesday, 5 February 2014 11:59:31 UTC