W3C home > Mailing lists > Public > public-device-apis@w3.org > May 2014

Re: Standby API Specification Proposal

From: Kostiainen, Anssi <anssi.kostiainen@intel.com>
Date: Mon, 19 May 2014 09:29:29 +0000
To: Dominique Hazael-Massieux <dom@w3.org>
CC: Dariel Marlow <dmarlow@gmail.com>, "<public-device-apis@w3.org>" <public-device-apis@w3.org>
Message-ID: <5376AF90-13C6-4638-9D1C-433BF17069F8@intel.com>
Hi Dom, All,

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

[...]

> * 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.

There’s now (re)emerging interest in experimenting with such an API in Chrome the browser (not Chrome Apps):

https://code.google.com/p/chromium/issues/detail?id=372443
https://code.google.com/p/chromium/issues/detail?id=257511

> * 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

It seems neither of the above experimental APIs seem to address the Chrome's requirements, so yet another API may get implemented.

> 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.

Dom - I think there’s now sufficient interest for this feature to justify moving this into a W3C working group soon. This is a small addition considering the overhead of rechartering a group, but OTOH it would be pity to leave this feature stranded due to that.

Thanks,

-Anssi
Received on Monday, 19 May 2014 09:30:10 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:03 UTC