[minutes] 20110518 Web Performance WG Teleconference #33

Thank you for meeting on the call today. The meeting summary is shown below:



1.      Discussed feedback and updates to the Resource Timing spec
As we are going to First Public Working Draft next Wednesday, we need to ensure that the spec action items created this week are closed prior to next Wednesday.


a.       Closed Action Items for spec updates from last week

Per last week's action items, Resource Timing Section 4.1 has been updated with reference to SVG, Section 4.2 now refers to "in-memory browser cache, Section 4.3 definitions of redirectStart and redirectEnd have been updated to refer to Timing-Allow-Origin, step 5 of the processing model has been updated to refer to Timing-Allow-Origin and Section 1 Introduction has been updated. Closed out ACTION-27, ACTION-28, and ACTION-29.



b.       Agreed Data URIs should not be included in the PerformanceResourceTiming array

Considering Data URIs do not go to the network and are instead decoded after the transport layer has completed the download of the document, Data URIs are not classified as a downloadable resource. The spec needs to be clear that this type of resource should not be included.



c.        Agreed to keep the initiator types and not include content-type as a way of classifying resources

We agreed to not change the spec to not replace initiator type with content type as a way of classifying resources, as if you only know the content type, it may not be clear where the resource came from. For example, XHR may cause a fetch of various types of resources; without the initiator type, it may not be clear where the resources came from. Further, some resources, like script do not have a content-type.


d.       Clarify the spec when resources initiated via plugins should or should not be included in PerformanceResourceTiming


e.       Update the Processing Model with more details

We agreed that the Processing Model section needs to be updated to include more details around when the resource timing list is created, when the data collection begins, when to populate the buffer with meta data (url and type), what actions to take when the buffer is full. Jatinder to suggest an update to the spec via ACTION-30.



f.         Agreed resourceFetchStart should be named resourceStart


2.      Discussed feedback and updates to the User Timing spec

Tony had sent a proposal to simplify the User Timing marks() and measures() interface to the mailing list: http://lists.w3.org/Archives/Public/public-web-perf/2011May/0063.html. As this proposal was only sent this morning, the WG will evaluate the proposal and respond with feedback on the mailing list.



3.      Discussed feedback and updates to the Page Visibility spec.
In today's call, we discussed the options we have regarding Page Visibility privacy:

1.       Determine that Page Visibility doesn't significantly increase the privacy issue that is already present,

2.       Allow User agents to specify a setting to disable Page Visibility APIs,

3.       Page Visibility should be limited to same-origin unless specified via a meta-tag,

4.       A combination of options 2 and 3.



We agreed that option 3 breaks the convention where cross-domain scripts added via a script tag have access to the page's window and document. The Working Group needs to determine whether to go with option 1 or 2.



4.      Feedback and discussion on requestAnimationFrame.

a.       Standardize window.animationStartTime

We discussed the merits of standardizing window.animationStartTime in the requestAnimationFrame, as this property will allow all animations to have the same starting point. Without standardizing this property, web developers will be forced to Date.now(), which is not monotonically increasing and may not have the standard resolution of a millisecond.



b.       Make window.animationStartTime and the requestAnimationFrame() callback timestamp monotonically increasing

We discussed specifying both window.animationStartTime and the requestAnimationFrame() callback timestamp as monotonically increasing clocks, in UTC format with millisecond resolution.


The following Action Item was opened to update the spec: ACTION-31 Consider including window.animationStartTime and the requestAnimationFrame() callback timestamp as monotonically increasing clocks, in UTC format with millisecond resolution.





We had the following action items from this meeting:

1.       Jatinder Mann: Update Resource Timing to fix verbiage per feedback on list and call

2.       Jatinder Mann: Update Resource Timing Processing Model

3.       Working Group: Evaluate new User Timing proposal

4.       Working Group: Evaluate Page Visibility privacy options

5.       Cameron McCormack: Update requestAnimationFrame to include monotonically increasing clock



The meeting minutes are given below:



Web Perf Teleconference #33 5/18/2011



IRC log: http://www.w3.org/2011/05/18-webperf-irc


Meeting Minutes: http://www.w3.org/2011/05/18-webperf-minutes.html



Attendees

Present

Jatinder Mann, Nic Jansma, Jason Weber, Christian, JamesS, Anne, Zhiheng, Tony, Cameron



Regrets

Philippe Le Hegaret, Arvind Jain, James Robinson



Scribe

Jatinder Mann



Meeting Chair

Jatinder Mann



Contents

Agenda
1. Feedback and discussion on Resource Timing updates.
2. Feedback and discussion on User Timing updates.
3. Feedback and discussion on Page Visibility privacy concerns.
4. Feedback and discussion on requestAnimationFrame.



Topics

Page Visibility Privacy Concerns



Summary of Action Items

ACTION-30 - Update the processing model to make it more clear which resources are included or not included. [on Jatinder Mann - due 2011-05-25].



ACTION-31 - Consider including window.animationStartTime and the requestAnimationFrame() callback timestamp as monotonically increasing clocks, in UTC format with millisecond resolution. [on Cameron McCormack - due 2011-05-25].





--------------------------------------------------------------------------------



<scribe> scribe: JatinderMann



move to agenda 1



Jatinder: Per last week's action items, Resource Timing Section 4.1 has been updated with reference to SVG, Section 4.2 now refers to "in-memory browser cache, Section 4.3 definitions of redirectStart and redirectEnd have been updated to refer to Timing-Allow-Origin, step 5 of the processing model has been updated to refer to Timing-Allow-Origin.



close ACTION-27



<trackbot> ACTION-27 Update the first example in Section 4.2 to make the cache item clear. closed



close ACTION-28



<trackbot> ACTION-28 Add SVG to Section 4.1 closed



close ACTION-29



<trackbot> ACTION-29 Update Section 4.3 and Processing Model to refer to Timing-Allow-Origin header section. closed



Jatinder: I have also updated Section 1 Introduction. Is there any feedback on these changes?



Chrisitian: Should assign a function directly instead of an anonymous function.



Jatinder: Let's review Tony's Resource Timing feedback: http://lists.w3.org/Archives/Public/public-web-perf/2011May/0078.html



Tony: Let's call out DataURI out in the example as not being reported.



Nic: Agreed, that's what we were thinking too.



<tonyg> http://dev.w3.org/html5/spec/Overview.html#fetch



Tony: I feel that the processing model should call out which resources should or shouldn't be included. Like the HTML5 Fetch spec.



ACTION Jatinder to update the processing model to make it more clear which resources are included or not included.



<trackbot> Created ACTION-30 - Update the processing model to make it more clear which resources are included or not included. [on Jatinder Mann - due 2011-05-25].



Tony: For examples, plugins aren't clear in the spec whether they do include resources or not.



Jatinder: We can update the spec around plugins to make it more clear.



Tony: What is the rationale for basing the type attribute on the initiator element rather than content-type of the resource?



Nic: If you only know the content type, it may not be clear where the resource came from. For example, XHR may cause a fetch of various types of resources. Without the intiator type, it may not be clear where the resources came from.



Christian: With images the content-type could be misleading.



Nic: Content-type is not available to script at all today. Not sure what the security background here is.



Tony: It makes sense to have the intiator type, based on this conversation.



Nic: We will send an email to the thread to make this point clear.



Tony: Video can add a resource with two ways, via the poster or source. Maybe it maybe fine to have both come from video intiator.

... While we are fetching a resource that has a redirect, we could begin populating the attributes, but after the redirect occurs we would go back and make changes. It could be weird if someone would reference that in the meanwhile. For NT, javascript doesn't have a chance to observe things until the end. We should carefully think about when we want to populate things.

... Another thing to consider, we may or may not want this interface to be abused as a download progress API



Nic: Our two options are to either add the attribute values after the download occurs at the end of the array, or write '0' values and then expose it in the very end.



Tony: There could be a usecase where a resource fails to download, and you would like to see which phase does the resource fail at.



Jatinder: Sounds like a good use case.



Zhiheng: If the download takes too long and fetchStart has started, but there is no fetchEnd, what should we see?



Nic: Either '0's or no values.



Jatinder: I like the '0's because it implies something is outstanding.



Zhiheng: That feels good to me.



Tony: I don't feel strongly. If something is in the array, they should be accurate when written. The way our network works, we fill in things as they occur anyway.



Christian: We should keep an integer, like zero, there as a return value.



Chrisitan: What about using something like -1?



Jatinder: Since 0 collides with the cross domain case, we should either use something clearly undefined, like -1, or do not add until we are done.



Tony: Since the data is defined as unsigned, maybe that means we should stick with not adding until we are done.



Nic: That will make the processing model easier too.



Jatinder: We can take a stab at this in our processing model action item, and discuss this further on the mailing list.



Zhiheng: resourceStart starts when the resources has been queued to download.



Jatinder: We can update the text here.

... Let's discuss the onbufferful attribute. Tony mentioned whether we need this handler. Considering user agents can change the default size, a web developer may find this event useful. Otherwise, the web developer will need to explicitly set the maximum buffer size.



Tony: I'm not clear if the buffer is defined as a circular buffer or are resources dropped once it is filled.



Nic: We have defined this not as a circular buffer. Resources get dropped once the buffer is full.



Tony: One usecase could be setting the buffer to size 1, and then use the onbufferful event to know when the resources are getting downloaded.



Jatinder: We will update the spec with the rest of the smaller feedback points.



move to agenda 2



Jatinder: Let's review Tony's User Timing feedback: http://lists.w3.org/Archives/Public/public-web-perf/2011May/0081.html

... Considering we plan to go to FPWD for Resource Timing by next Wednesday, we will aim to have these changes made available this week.



move to agenda 3



Jatinder: I have made updates to the Page Visibility spec, per my mail on the mailing list: http://lists.w3.org/Archives/Public/public-web-perf/2011May/0063.html

... Let's discuss Page Visibility privacy concerns



Page Visibility Privacy Concerns

Jatinder: To recap, the privacy concern is that web applications can better deterministically know whether you are viewing their content then they could have done before.

... Using window.onfocus and window.onblur already gives a website a good indication of the user presence. Page Visibility will give a more accurate indication of user presence; Page Visibility will correctly return the User agent is visible in the case that it is not minimized and another application is in focus, whereas onfocus and onblur won't.

... Our options are as so: (1) Determine that Page Visibility doesn't significantly increase the privacy issue that is already present, (2) Allow User agents to specify a setting to disable Page Visibility APIs, (3) Page Visibility should be limited to same-origin unless specified via a meta-tag, (4) a combination of options 2 and 3.

... I would argue against option 3. The convention is to allow scripts added to a page to have full access to properties on window/document; they are treated as if they were same origin scripts. For example, today a x-domain script added to a page has access to window.onfocus and window.onblur. We shouldn't change this behavior.

... Let's follow up on the mailing list with these two proposals and close on the list, as we don't have all concerned parties here.



move to agenda 4



Jatinder: As we have been evaluating this spec, the concept of a window.animationStartTime seems like a very reasonable property to standardize. This property will allow all animations to have the same starting point. Without standardizing this property, web developers will be forced to Date.now().

... We think that both window.animationStartTime and the requestAnimationFrame() callback timestamp should be implemented as monotonically increasing clocks, in UTC format with millisecond resolution.



http://www.w3.org/2010/webperf/track/actions



Action Cameron to consider including window.animationStartTime and the requestAnimationFrame() callback timestamp as monotonically increasing clocks, in UTC format with millisecond resolution.



<trackbot> Created ACTION-31 - Consider including window.animationStartTime and the requestAnimationFrame() callback timestamp as monotonically increasing clocks, in UTC format with millisecond resolution. [on Cameron McCormack - due 2011-05-25].