W3C home > Mailing lists > Public > public-web-perf@w3.org > July 2012

[minutes] 2012-07-11 Web Performance WG Teleconference #78

From: Jatinder Mann <jmann@microsoft.com>
Date: Wed, 11 Jul 2012 17:44:51 +0000
To: "public-web-perf@w3.org" <public-web-perf@w3.org>
Message-ID: <AE5FFD9402CD4F4785E812F2C9929D650E3BB9A7@SN2PRD0310MB383.namprd03.prod.outlook.com>
Meeting Summary:



1.       Navigation Timing

All Navigation Timing feedback has been responded to on the mailing list. The Working Group would like to schedule a call with the Director next week to take this spec to PR.



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 next week.



3.       Resource Timing

All feedback issues raised on this spec have been resolved. This spec is in CR. James is working on providing a test suite, which Jatinder will review.



4.       User Timing

The Working Group has agreed to resolve the last remaining Last Call feedback by removing the redundant API. As this spec has been stable for quite some time and there is no remaining feedback, the Working Group would like to move this spec to CR.



5.       Page Visibility

As there is no outstanding feedback on this spec and the spec has been very stable for a long time, we have two implementations and a test suite, the Working Group would like to move this spec to CR.



6.       High Resolution Time

There are currently no active open issues.


Detailed Notes:



Web Perf Teleconference #78 7/11/2012



IRC log: http://www.w3.org/2012/07/11-webperf-irc



Meeting Minutes: http://www.w3.org/2012/07/11-webperf-minutes.html



Attendees

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

Jatinder Mann, James Simonsen, Jason Weber


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: There were four pieces of feedback to this spec in the last few weeks.

[NavigationTiming] Uniqueness requirement for PerformanceTiming doesn't make much sense - http://lists.w3.org/Archives/Public/public-web-perf/2012Jun/0047.html

Jatinder: Zhiheng made the proper spec update here and resolved the issue.

[NavigationTiming] Not sure what the spec text about sorting PerformanceTiming objects means - http://lists.w3.org/Archives/Public/public-web-perf/2012Jun/0049.html

Zhiheng made the proper spec update here as well.

James: I saw that, yes.

[NavigationTiming] Issues in the document.open test (or perhaps in the spec, if the test is correct) - http://lists.w3.org/Archives/Public/public-web-perf/2012Jul/0022.html

Jatinder: To resolve the issue of ensuring document.open/.write/.close does not impact Navigation Timing and defining what is a navigation in Navigation Timing, can be achieved by referencing http://www.w3.org/TR/html5/single-page.html#navigate in the Navigation Timing spec.That reference excludes dynamic markup insertion. Zhiheng to make that update.

James: That looks like a good update to me.

Unclear note about "maintain the DOM structure of the document in memory" - http://lists.w3.org/Archives/Public/public-web-perf/2012Jun/0029.html

Jatinder: I believe we were trying to capture the scenario when traversing from a bfcache and not hitting the network, we shouldn't update the timing data for that page from when it had initially hit the network. I believe the definition of navigation doesn't explicitly include history traversal. If so, this might be out of scope anyway. I will close loop with Boris.
... Considering all feedback has been responded to, I propose we take this spec to PR next week and schedule the call with the Director.

James: I agree that there aren't any additional pieces of feedback.
... Let's take this spec to PR.
Performance Timeline

Jatinder: Seeing that Performance Timeline has been stable and has had no feedback for quite some time, I propose we take this spec to CR next week and schedule the call with the Director.

James: I believe we agreed to that two weeks ago. Let's move it to CR next week.
Resource Timing

Jatinder: I have responded to all feedback on the Resource Timing spec. As this spec is already in CR, we should start working on a test suite and implementations.

James: I have been working on a test suite for this spec. I will move them to the submission folder. Can you review them?

Jatinder: Yes, I can review them as soon as they are available. Thanks,
User Timing

Jatinder: User Timing spec only has one piece of feedback remaining and that is to review the getMarks/getMeasures APIs as they are redundant.
... I don't like the argument of sticking with generalized APIs vs specialized. We shouldn't restrict our API set on that principal.

James: I agree with that principal. I just don't think getMarks/getMeasures is the best example of specialized as they offer very similar data as the PErformance timeline provides.

Jatinder: Okay, let's make this change. I will respond to this Last Call feedback.

James: As there are no additional feedback and the rest of the spec has remained stable for some time, I recommend we take this spec to CR soon.

Jatinder: I agree. Let's schedule the call next week.
Page Visibility

Jatinder: As there is no outstanding feedback on this spec and the spec has been very stable for a long time, we have two implementations and a test suite, I propose we take this spec to CR.

James: If feedback has been met, I don't disagree.



Jason: Excellent seeing progress being made.
Received on Wednesday, 11 July 2012 17:46:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:33 UTC