- From: Tony Gentilcore <tonyg@google.com>
- Date: Wed, 18 Aug 2010 17:12:03 -0700
- To: Anderson Quach <aquach@microsoft.com>
- Cc: Zhiheng Wang <zhihengw@google.com>, "public-web-perf@w3.org" <public-web-perf@w3.org>
- Message-ID: <AANLkTikkZhC97D6mELOWT8y-V4fBCPmJ_OAVrREPG104@mail.gmail.com>
Thanks for the updates. Leaving mark/measure/fullyLoaded for our next conversation, the only question I still have is about the definition of requestEnd. The IE platform preview sets it at a later point than the draft and Chrome 6. Everything else looks good to me. -Tony On Wed, Aug 18, 2010 at 5:03 PM, Anderson Quach <aquach@microsoft.com>wrote: > > > Hi Tony and Zhiheng, > > > > This is a great discussion here. Here are thoughts from Nic and I. > > > > It’s really important that we keep the normative requirements in both > definition and the processing model free from any inconsistencies and > ambiguity. I’m presuming you folks are talking about the differences in > section 4.2 The NavigationTiming Interface and section 4.5 Processing Model > of the Aug 17 working draft [1]. > > > > There’s a slight typo in section 4.3 NavigationInfo, the “attribute read > only attribute unsigned short type” is capitalized. > > > > In section 4.4 window.performance.timing, the sample code use a > NavigationInfo.type that does not exist and a close parenthesis is missing > from the if statement block. > > > > In terms of navigationStart, it is the intention to begin immediately after > the onbeforeunload. > > > > As for the markers related to the document load and unload. It’s our > recommendation to be more explicit about the naming. Currently this is not > updated in the fourth IE platform preview, but it is our intention to update > this as soon as possible. > > > > With the DOM events implemented in the platform preview, the time at which > the DOM readystate transitions to loading can be unique from responseEnd, > and with the readystate transitions to complete can be unique from > loadEventStart. For consistency and completeness, we would recommend the > standardization of the following markers as it relates to HTML5: domLoading, > domInteractive, domContentLoaded and domComplete. > > > > We share the same concerns with respect to the ability to standardize the > results for firstPaint. All user agents will do different amount of work in > their first paint. I’d recommend either making it a non-normative > requirement, or perhaps not introducing it in the NavigationTiming > interface. > > > > The intention for fullyLoaded is for the site developer to capture when > they declare the page and their content is finished loaded. This can be > marked by the site developer and can be long after loadEventEnd has > completed. This marker however, is best discussed in the context of User > Timings. > > > > Timing measures allow for site developers to easily and compactly grab the > time phases within the timeline. The idea here is to enable access to the > overall time it took to navigate, time phases associated with fetching the > document and the time phases associated with loading the document in the > browser. > > > > Best Regards, > > Anderson Quach > > IE Program Manager > > > > [1] http://dev.w3.org/2006/webapi/WebTiming/ > > > > *From:* public-web-perf-request@w3.org [mailto: > public-web-perf-request@w3.org] *On Behalf Of *Zhiheng Wang > *Sent:* Tuesday, August 17, 2010 2:19 PM > *To:* Tony Gentilcore > *Cc:* public-web-perf@w3.org > *Subject:* Re: [Web Timing] Getting root timings to recommendation > > > > This is extremely helpful. Thanks, Tony. Please find comments inline. > > On Mon, Aug 16, 2010 at 11:08 AM, Tony Gentilcore <tonyg@google.com> > wrote: > > Chrome 7 and the IE9 beta are drawing near. While aggressive, it might be > possible to push to get the Web Timing spec [1] into a recommended state by > then so that we can drop the vendor prefixes for those releases. > > > > Agree we should moving towards removing the vendor prefixes. As we > discussed out of this thread, fortunately, advancing the draft to > recommendation doesn't necessarily > > block us from doing it (at least for Chrome). :-) > > > > > > I've surveyed the spec and the two implementations and prepared a summary > [2] of the remaining differences. The left most column lists an event or > step in the whatwg HTML5 spec. The next four columns list how the two spec > sections and two implementations label that step. My editorials are on the > right summarizing the differences. > > > > Some high level thoughts: > > 1. The spec has normative requirements in both 4.2 and 4.4. This introduces > the possibility that the spec is internally inconsistent (or at best > redundant). My preference would be for 4.4 to be normative and 4.2 to be > rephrased as non-normative notes. > > > > I would keep both normative when eliminating any inconsistency and > redundancy (if any). And if one of them has to be relaxed, it should > > be 4.5 (processing model) IMO. Definition is what keep the attributes > consistent across user agents. > > > > 2. The spec could use a careful editorial pass to clean up typos, apply > some formatting to 4.4, and link up more definitions. > > > > Agree. I will take care of them. > > > > 3. Resource timing needs to be split into another document. > > > > Done in the latest updates. ResourceTiming is now under > http://dev.w3.org/2006/webapi/ResourceTiming/ > > I will send out more notes when I add a couple more points into it. > > > > 4. In terms of the actual implementations, there are only very minor > differences. I think this is all: > > 1. We are pretty close on navigationStart, but we need to be specific > about beforeunload. > > > > While having it up in the draft for easy discussion, I incline to > remove unloadStart. Security triumphs. That said, I would really like > > to see more feedback from others about this particular issue. > > > > > > 2. [un]loadEvent[Start,End] vs. [un]load[Start,End]. > > 3. requestEnd is marked differently. > > 4. dom*, firstPaint, fullyLoaded timings should either be put in the spec > or prefixed w/ ms. > > > > All of this only pertains to window.performance.timing. We probably need to > talk about navigation, timingMeasures, and the new Mark/Measure APIs. > > > > I believe the new Mark API falls into the UserTiming space? ( > http://www.w3.org/2010/08/webperf.html) > > > > thanks, > > Zhiheng > > > > > > > > > > -Tony > > > > [1] http://dev.w3.org/2006/webapi/WebTiming/ > > [2] > https://spreadsheets.google.com/ccc?key=0AvEMl2LYkOQ5dGRLV3Nxc0lCQk0xNTNYRFBFRHlUWXc > > > > >
Received on Thursday, 19 August 2010 00:13:07 UTC