See also: IRC log
shubhie: we want to ship v1 in M57 (early Jan)
_ one change we made is reporting a list of iframe attributes: name, id, source
_ security review: iterating on feedback, still an open discussion
_ attribution: plan is to show long scripts URLs
_ next steps: we'll update the explainer next week, ptal.
_ implementation: partial implementation in Canary behind experimental flag -- give it a try.
yoav: where are we with the spec?
shubhie: yeah, we'll work on
expanding on explainer to cover processing / security,
etc.
... AI: everyone to review explainer, we'll discuss how and
where to expand on next call
Todd: there are lots of scenarios where main thread can cause compositor to run slower -- e.g. combination of webgl/canvas/svg bogs down; or an image decode appears to be done on main thread, but image shows up way later
Shubhie: do we have a sense for how common that is?
Todd: this is probably the long
tail..
... we should probably think about this entire process as a two
phase process: main thread > compositor
_ this is implementation specific, but at the same time, this is a common pattern for most browsers
yoav: what's the point of providing both.. the developer only cares about the longer time?
Todd/Shubhie: having two provides a good hint for where the problem may be
AI: let's document alternative models on GitHub and iterate there
Yoav: we need to start a thread WICG thread and we can transfer the repo
https://github.com/w3c/resource-timing/pull/80
https://github.com/w3c/resource-timing/pull/81
AI: Todd will review
https://github.com/w3c/resource-timing/pull/79
Todd: agree that we can't specify a MUST because we have different implementations; we can add a note in the spec, as in PR
_ there is a separate issue: we should gather some telemetry.. how often is this used? if we find that everyone relies on this, then perhaps we ought go back and change to MUST
igrigorik: we should also write some tests to figure out interop between existing implementations
AI: update note with a disclaimer, and in parallel we should open an issue to investigate current implementations and use in the wild
https://github.com/w3c/resource-timing/issues/63
Todd: if we want to make a difference between first byte vs header complete vs ... those should be different attributes
_ if we want to break apart first byte, we're better of with different measurements
AI: update to align with receipt
of first byte by the HTTP parser
... NT2 ...
Todd: it's helpful to be able to tell the tests apart; having a prefix would be helpful
plh: we're ok with the idea, but we do have tests that apply to both
_ it's ok to have tests that don't have a version number
Shubhie: do we duplicate tests?
Todd: implementations that don't have NT1 would want those
https://github.com/w3c/navigation-timing/pull/52
scribe: we'll merge the extended
diagram, as we want to optimize for those reading the
spec
... and, looks like Todd beat us to the punch :)
thanks all!
This is scribe.perl Revision: 1.148 of Date: 2016/10/11 12:55:14 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) No ScribeNick specified. Guessing ScribeNick: igrigorik Inferring Scribes: igrigorik WARNING: No "Topic:" lines found. Present: igrigorik Todd Shubhie plh NicJansma yoav xiaoqian 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: 30 Nov 2016 Guessing minutes URL: http://www.w3.org/2016/11/30-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]