See also: IRC log
https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit#
[hr-time] unload test > Todd will followup w/ Dale
we can publish CR once that lands
[beacon] CORS tests are blocking
Todd: I'll check-in with Brandon, we should have those tests
https://github.com/w3c/beacon/issues/41#issuecomment-322365422
[user-timing] https://github.com/w3c/user-timing/issues/20
Todd will check-in on status
one resource per entry test: https://github.com/w3c/web-platform-tests/pull/6567
yoav: feedback makes sense, we should accumulate the entries, I'll update the test
Device Memory: propose to adopt officially into WG charter
Yoav/Todd: sgtm.
@yoav @xiaoqian will coordinate the move.
Paint Timing: proposal to adopt into WG
shubhie: shipped in Chrome, has TAG approval.
Todd: LGTM
Yoav: will coordinate the transfer
Tim: event timing proposal
https://docs.google.com/presentation/d/1tp3VzgekEfEvymx7eG3ABDoocOZUE7ZsHR3fB44y088/edit
Tim: ^ motivation
... why not long tasks? LT does not associate al the different
top-level-tasks that contribute to a long input event -->
goal: this input event caused a long frame
... for every DOM event: report handler duration, and if we
"drew", time until draw
... "drew" is step 4.3 of event loop: "if necessary update the
rendering of document..."
... if it was necessary use the timestamp when update ran, if
not do not provide
... show eventTimestamp and when processing starts and ends
(e.g. if event processing was blocked)
... we can polyfill much of this, but performance overhead is
prohibitive; had to monkey patch addEventListener
Todd: at first glance, this looks
good; some of field names need a more developer friendly
name
... also worried about linking to rendering but not accounting
for off-thread work -- e.g. compositing time, etc.
... a lot of partners I see today, are using raF based
polyfills
... let's say we have this and Long Tasks, are we missing
anything?
Tim: frame display time,
probably...
... perhaps more associated event data
Shubhie: we still need slow frames API
Todd: right, we need to find the
right balance on that API; we can't / shouldn't report every
frame
... event duration signals that something got in the way of
paint; Long tasks / long frame help explain what happened
... I like the overall idea and direction here, need to iterate
on naming and developer ergonomics
Shubhie: what about mitigations for rendering?
Tim: ... we expose if step 4.3
was executed
... one possibility is to run 4.3 whenever you hover, not sure
if it provides full coverage
Yoav: how does an analytics provider register for this?
Tim: you register for all events (e.g. type => "event")
Yoav: sgtm
Ilya: do we need to have a conditial 4.3?
Tim: it may be hard to figure out
when to record that timestamp, but probably doable
... the question is whether we can "fake" it well enough
... I'll do some more thinking on if/how we can do this; the
idea is to always report 4.3 and make it indistinguishable
Yoav: what about changing :visited. Alex Russel had a proposal
AI's: iterate on developer ergonomics; investigate rendering steps
scribe: let's move to WICG to
enable feedback and comments
... timeline: prototype in ~Q4 in CHrome
Custom Events: https://docs.google.com/presentation/d/1vGE_6wWNBI7Mm4PHLry0L-Hmu4Mg3xco0vKsb0Zrsoc/edit
Tim: motivation ^
... right now developers are doing pretty gross things with
mark and measure -- e.g. encoding data into name string,
etc.
... arbitrary timestamps is another limitation of UT
... e.g. if you want to mark something retroactively, UT does
not support
... also, want to provide ability to provide custom data
... proposal: performance.queueEntry(...)
... we could probably extend UT mark or measure
... we could expose a constructor, but that's inconsistent with
mark/measure
... that said, we can make either of those work
... we can get pretty far with a polyfill, but the value here
is providing a shared interface for developers +
analytics
... there may be merit in providing filtering capabilities in
v2+, don't think this is strictly required in v1
Todd / Ilya: filtering is more of a generic PO function, let's separate that from this proposal
Shubhie: an explicit difference from mark and measure is that you have to provide timestamps
Todd: need to look at this some more; Nolan wanted arbitrary data and more; the downside is that it requires that you write more JS
Tim / Todd: mark and measure have some benefits, we should think about how much we can extend and improve them
scribe: Tim: we could probably easily build a shim to implement mark and measure on top of this
Todd: this looks great, just need
to iterate on shape and timeline
... if you can get this up on WICG, then we can start
iterating; I'm very supportive of this, because it provides
clear value to the web
AI: get the spec on WICG
... next call: Aug 30.
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/vs/or/ WARNING: No "Present: ... " found! You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy <amy> Present+ No ScribeNick specified. Guessing ScribeNick: igrigorik Inferring Scribes: igrigorik WARNING: No "Topic:" lines found. WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Got date from IRC log name: 16 Aug 2017 Guessing minutes URL: http://www.w3.org/2017/08/16-webperf-minutes.html People with action items: WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report[End of scribe.perl diagnostic output]