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

[minutes] June 15 teleconference

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Thu, 15 Jun 2017 16:55:22 +0200
To: W3C Device APIs WG <public-device-apis@w3.org>
Message-ID: <d3e32691-a546-ca44-0f62-26c9be36e833@w3.org>

The draft minutes of our teleconference are available at:

and copied as text below.


                               - DRAFT -

            Device and Sensors Working Group Teleconference

15 Jun 2017



   See also: [3]IRC log

      [3] http://www.w3.org/2017/06/15-dap-irc


          Alexander_Shalamov, Wanming_Lin, Dom, Anssi, Kenneth,



          anssik, dom


     * [4]Topics
         1. [5]Minutes approval
         2. [6]HTML Media Capture
         3. [7]Sensors API
         4. [8]Wake lock
         5. [9]Battery Status API
         6. [10]Rechartering
         7. [11]Other Business
     * [12]Summary of Action Items
     * [13]Summary of Resolutions

   <kenneth_> +Present KennethRohdeChristiansen

Minutes approval

   <dom> ScribeNick: anssik

   <dom> Proposed RESOLUTION: Minutes from 18 May 2017 are


   proposed RESOLUTION: Minutes from 18 May 2017 are approved

   RESOLUTION: Minutes from 18 May 2017 are approved

HTML Media Capture

   dom: checking if we can go to PR next month
   ... is that correct?


     [15] http://w3c.github.io/test-results/html-media-capture/20170428.html

   <dom> [16]HTML Media Capture Test Results

     [16] http://w3c.github.io/test-results/html-media-capture/20170428.html

   dom: the 1 failing test case could be not applicable as well
   ... have to wait for couple of weeks before entering PR

Sensors API

   dom: what is our vision to bring the work to CR?
   ... what needs to be update re wide reviews

   <inserted> ScribeNick: dom

   anssik: we want to get closure on open pull requests
   ... then we should triage open issues
   ... I would like to have level 1 issues marking what we want to
   get in our CR
   ... the rest would be for later versions
   ... goal is to go to CR this year
   ... [this is for generic sensor, but we would also want to go
   to CR with some of the most-baked concrete sensors]

   <anssik> dom: what's your feeling on the actual timeline?

   anssik: timeline will depend on editorship situation
   ... assuming dedicated full time editorship, this would need
   addressing level 1 issues (~30)

   kenneth: there is also the F2F to take into account in the
   ... it helps with getting a broad overview of the status

   alex: closing issues can be fast, but some of them have
   dependencies to other groups / specs

   anssik: plan is to have outside TPAC F2F; but we can still have
   an unofficial session at TPAC

   kenneth: but for coordination, TPAC remains nice even if DAS is
   not meeting formally

   <inserted> ScribeNick: dom

   anssik: chrome origin trial starting in the near future
   ... we would want to include that feedback in the spec prior to
   ... CR this year is optimistic - but that should be our target
   ... which means we should have a CR-worthy spec by the time of

   mikhail: it would be nice to align spec / implementation prior
   to origin trial

   <inserted> ScribeNick: anssik

   dom: the chair is looking at the editorship issue
   ... after that we can get clarify on the timeline

   <dom> ACTION: Alexander to take a stab a level-1 issue
   classification [recorded in

     [17] http://www.w3.org/2017/06/15-dap-minutes.html#action01

   <trackbot> Created ACTION-800 - Take a stab a level-1 issue
   classification [on Alexander Shalamov - due 2017-06-22].

Wake lock

   [the editor not on the call]

   dom: new activity, suggestions from Microsoft
   ... hoping to be able to take this to CR

Battery Status API

   dom: two things: new activity on issue #10
   ... and secondly, revised CR plan


     [18] https://github.com/w3c/battery/issues/10

   <dom> anssi: mounir noticed the security change in issue 10


     [19] https://github.com/w3c/battery/issues/5#issuecomment-257554180

   <dom> sounds like another case where we might want to rely on
   [20]https://wicg.github.io/feature-policy/ too

     [20] https://wicg.github.io/feature-policy/

   dom: perhaps iframed content that shares the origin with the
   top-level should not be restricted

   <dom> " The Battery API can be used by third party content for
   valid reasons."

     [21] https://github.com/w3c/battery/issues/10#issuecomment-308107841

   dom: do we want to reopen issue #10?
   ... or do research first?

   anssik: maybe reopening is the right thing to do
   ... just reopened [22]https://github.com/w3c/battery/issues/10

     [22] https://github.com/w3c/battery/issues/10

   dom: should be feedback from people who chimed in on issue #5

   <dom> dom: also, worth noting that mounir is pointing at
   real-world usage of the battery api for a/b testing - probably
   worth highlighting to get interest from more implementors


   dom: current charter expiring by the end of this year, assume
   we want to continue beyond this year to finish the current work
   and possibly adopt new work

   possible candidates for inclusion in this group:

   <dom> [23]https://www.w3.org/TR/orientation-event/


   * taking over device orientation v1?

   * geo v2?

   * webbluetooth?

   * webusb?

   * webnfc?

   dom: Geolocation WG closed, had Geolocation API and Device
   Orientation API in scope
   ... Device Orientation API was not finished, suggestion for DAS
   to take the spec to REC
   ... also Geolocation API "v2" a possibility, e.g. background
   ... WebBT, WebNFC, WebUSB also would be natural extensions to
   the DAS group

   <inserted> ScribeNick: dom

   anssi: DAS WG is probably the best fit for all of these work
   items in terms of scope
   ... Device Orientation would benefit from the sensor expertise
   of this group
   ... geo could remodeled after generic sensor
   ... the 3 incubation specs (bluetooth, nfc, usb) would benefit
   from more common interactions
   ... incl in F2F and/or calls
   ... they share a lot in common (e.g. permission model, API
   shape) - we could learn from each other
   ... WebBluetooth is enabled by default in Chrome
   ... WebUSB is in intent to ship


     [24] https://www.chromestatus.com/features/5651917954875392

   [25]WebNFC Chrome status

     [25] https://www.chromestatus.com/features/6261030015467520

   scribe: WebNFC will go to origin trial in the near future
   ... would be good to transition to WG
   ... adding these to this group would also help diversify
   participation which would be good

   <anssik> dom: that's the first level of support for extending
   the group

   <anssik> ... if we do this, we'd expect the CG participants
   from the related CGs to join this WG

   <anssik> ... will take this discussion to the list

Other Business

Summary of Action Items

   [NEW] ACTION: Alexander to take a stab a level-1 issue
   classification [recorded in

     [26] http://www.w3.org/2017/06/15-dap-minutes.html#action01

Summary of Resolutions

    1. [27]Minutes from 18 May 2017 are approved
Received on Thursday, 15 June 2017 14:55:31 UTC

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