- From: Philippe Le Hegaret <plh@w3.org>
- Date: Tue, 21 Dec 2010 16:24:03 -0500
- To: public-web-perf <public-web-perf@w3.org>
Available at http://www.w3.org/2010/12/15-webperf-minutes.html Text version: Web Performance Working Group Meeting #14 15 Dec 2010 Attendees Present AndersonQuach, JamesSimonsen, Plh, TonyG, Zhiheng, [Microsoft], plh, JasonWeber, NicJansma, KarenAnderson Regrets Chair JasonWeber Scribe AndersonQuach Contents * [2]Topics 1. [3]Navigation timing feedback on window.performance, DOM readiness markers. 2. [4]Review new test cases. * [5]Summary of Action Items _________________________________________________________ Navigation timing feedback on window.performance, DOM readiness markers. TonyG: If we get site compat issues filed, we can move to an interface that is read-write. PLH: we should capture this in the spec before last call. [6]http://www.w3.org/TR/html5/the-end.html [6] http://www.w3.org/TR/html5/the-end.html AndersonQuach: Recommend that we keep the markers as specified in the Navigation Timing specs, for the points Nic mentions in mail. NicJansma: Web developers can add a callback to the onreadystate event to do work. TonyG: Multiple scripts may be adding listeners, the site author may not understand all the listeners attached and the performance impact. JamesSimonsen: We brought this up, there's a lot of info and technical. The distinct of the DOM readiness state. I expect stuff user-agent authors understand. Would like to steer them into a direction that is self documenting and succint. TonyG: There are points i didn't considered, there are differences between each of these marks. Maybe it's worth having them. AndersonQuach: Each marker was introduced that have scenarios where site developers can operate on them. NicJansma: A good deliverable are samples and best practices on how to use these events, to help increase the awareness of the individual markers. Zhiheng: I like the way the spec is now, it captures the critical path of a page load. <plh> --> [7]http://test.w3.org/webperf/tests/submission/Microsoft/ tests from MSFT [7] http://test.w3.org/webperf/tests/submission/Microsoft/ Review new test cases. NicJansma: We would like feedback on the tests, particularly for user interactions. KarenAnderson: Document reload, is it okay to have a test that requires interaction, e.g. navigation_type_reload.htm? plh: Yes, I would think so. Unless we can find a way to do it automatically. TonyG: in that example, can you call window.location.reload NicJansma: It's more of a general question about user-interactive test cases or tests that require user interaction. ... It could be structured as a start page and move to a landing page. plh: General guideline is that automatic is preferred. ... We prefer automatic tests, once potentially talk about 100k + tests when more tests are added. For example: Mozilla would be reluctant if the tests are manual. NicJansma: We agree, we should automate as much as possible. Zhiheng: We have more than 10 test cases now. How do we have agreement on approved tests. AndersonQuach: As long as we have two user-agent vendors review and are okay we can approve it. plh: important to record that we approve the tests ... or remove a test to remove the test from the approved section ... as long as we make it clear to add the test or remove the tests, as long as someone is going to do it we'll be fine. ... what about last call? Zhiheng: namespace change to keep as read-only or read-write for window.performance. JasonWeber: Would like to ship a standards compliant implementation in IE. Would like to make a call for performance and not change the spec. ... Would like to finalize on the spec and remove uncertainty. we're open to either solution, read-only or read-write. ... We want to make sure there is integrity in the data. ... If we open up the performance object and someone can overwrite timing or navigation underneath. TonyG: We have one more idea. We can try to get some data on a million sites. JasonWeber: TonyG have you seen our data. I was satisfied with that personally, there is some feeling we want more confidence that it won't introduce compat issues. JamesSimonsen: The safest way to go is go with read-write and reduces the chances existing sites would break. JasonWeber: From our release process we are not comfortable with the ambiguity in the spec, or the possibility of a fallback, we would leave a vendor prefix.
Received on Tuesday, 21 December 2010 21:24:10 UTC