[![W3C][1]][2] # Device and Sensors Working Group Teleconference ## 16 Jun 2016 [Agenda][3] See also: [IRC log][4] ## Attendees Present Frederick_Hirsch, Dom, Andrey_Logvinov, Anssi_Kostiainen Regrets Chair Frederick_Hirsch Scribe dom ## Contents * [Topics][5] 1. [Welcome, scribe selection, agenda review, announcements][6] 2. [Minutes approval][7] 3. [Battery][8] 4. [HTML Media Capture Update][9] 5. [Vibration PER][10] 6. [Sensor][11] 7. [Wake Lock API][12] 8. [Other Business][13] 9. [Adjourn][14] * [Summary of Action Items][15] * [Summary of Resolutions][16] * * * ### Welcome, scribe selection, agenda review, announcements ScribeNick: dom TPAC 2016 registration - [https://lists.w3.org/Archives/Public/public- device-apis/2016Jun/0043.html][17] FJH: reminder of TPAC registration; not sure I'll be able to make it myself ... We had an updated WD of wake lock WakeLock API published as WD [https://lists.w3.org/Archives/Public /public-device-apis/2016Jun/0010.html][18] ### Minutes approval **RESOLUTION: Minutes from 2 June 2016 are approved [http://www.w3.org/2016/06/02-dap-minutes][19]** +1 to approve ### Battery updated tests [https://lists.w3.org/Archives/Public/public-device- apis/2016Jun/0040.html][20] FJH: what's the status on battery? Anssi: Firefox was failing a couple of tests; we thought the problem was in Firefox, but it turned out that our test case was wrong ... (Chrome was thus wrong) ... we've updated the test case and the test results ... and we can conclude the failure is not related to the battery API, but a broader issue with Chrome ... so I don't think it should block dom: Boris is still commenting that test case has issue due to race condition dom: where is the implementation report? anssik: new person taking on work, so need to follow up **ACTION:** anssik to get new updated test report [recorded in [http://www.w3.org/2016/06/16-dap-minutes.html#action01]][21] Created ACTION-762 - Get new updated test report [on Anssi Kostiainen - due 2016-06-23]. [https://lists.w3.org/Archives/Public/public-device- apis/2016Jun/0040.html][20] Dom: once I have the updated report, I'll proceed with the next step for the Battery API Proposed Rec anssik: latest test report update is 13 May [https://github.com/w3c/test- results/commit/c3e7c6e24c1f4783f66bfdd2c1fbe849fc4c5d61][22] anssik: so we have confirmed, test report needs an update FJH: what will be needed from me for this? Dom: not sure yet ### HTML Media Capture Update [https://lists.w3.org/Archives/Public/public-device- apis/2016Jun/0036.html][23] -> [https://lists.w3.org/Archives/Public/public-device- apis/2016Jun/0036.html][23] Anssi's update on implementations of HTML Media Capture Anssi: we don't have a second implementation (at least not a widely shipping one) ... so we basically need to keep monitoring Frederick: we have an open candidate rec with a call for implementation, so let's wait until we get the required level of implementation Anssi: there was some interest from Ted@Apple? to add new feature to this spec ... although that discussion kind of died out ... maybe this will find more implementation and we can move forward Frederick: we'll review this on a regular basis (e.g. every 6 months) ... but I don't think there is any harm in keeping this open ### Vibration PER dom: talked with Phillippe Le Hegaret, plan to have revision of Page Visibility, couple of weeks dom: need to decide what to do dom: in favor of waiting for a few weeks fjh: will they be doing PER dom: no, they want to make substantive changes as well, so that'll need a full rec-track cycle dom: no, need to go through REC track starting at FPWD, but FPWD might be enough for us dom: but referring to FPWD would likely be acceptable in this case [https://github.com/w3c/vibration/issues/7][24] dom: ok to fix this general agreement on call to go with approach of watiing for FPWD related to Page VIsibility, not removing this, and going forward with PER, relying on Philliipe’s judgement on risk (which we agree with) dom: will provide pull request [https://github.com/w3c/vibration/issues/10][25] anssi: andrey suggested requiring permission for vibration in a new issue dom: wif we did this would not have implementations, would prefer to defer and and do PER, save for v2 anssi: obviously this isn't what existing implementations do, so would require a substantive change (not PER compatible) Andrey_Logvinov: agree anssi: so it sounds like more a v2 suggestion +1 to PER without this, and then v2 makes sense to align with current implementations fjh: makes sense to me as well anssi: I'll tag it with v2 fjh: add a comment too anssi: done ### Sensor fjh: So Tobie is taking up another spec Anssi: yes, WebIDL fjh: who can take over his work? Anssi: I can contribute, and we have 2 new intel contributors from the Chromium implementation side ... Our plan is to upstream the implementation and give feedback to the group based on that ... and update the spec based on clarifications that emerge ... there will be feedback coming in very soon, based on issues already identified in their implementation work dom, you wanted to ask about wide review dom: should we start the wide review process without tobie around? anssi: I don't feel pressed to start it right now; the feedback we'll get will be in the order of clarifications if we are getting feedback from Intel contributors we should probably incorporate that first anssi: When we get to CR we need to satisfy having completed wide review fjh: it seem more logical to see feedback integrated first before starting first review ... esp if it's in the short term anssi: sounds reasonable ... the idea is to make sure the spec reflects the implementation, that is both precise and reflects reality ... so it would make better use of reviewers time ... I think we should aim at initiating wide review ahead of TPAC dom: main issue is that TPAC is in September, which follows August that is always quiet ... maybe we could start end of August? Frederick: I was thinking earlier, in July Dom: sounds even better to me if that's compatible with Anssi's timeline Anssi: we already got a review from the TAG ... not sure the horizontal groups need the fine tuning to make useful reviews Dom: agreed re other horizontal groups ... TAG would probably benefit from seeing the latest refinements Anssi: so we can stage the reviews Frederick: I'm not sure we need staging if a final doc is only a couple of weeks away Dom: I guess it depends on the timeframe of getting these refinements in, and how confident we are of this timeframe frederick: can you ask estimates from your colleagues Anssi? Anssi: they'll raise issues as they implement; I'll ask for an estimate Frederick: let's plan for generic wide review first week of July ... if we're not ready for general wide review, we can start a staged review then lets try to have wide review early july, incorporating changes, then stage as needed note that Dom and Anssi will not be available mid July until end August ### Wake Lock API [https://github.com/w3c/wake-lock/issues/64][26] Andrey: still one open issue about restricting wake lock requests to top level origin [https://github.com/w3c/wake-lock/issues/51][27] Andrey: I have created a PR to address it ... not sure how this works with permissions ... inheritance ... In Chromium, there is a proposal that the top level browsing context need to delegate permissions explicitly Frederick: it sounds that permissions is a work in progress that is being developed ... while same origin is already available today ... is that correct? Andrey: if so, maybe we should merge the PR Dom: I think we should merge the PR and ask specific feedback from WebAppSec in our wide review Frederick: yes; we should add a note to call attention on the discussion on permission Andrey: OK, will create another PR with that note then dom: once that done, we should start the wide review process as previously discussed? Frederick: yes ### Other Business fjh: we should look at our schedules, possible cancel meetings in July/August, given a number of people are on summer holiday. fjh: I have conflict 28 July fjh: also have conflict 30 June, can you chair Dom? dom: yes ### Adjourn ## Summary of Action Items **[NEW]** **ACTION:** anssik to get new updated test report [recorded in [http://www.w3.org/2016/06/16-dap-minutes.html#action01][28]] ## Summary of Resolutions 1. [Minutes from 2 June 2016 are approved http://www.w3.org/2016/06/02-dap- minutes][29] [End of minutes] * * * Minutes formatted by David Booth's [scribe.perl][30] version 1.144 ([CVS log][31]) $Date: 2015/11/17 08:39:34 $ [1]: https://www.w3.org/Icons/w3c_home [2]: http://www.w3.org/ [3]: https://lists.w3.org/Archives/Public/public-device- apis/2016Jun/0044.html [4]: http://www.w3.org/2016/06/16-dap-irc [5]: #agenda [6]: #item01 [7]: #item02 [8]: #item03 [9]: #item04 [10]: #item05 [11]: #item06 [12]: #item07 [13]: #item08 [14]: #item09 [15]: #ActionSummary [16]: #ResolutionSummary [17]: https://lists.w3.org/Archives/Public/public-device- apis/2016Jun/0043.html [18]: https://lists.w3.org/Archives/Public/public-device- apis/2016Jun/0010.html [19]: http://www.w3.org/2016/06/02-dap-minutes [20]: https://lists.w3.org/Archives/Public/public-device- apis/2016Jun/0040.html [21]: http://www.w3.org/2016/06/16-dap-minutes.html#action01] [22]: https://github.com/w3c/test- results/commit/c3e7c6e24c1f4783f66bfdd2c1fbe849fc4c5d61 [23]: https://lists.w3.org/Archives/Public/public-device- apis/2016Jun/0036.html [24]: https://github.com/w3c/vibration/issues/7 [25]: https://github.com/w3c/vibration/issues/10 [26]: https://github.com/w3c/wake-lock/issues/64 [27]: https://github.com/w3c/wake-lock/issues/51 [28]: http://www.w3.org/2016/06/16-dap-minutes.html#action01 [29]: #resolution01 [30]: http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm [31]: http://dev.w3.org/cvsweb/2002/scribe/