W3C home > Mailing lists > Public > public-device-apis@w3.org > October 2017

[wake-lock] Candidate Rec blockers

From: Kostiainen, Anssi <anssi.kostiainen@intel.com>
Date: Wed, 18 Oct 2017 07:27:06 +0000
To: W3C Devices and Sensors WG <public-device-apis@w3.org>
Message-ID: <10BD2768-2685-4DD6-A0EE-799A47160CF3@intel.com>

At our latest teleconference, we charted a plan [1] to transition Wake Lock API [2] to Candidate Recommendation. 

Looking into this, I have identified two issues for which we need clarity on prior to asking for a transition to CR, in particular, with respect to the following transition requirement [3]:


* must document how adequate implementation experience will be demonstrated


The issues identified are the following:

* There are no web-platform-tests [4] for Wake Lock API. It is strongly recommended to ship at minimum a preliminary test suite along with a CR spec. Blink's tests could be potentially used as a starting point, but would need to be reworked to align with the latest spec.

* The only known implementation [5] is based on an earlier version of the specification. The specification was since reworked substantially and the implementation is no longer aligned. We'd need to demonstrate these changes are implementable, or that they will not cause difficulty of implementation.

We're looking for volunteers to help with the above-mentioned tasks to allow the Wake Lock API spec to advance to CR.


-Anssi (Device and Sensors Working Group Chair)

[1] https://www.w3.org/2017/10/05-dap-minutes.html#action03
[2] https://w3c.github.io/wake-lock/
[3] https://www.w3.org/2017/Process-20170301/#candidate-rec
[4] https://github.com/w3c/web-platform-tests/
[5] https://crbug.com/257511
Received on Wednesday, 18 October 2017 07:27:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:33:40 UTC