See also: IRC log
<scribe> ScribeNick: dom
<fjh> TPAC 2016 registration - https://lists.w3.org/Archives/Public/public-device-apis/2016Jun/0043.html
FJH: reminder of TPAC registration; not sure I'll be able to make it myself
... We had an updated WD of wake lock
<fjh> WakeLock API published as WD https://lists.w3.org/Archives/Public/public-device-apis/2016Jun/0010.html
RESOLUTION: Minutes from 2 June 2016 are approved http://www.w3.org/2016/06/02-dap-minutes
<anssik> +1 to approve
<fjh> updated tests https://lists.w3.org/Archives/Public/public-device-apis/2016Jun/0040.html
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
<fjh> dom: Boris is still commenting that test case has issue due to race condition
<fjh> dom: where is the implementation report?
<fjh> anssik: new person taking on work, so need to follow up
<fjh> ACTION: anssik to get new updated test report [recorded in http://www.w3.org/2016/06/16-dap-minutes.html#action01]
<trackbot> Created ACTION-762 - Get new updated test report [on Anssi Kostiainen - due 2016-06-23].
<fjh> https://lists.w3.org/Archives/Public/public-device-apis/2016Jun/0040.html
Dom: once I have the updated report, I'll proceed with the next step for the Battery API Proposed Rec
<fjh> anssik: latest test report update is 13 May
<anssik> https://github.com/w3c/test-results/commit/c3e7c6e24c1f4783f66bfdd2c1fbe849fc4c5d61
<fjh> anssik: so we have confirmed, test report needs an update
FJH: what will be needed from me for this?
Dom: not sure yet
<fjh> https://lists.w3.org/Archives/Public/public-device-apis/2016Jun/0036.html
-> https://lists.w3.org/Archives/Public/public-device-apis/2016Jun/0036.html 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
<fjh> dom: talked with Phillippe Le Hegaret, plan to have revision of Page Visibility, couple of weeks
<fjh> dom: need to decide what to do
<fjh> dom: in favor of waiting for a few weeks
<fjh> 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
<fjh> 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
<anssik> https://github.com/w3c/vibration/issues/7
<fjh> dom: ok to fix this
<fjh> 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)
<fjh> dom: will provide pull request
<anssik> https://github.com/w3c/vibration/issues/10
anssi: andrey suggested requiring permission for vibration in a new issue
<fjh> 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)
<fjh> Andrey_Logvinov: agree
anssi: so it sounds like more a v2 suggestion
<fjh> +1 to PER without this, and then v2
<fjh> 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
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
<Zakim> 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
<fjh> 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
<fjh> lets try to have wide review early july, incorporating changes, then stage as needed
<fjh> note that Dom and Anssi will not be available mid July until end August
<Andrey_Logvinov> https://github.com/w3c/wake-lock/issues/64
Andrey: still one open issue about restricting wake lock requests to top level origin
<Andrey_Logvinov> https://github.com/w3c/wake-lock/issues/51
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
<fjh> fjh: we should look at our schedules, possible cancel meetings in July/August, given a number of people are on summer holiday.
<fjh> fjh: I have conflict 28 July
<fjh> fjh: also have conflict 30 June, can you chair Dom?
<fjh> dom: yes