17:01:24 <RRSAgent> RRSAgent has joined #webperf
17:01:24 <RRSAgent> logging to http://www.w3.org/2013/05/08-webperf-irc
17:01:26 <trackbot> RRSAgent, make logs world
17:01:26 <Zakim> Zakim has joined #webperf
17:01:28 <trackbot> Zakim, this will be WPWG
17:01:28 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
17:01:29 <trackbot> Meeting: Web Performance Working Group Teleconference
17:01:29 <trackbot> Date: 08 May 2013
17:02:37 <JatinderMann> present+ JatinderMann
17:04:30 <JatinderMann> present+ ArvindJain
17:04:49 <Alois> Alois has joined #webperf
17:05:30 <JatinderMann> present+ Alois
17:08:35 <JatinderMann> Jatinder: It looks like all browsers have implemented a somewhat different about:blank performance.timing attribute values. Seeing that these timing values aren't very useful to site developers, we can just specify that user agents MUST define the attributes, to avoid throwing an exception, but add a SHOULD clause on the expected values. Thoughts?
17:08:42 <JatinderMann> Topic: Timing Spec Feedback
17:09:06 <JatinderMann> Arvind: The only change I made was that if there is no previous document, the attribute must return the time the current document is created.
17:11:50 <JatinderMann> Arvind: I think the spec is clear here as is.
17:12:23 <JatinderMann> Arvind: I asked Philippe to update the edition 2 of the navigation timing spec to include.
17:15:41 <JatinderMann> Jatinder: I thought we had added that about:blank example after an discussion on that example. What should we do in the case that one creates an about:blank iframe and changes the source value later? Should there be only one iframe entry or two?
17:21:28 <JatinderMann> Arvind: Technically, the about:blank document can't be fetched. There should only be one resource entry.
17:23:46 <simonjam> simonjam has joined #webperf
17:25:24 <JatinderMann> Arvind: I think we should update the example to state that the about:blank case shouldn't be included.
17:25:41 <JatinderMann> Jatinder: Test cases are assuming 304 should add an entry but 404 shouldn't add an entry. Seems like both of these are examples of when the body of the resource never came down. The processing model step 7 states: "If fetching the resource is aborted for any reason, abort the remaining steps."
17:25:50 <JatinderMann> Jatinder: Should we include 304s?
17:30:25 <JatinderMann> Arvind: 304 does mean that there is some time spent in the networking layer, before the resource is pulled from the cache. Let me check to see if the processing model covers this as is.
17:30:54 <JatinderMann> Alois: We found that sometimes in Chrome resources that haven't been completed are added.
17:32:35 <JatinderMann> Alois: It's useful to get that missing error data. Also the case if the resource is aborted, if the resource leaves the page midway.
17:33:00 <JatinderMann> Jatinder: There is value in putting the resource error data in the same timeline as resource timing.
17:33:37 <JatinderMann> Arvind: Having them in the same timeline means that you can see the attribute values for each of the successful phase, which is useful.
17:34:54 <JatinderMann> Jatinder: I rather we standarize Resource Timing L1 as is, and discuss whether we add aborted/error resources in Resource Error Loggin or Resource Timing Level 2.
17:35:59 <JatinderMann> Arvind: I like that idea as well.
17:36:45 <Alois> where is the latest version of nav error logging?
17:36:54 <JatinderMann> https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationErrorLogging/Overview.html
17:37:12 <JatinderMann> Dan: We should make sure we include aborted/abandoned resources.
17:37:19 <JatinderMann> Topic: Navigation Error Logging
17:37:36 <JatinderMann> Arvind: I made some updates to the Navigation Error Logging specs: https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationErrorLogging/Overview.html.
17:37:55 <JatinderMann> Dan: I don't like the idea of only giving the general categories, it may not be as useful.
17:39:31 <JatinderMann> Arvind: I don't think we should define the actual errors. We should link to a reference HTTP errors.
17:41:04 <JatinderMann> Dan: There are some errors that we need to actually define. I will put together a list and send it out for discussion.
17:42:09 <JatinderMann> Jatinder: What do we plan to do if we want to exclude a class of error types?
17:42:18 <JatinderMann> Dan: We can add a list of errors that we can exclude.
17:42:33 <JatinderMann> Arvind: I rather we let the User Agent just decide which errors to exclude.
17:45:35 <JatinderMann> Arvind: As there is a local storage read, I made the calls asynchronous.
17:47:25 <JatinderMann> Jatinder: I noticed that the method name is getNavigationErrors. Should we make it future proof by making a getErrors method?
17:47:53 <JatinderMann> Dan: There was a discussion in HTML about possibly expanding this interface for other errors.
17:47:59 <JatinderMann> Arvind: Can you send a link?
17:51:06 <JatinderMann> Dan: There are a number of options on how to future proof this API.
17:51:47 <JatinderMann> Jatinder: I like the idea of future proofing. At the same time, I think this will be the only historical data we store, so probably the only time we need an asynchronous call. Something to think about. Let's review the spec and give feedback on the mailing list.
17:51:56 <JatinderMann> Topic: Diagnostics
17:52:14 <JatinderMann> Jatinder: Since we are almost out of time, let's make sure to schedule Diagnostics discussion for next week's conference call.
17:52:18 <JatinderMann> rrsagent, generate minutes
17:52:18 <RRSAgent> I have made the request to generate http://www.w3.org/2013/05/08-webperf-minutes.html JatinderMann
19:03:22 <Zakim> Zakim has left #webperf