yoav: TPAC, we're meeting thursday and friday
... do we want to follow similar setup as last TPAC, with separation for design vs triage days?
todd: sg, main hurdle is scheduling vs other groups
who's coming? Philip, Charles, Nic, Nicolas, Todd, Yoav
<scribe> ACTION: chairs to start planning doc for TPAC: who's coming, agenda ideas
Charlie: Distributed Tracing group contacted us way back
<scribe> ACTION: Yoav to followup with DT group
next design call: Sept 6th @ 11AM PST
<yoav> https://github.com/w3c/page-visibility/pull/38
<scribe> ACTION: Yoav & Todd to review ^
hidden when fully obscured: https://github.com/w3c/page-visibility/pull/38
<scribe> ACTION: Todd to review tomorrow PV pull 38
Next: support waitUntil semantics in pagevisibility?
Philip: we can close it,
Yoav: sgtm, no further action needed
<yoav_> https://github.com/w3c/page-visibility/issues/40
Next: Provide a clear way to hook into "document becomes visible/hidden"
https://github.com/w3c/page-visibility/issues/40
yoav: it's an editorial issue, unclear if there are upstream use cases
todd: none of the currently open issues block us from CR
... re #34, I propose we move that to L3 because we don't have an implementation that conforms to this
ig: sgtm
<yoav_> https://github.com/w3c/page-visibility/issues/39
Philip: the order is defined in HTML spec
meta: should Pagelifecyle API assume L3 features?
todd: we should complete L2 PV;
yoav: ditto
... for L3 we should chat w/ Page Lifecycle editors on mering
ryosuke: Safari does implement #34 when fully obscured
todd: what do we need to clear up in L2
... current language does not talk about obscured use case
... the problem with current language is that it's a must
... it's easy to fix, I'll tackle it tomorrow
Hooks (#40): let's investigate for L2
todd: I'll take a run at this one
Re, https://github.com/w3c/page-visibility/issues/39:
todd: this is not in PV, we should move this to HTML repo
philip: yes, will do
<yoav_> https://github.com/w3c/resource-timing/issues/70
ig: if Todd resolves the two issues, we should be able to republish PV
yoav: URL is currently resolved in SW
... s/resolved/exposed
... what is our stance on this wrt exposing timing information?
... SW today gets the fetch event for the resource, which allows it to observe start and end
rniwa: given TAO, this seems fine
Yoav: I'll followup on the issue; I need to check-in w/ current plans Mozilla has here
... I'll summarize the discussion here on the thread
<yoav_> https://github.com/w3c/resource-timing/issues/82
<yoav_> https://github.com/w3c/resource-timing/issues/141
yoav: rniwa objected to current language for synchronous event for bufferfull
... in Safari it's fired asynchronously; the implementation is: when RT buffer is full, we schedule an event to fire, in the meantime we buffer new events into secondary buffer. when event does fire, we iterate through secondary buffer to append if there's new space
rniwa@: ^ correct
npm/yoav: this behavior does not affect PO
yoav: this behavior makes sense, I'd like to investigate integrating it into the spec if there's support from other vendors
nic: afaik, RT is the only place with buffering logic
todd: we haven't implemented onresourcebufferfull in Edge; we just raised our limit to 500
... we don't have a strong opinion on this one
<scribe> ACTION: Yoav to propose draft language, so we can sanity check w/ implementers
<yoav_> https://github.com/w3c/resource-timing/issues/96
yoav: this is a bug in processing model
rniwa: this behavior is what triggered the issues above
todd/yoav: we can resolve this in same patch
--- thanks all! ---