<scribe> agenda: 'http://lists.w3.org/Archives/Public/public-web-perf/2011Apr/0052.html'

<scribe> scribe: Jatinder

1. Announce starting Wednesday 2PM PST teleconf meetings next week for Page Visibility, Efficient Script Yielding and Display Paint Notifications.

2. Feedback and discussion on Monotonic Clocks

http://www.w3.org/TR/navigation-timing/

<scribe> ACTION: "Jatinder to update Resource and User Timing specs to include Section 5.3 Monotonic Clock" [recorded in http://www.w3.org/2011/04/20-webperf-minutes.html#action01]

<trackbot> Sorry, couldn't find user - "Jatinder

3. Feedback and discussion on proposed changes to navigationStart for the cross-domain redirect case.

We agree to change Navigation Timing such that navigationStart is not zero'd out for cross-domain redirect cases.

<scribe> ACTION: Zhiheng to update Navigation Timing spec to ensure navigationStart is not zero'd out for x-domain redirect case. [recorded in http://www.w3.org/2011/04/20-webperf-minutes.html#action02]

<trackbot> Created ACTION-23 - Update Navigation Timing spec to ensure navigationStart is not zero'd out for x-domain redirect case. [on Zhiheng Wang - due 2011-04-27].

4. Feedback and discussion on Unified Timing API proposal.

Jatinder: I have spent some time looking at the new proposal and I am opposed to making this change. Common practice is to design APIs for a specific task and not try to over-generalize them. Trying to unify these different APIs for Resource, User and Navigation Timing into a single API will make the unified API overly complicated. It will add restrictions to our ability to innovate these APIs in the future, as a change specific to one area will impact all
... Aside from combining the multiple APIs into a single API, this proposal doesn’t provide any substantial features or benefits when compared to the existing proposal. We have spent quite a few months on the existing spec and are near completion. Microsoft’s preference is to focus our attention in improving and stabilizing the existing spec and bringing it to Candidate Recommendation.

Tony: Unified Timing as proposed isn't going to fly. We will need to update the current spec with the features we want.
... We want to deal with Resource Timing. We are arbitrarily recreating the DOM and making the elements appears as if they are associated with a particular DOM element, by ID. But this feels thin. Developer might want to act on this in any number of ways.
... Feels a bit arbitrarily. Based on the snapshot of the DOM based on history, rather than what it looks like now. Our thinking process is that there are a stream of events in the browser, and we want to time anything.
... E.g., in the Chrome inspector, there are many timing data that aren't associated with an element.
... My question would really be, how strong is the use case for looking things up by id or type at the time things were requested.
... only looking things by URL.

Nic: We can't always assume there is a 1:1 mapping there. URLs, IDs can change over time.

Tony: Agree. Keeping static IDs is a shaky thing to do.

Nic: Maybe we don't keep the getbyID or getbyType.

Tony: A lookup by URL would be useful.

Zhiheng: Don't always know the URL of the iframe by javascript?

Tony: You can use existing DOM calls to traverse the DOM tree and get the URLs.

Karen: The concept was to have an unique identifier, so you can get the timing data for a particular resource. Imagine the same resource in the header or the footer, and you want to get the data on a particular one.
... Any suggestions of how to get data on a particular resource that is displayed multiple times?

Tony: I thought we discussed this before. If the same resource is used multiple times, we show it once.

Nic: Yes, for images and such. But XHRs, for example, can be pulled down mutiple times.

Tony: I see. Can't cache XHRs?

Nic: The idea behind these were convenience APIs. We can pull these out if we don't want the convenience.

Jatinder: If these are really convenience APIs, what is the downside? Are we afraid that users might be confused?

Tony: It's odd to have a static ID, where it can change later on. Can create confusion.

Jatinder: Is the proposal to get getResourceTimingsByID and getResourcesTimingsByType and just keep getResourceTimingsByLocation?

Tony: Yes.

Nic: What about the attributes?

Tony: Another thought, we should allow web developers to turn on the logging, so we don't have to keep this in memory by default.

Jatinder: The downside is that there needs to be script in the <head>.

Zhiheng: I don't prefer script in the <head>. It's not as reliable.

Jatinder: Didn't we, on the mailing list, already run tests on browsers and agree that the overhead was acceptable?

We agreed on the call to move ahead with providing feedback to the current Resource and User Timing specs, and not pursue the Unified Timing model. Tony will send out mail with concerns he has with the current API and we will discuss them next week on the call and in the mailing thread.

<scribe> ACTION: Jatinder to update Resource and User Timing specs to include Section 5.3 Monotonic Clock. [recorded in http://www.w3.org/2011/04/20-webperf-minutes.html#action03]

<trackbot> Created ACTION-24 - Update Resource and User Timing specs to include Section 5.3 Monotonic Clock. [on Jatinder Mann - due 2011-04-27].

This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: Jatinder
Inferring ScribeNick: Jatinder
Default Present: [Microsoft], +1.760.705.aaaa, Plh, +1.650.214.aabb, +1.650.691.aacc, tomayac, +1.650.253.aadd

WARNING: Replacing previous Present list. (Old list: Jatinder)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ Nic


WARNING: Replacing previous Present list. (Old list: Nic)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ Cameron


WARNING: Replacing previous Present list. (Old list: Cameron)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ Christian

Present: Christian Jatinder Nic Cameron Philippe JamesS JamesR KarenA Zhiheng

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Got date from IRC log name: 20 Apr 2011
Guessing minutes URL: http://www.w3.org/2011/04/20-webperf-minutes.html

WARNING: No person found for ACTION item: "jatinder to update resource and user timing specs to include section 5.3 monotonic clock" [recorded in http://www.w3.org/2011/04/20-webperf-minutes.html#action01]

People with action items: jatinder zhiheng