Re: [Web Timing] Getting root timings to recommendation

   Thanks, Anderson. Pls find comments inline.

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.
>

    Both fixed.


>
>
> In terms of navigationStart, it is the intention to begin immediately after
> the onbeforeunload.
>

    This makes it rather close to fetchStart, which is Step 11
here<http://www.whatwg.org/specs/web-apps/current-work/#navigating-across-documents>.
Instead, navigationStart is intended for the moment
before Step 1.


>
>
> 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.
>

    cool. so they will be (un)loadEventStart/End


>
>
> 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.
>

     Sounds good mostly. Could you elaborate the difference between
domComplete and loadEventStart?
They are both after Step 7 and before Step 8 in the current parsing
model<http://www.whatwg.org/specs/web-apps/current-work/#the-end>
.



>
>
> 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.
>

    Good to know that we have concensus here.


>
>
> 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.
>

    I think it's a good idea to promote this measurement, even though I am
not sure if we need a normative name.
There should be more discussions in UserTiming but my concern is, if we are
to use
it to benchmark different pages, there is always someway to game it.


>
> 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.
>

   My preference is to leave it to developers to do the conversion.

cheers,
Zhiheng



>
>
> 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
>
>
>
>
>