See also: IRC log
<scribe> Meeting: Web Performance WG Teleconference #35 Agenda 2011-06-01
<scribe> scribe: Jatinder Mann
Jatinder: Philippe has prepared a
list of issues that were raised in the mailing list and may
still need to be resolved: http://www.w3.org/2011/06/navigation-timing-issues.html
... Which of these are outstanding? Per Zhiheng’s response, it
appears that only the
http://w3c-test.org/webperf/tests/approved/test_navigation_type_backforward.htm
test case needs to be updated to deal with bfcache (we
concluded that values shouldn’t change due to bfcache).
Zhiheng: That appears to be the only issue so far.
Philippe: It would be best if we can respond on the mailing list if these issues have been resolved.
Jatinder: Who would like to update the http://w3c-test.org/webperf/tests/approved/test_navigation_type_backforward.htm?
Zhiheng: We can do so by using the onunloader handler.
Tony: Have we decided what the correct behavior here should be?
Zhiheng: We had discussed on the mailing list that we don't want to make a change here to reduce confusion.
http://lists.w3.org/Archives/Public/public-web-perf/2011Mar/0110.html
JamesS: Don't we risk the page reporting the data twice here?
Anne: I had a question about bfcache. Do you get domready events?
Kyle: It treats the page as being hidden and brings it back.
Anne: All browsers?
Kyle: Just Firefox.
Anne: On the first page load, if
you dumped data to the server. If we go back and forward, would
more stuff be added to the bfcache?
... on a timer.
... It should at least be marked in the data that this came
from the back forward.
<Christian> anne=anne sullivan?
<simonjam> yes
ACTION Update the Navigation Timing to be clear what the expected behavior with bfcache on Zhiheng
<trackbot> Sorry, couldn't find user - Update
ACTION to Zhiheng to Update the Navigation Timing to be clear what the expected behavior with bfcache
<trackbot> Sorry, couldn't find user - to
Jatinder: Per last week’s discussion, our goal is to enter Last Call for Resource Timing as soon as we can. I have added Section 4.6 Vendor Prefix to respond to Sigborn’s feedback on the mailing list, and have opened ACTION 35 and 36 to make similar changes to Navigation Timing and User Timing. Are there any other issues that need to be responded to prior to entering Last Call?
James: We need to discuss future direction. We need to do a better job with these APIs. We should treat the timing information similar to the DOM, have one API and build from it.
Arvind: Tony, what about the Navigation Timing API? Are your concerns only specific to Resource Timing?
James: For example, you tried to create a new performance timing API for webGL, we would have to create new APIs.
James to have an updated unified proposal API by end of the week.
Arvind: We shouldn't go into Last Call for a week or two.
Jatinder: Agree that we shouldn't go into Last Call until we have consensus.
Kyle: I want to include the HTTP response code.
Jatinder: I believe this was discussed on the mailing list prior - does anyone remember why we didn't make this change?
James: I believe it was because of privacy concerns that we didn't include this.
Kyle: Should we allow third party scripts that are added via <script> to have the same level of access as a script added on the page.
Jatinder: The convention on the web is to treat third party scripts added to the page, as a script on the page.
Kyle: Want to include HTTP response code. We can only provide this information to same-origin and not cross-origin.
Jatinder: Biggest concern with
HTTP response code is that they can create finger printing
attacks.
... There has been some heated debates on the mailing list
whether we should use Page Visibility or IDLE states in order
to help web developers write CPU and power efficient
applications. We all want to provide the right tools to let web
developers create efficient applications, we need to agree on
the means. Let’s use the teleconference forum to discuss both
proposals.
Jason: I don’t see these as
competing proposals, but rather as complimentary. Today
developers don’t have the information to informed decisions.
For example, a developer doesn’t understand when a browser is
minified; page visibility can help here. As I been looking at
the threads for a few months now, I can see that there have
been additional APIs that can help give more information. For
example, the cpu idle state of the machine and the machine
b
... up is another interesting information that will be useful
for web developers.
... I recommend we continue with the current charter and finish
these specs. We can continue to add more specs in the
charter.
Arvind: I agree with what Jason just has said.
Kyle: What does Page Visibility give that IDLE doesn't?
Arvind: I need clarity on the multi-tasking/multi-monitor scenario. If we don’t provide a Page Visibility API and only provide an IDLE state API, how will a web developer know whether the user is definitively not viewing a page? If a user has a browser and another application opened and visible at the same time, but is only interacting with the application, the IDLE state API may change the behavior of a page, even though it shouldn’t.
Jason: If the page goes into a background tab, the page may want to bring the resources down to zero.
Kyle: Fair enough that was a performance scenario.
Cameron: IDLE doesn’t give the scenario where the page is visible but is not being interacted with.
Arvind: IDLE wouldn’t give the prerendered scenario either.
Kyle: That's definitely a scenario I haven't considered before.
<plh> http://www.w3.org/TR/2011/WD-animation-timing-20110602/
<heycam> plh, cool, I'll update the version in hg with the new short name
Jason: We had re-chartered to specifically include Page Visibility into the Web Performance WG and we like where Page Visibility is going. We can re-charter to add machine idle and user idle in the future. Kyle, if you can draft up a proposal for user idle, we can consider it.
Kyle: Agreed.
Jatinder: I raised Issue-7
FrameRequestCallback interface should be designated as
Callback=FunctionOnly. We may not want to allow objects to be
registered as callbacks, especially seeing that the API seems
to have been designed for function callbacks.
... We are planning on taking this spec to first public draft
tomorrow. Are there any objections?
No objections.
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 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: JatinderMann Found Scribe: Jatinder Mann Default Present: [Microsoft], +1.650.214.aaaa, +44.207.184.aabb, +1.512.851.aacc, Philippe, +1.650.691.aadd, [Google], heycam, Plh Present: [Microsoft] +1.650.214.aaaa +44.207.184.aabb +1.512.851.aacc Philippe +1.650.691.aadd [Google] heycam Plh TonyG Anne JamesS Kyle Christian Zhiheng Agenda: http://lists.w3.org/Archives/Public/public-web-perf/2011Jun/0004.html WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Got date from IRC log name: 01 Jun 2011 Guessing minutes URL: http://www.w3.org/2011/06/01-webperf-minutes.html People with action items:[End of scribe.perl diagnostic output]