[minutes] 2012-06-13 Web Performance WG Teleconference #76

Meeting Summary:



1.       Navigation Timing

The Working Group had been discussing the status of Navigation Timing and Navigation Timing Level 2 specs. Per feedback from Philippe, we feel that Navigation Timing should continue to be standardized and new work should be defined in Navigation Timing Level 2. UAs should implement both specs.



There was a point raised that other specs require the Navigation Timing behavior. E.g., for High Resolution Time, in order to (A) measure performance.now() from the navigation start of a document, the definition of performance.timing.navigationStart, at least internally, is required, and (B) in order to compare performance.now() values across frames, one will need to add performance.timing.navigationStart to performance.now().



2.       Resource Timing

There have been two pieces of clarification feedback on the Resource Timing specification that the editor will make: update the initatorType definition to include localName and JS object constructors, and update the Timing-Allow-Origin to include the processing model.



3.       User Timing

During the Last Call period, there were only three pieces of feedback on this spec: getMarks/getMeasures should not return Array, privacy section should clarify why there will not be restrictions and the example needs an update. Due to the limited churn, the WG is considering moving this spec to CR in the next few weeks.



4.       Performance Timeline

The only Last Call feedback on this spec was to update the example code. Considering the spec has been very stable, the WG would like to move this spec to CR.



5.       Page Visibility

Jatinder is working on updating the spec to resolve ISSUE-8. As this is the last remaining issue on the spec, and the spec has been very stable, once this issue has been resolved, the WG would like to move this spec forward.



6.       High Resolution Time

There are currently no active open issues.



7.       Charter

The WG has agreed to extend the current charter for a few months longer. Once we have completed work on these existing specs, we will consider a charter update in order to take on new work.


Detailed Notes:



Web Perf Teleconference #76 6/13/2012



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



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



Attendees

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

Jatinder Mann, Arvind Jain, Philippe Le Hegaret, Alois Reitbauer


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 and charter



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

Jatinder: Sigbjorn raised concerns about moving this spec to PR if we intend to replace this API with the one definednnIn Navigation Timing 2.
... After some discussions about the timebase of DOMHighResTimeStamp and comparing performance.now()n values across, it was clear that in order to (A) measure performance.now() from the navigation start of a document, we need to define, at least internally, a performance.timing.navigationStart value, (B) in order to compare performance.now() values across frames, we need to be able to add performance.timing.navigationStart to performance.now() t
... Aside from our other arguments for standardizing Navigation Timing and working on the next version of the spec, I think these are clear use cases where we need to have Navigation Timing standardized and implemented interoperably in order to use High Resolution Time. What are your thoughts Philippe?n

Philippe: If we believe there is value in UA to implement Navigation Timing, then we should standarize it. Do we believe UAs should implement Navigation Timing?

Jatinder: Yes.

Arvind: Yes.

Philippe: I will respond to Sigbjorn on the mailing list. We should plan to move Navigation Timing to PR in the next two weeks and move Navigation Timing 2 to FPWD.
Resource Timing

Philippe: Any updates from Resource Timing?

Jatinder: I have action items to update the initiatorType definition to be tied to the element's localname and the object's constructor. This doesn't change the behavior, just implementation. I will update the spec.
... Also, we wanted to include a short processing model for Timing-Allow-Origin that clarifies the behavior. There is no real change of behavior here as well.
User Timing

Philippe: Updates on User Timing?

Jatinder: There are three changes: getMarks(), getMeasures() should return an object, example needs fixing and I need to add details in the privacy section to clarify the current behavior.
... These are the only feedback we got during Last Call. I am working on making those changes.

Philippe: Once these changes are made, we should be able to move this spec forward to CR.
Performance Timeline

Philippe: Any Last Call feedback on Performance Timeline?

Jatinder: Just an update to the example.

Philippe: We should be able to move that one to CR along with the others once those changes have been made.
High Resolution Time

Philippe: Any feedback?

Jatinder: There was a discussion on the timebase for HRT. However, it has been resolved with the current behavior remaining.
Page Visibility

Philippe: Page Visibility feedback?

Jatinder: There is Issue-8 that has been agreed upon now. I am working on updating the spec. I raised a concern on creating iframe specific behavior, we had agree to tie everything to top level browsing context.

Arvind: I will follow up with the Chrome team to see their opinion here.

Jatinder: I will start making the rest of that change. This is the last remaining item on this spec. Once this has been closed, we should discuss moving this spec forward.
Navigation Timing 2

Philippe: Can we ready this spec fo FPWD in the next two weeks?

Jatinder: Yes, that should be fine.
... There was an issue brought up on the mailing list about IE9's support of window.performance.toJSON and how that isn't spec'd out. Should we consider adding that behavior to Navigation Timing 2? Considering we expect most users to stringify this data and send to a server, seems like a logical choice.

Arvind: I will follow up with the Chrome team to get their opinion and get back.
RequestAnimationFrame

Philippe: I will follow up with the editors to see if they are working on making updates.
Charter

Philippe: Our charter expires at the end of this month. We need to either ask for an extension of this charter or propose a new charter. In order to work on new things, we will need a new charter. We have a couple of action items on folks to research new ideas; these will need a charter update. Per Jason Weber though, he wanted to first complete these specs before starting work on others.

Jatinder: Considering we are very near done with these specs, I would also prefer focussing on these spec and finishing them up before moving to the next ones.

Arvind: I believe HARS should be covered in the current charter anyway.

Philippe: I will follow up on getting the charter extended.