[minutes] 2012-06-27 Web Performance WG Teleconference #77

Meeting Summary:



1.       Navigation Timing

The action item here was to follow up and close on the clarifications raised on the Navigation Timing spec. Jatinder to follow up.



2.       Performance Timeline

As there was no additional feedback from the Last Call period and this spec has been stable for some time, the working group has agreed to move this spec to CR.



3.       Resource Timing

All feedback issues raised on this spec have been resolved.



4.       User Timing

The spec has been updated based on all Last Call feedback. Currently, there are no outstanding spec issues remaining.



5.       Page Visibility

Jatinder is working on updating the spec to resolve ISSUE-8.



6.       High Resolution Time

There are currently no active open issues.


Detailed Notes:



Web Perf Teleconference #77 6/27/2012



IRC log: http://www.w3.org/2012/06/27-webperf-irc



Meeting Minutes: http://www.w3.org/2012/06/27-webperf-minutes.html



Attendees

Present for Navigation Timing, Resource Timing and User Timing (4-5PM EST/1-2PM PST)

Jatinder Mann, Philippe Le Hegaret, James Simonsen


Present for Page Visibility, Efficient Script Yielding, Display Paint Notifications (4-5PM EST/2-3PM PST)

Meeting cancelled.



Scribe

Jatinder Mann



Contents

Agenda

1.       Update on all specifications



--------------------------------------------------------------------------------
Navigation Timing

Jatinder: One issue raised on the mailing list was whether dynamic markup insertion should impact navigation timing attributes.

<plh> http://w3c-test.org/webperf/tests/submission/W3C/NavigationTiming/test_interface.html

simonjam: I prefer having document.open/.close/.write not impact navigation timing attributes.

Jatinder: I agree, as they do not impact network timing, and this spec is very focussed on network timing data.
... Per Boris' suggestion, seems like we should define "navigation" and exclude document.open/.write/.close in that definition. I like the idea of explictly defining navigation.

James: I like the idea as well.

<plh> ACTION: plh to move Performance Timeline to CR [recorded in http://www.w3.org/2012/06/27-webperf-minutes.html#action01]

<trackbot> Created ACTION-105 - Move Performance Timeline to CR [on Philippe Le Hégaret - due 2012-07-04].

<plh> oh, high resolution time is already a CR, so no need for action

<plh> my bad

plh, moving high resolution time to PR will need to wait for two implementations and test suite? IE has one currently.

<plh> correct

<plh> Google submitted one test already btw

Ok.

Jatinder: The working group would like to move Performance Timeline to CR, as this spec has no additional last call feedback and has been stable for some time.

Plh: Agreed.

James: Agreed.

Jatinder: For the navigation timing change, I will propose a definition of "navigation" and include Zhiheng on that mail.
... Boris also suggested "Each browsing context must have a unique window.performance.timing attribute" text implies the PerformanceTiming object is the same across pageloads, which I don't believe was our intention. I recommend we remove that line.

Plh: Let's include Zhiheng in that proposal, as he might have additional insight.

James: Sounds fine to me.

Jatinder: Boris also suggested "PerformanceTiming objects in the timing attribute may be sorted by the chronological order of the corresponding browsing context" line is unclear. I'm not very sure what this line really means, as I don't believe we allow iterating through the attributes. I'll email Zhiheng to see what his intentions here were, but otherwise, I recommend we cut this line.

James: Agree.

Jatinder: Another issue raised was regarding "Some user agents maintain the DOM structure of the document in memory during navigation operations such as forward and backward. In those cases, the window.performance.timing and window.performance.navigation objects must not be altered during the navigation." Though this is referring to the bf cache, Boris felt this text wasn't very clear. I recommend we treat the bfcache navigations that don't hit the
... Considering Firefox is the only implementer of bfcache, I will follow up with Boris to see what he thinks of that.
Other specs

Jatinder: I have updates on the other specs that I intend to push out today.

James: I am looking forward to seeing those updates.