Re: Updates to Navigation Timing errata

Would the following text just before the illustration make the intention
clear to implementors?

Note that user agents may choose to perform some of the steps involved in
loading the document speculatively prior to user navigation e.g. the user
agent could pre-resolve the host name, speculatively connect to the server
hosting the document or prefetch the root document ahead of the actual user
navigation. The timings in the PerformanceTiming <#performancetiming> interface
represent the time spent waiting after user navigation in these steps. For
example, in the case of speculative resolution that started and finished
before user navigation and the user agent was able to use that result, the
domainLookupStart <#dom-performancetiming-domainlookupstart> and
domainLookupEnd <#dom-performancetiming-domainlookupend> attributes should
both return the same value as fetchStart <#dom-performancetiming-fetchstart>.
If the speculative resolution started before user navigation and finished
after navigationStart <#dom-performancetiming-navigationstart>, the
domainLookupStart <#dom-performancetiming-domainlookupstart> attribute
should return the same value as
fetchStart<#dom-performancetiming-fetchstart> and
the domainLookupEnd <#dom-performancetiming-domainlookupend> attribute
should return the time immediately after the name lookup is successfully
done.

Arvind


On Tue, May 14, 2013 at 11:02 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 5/14/13 1:52 PM, Arvind Jain wrote:
>
>> Boris, with this being our intention, does the illustration still
>> concern you?
>>
>
> No, if that's the intention.  But I'm not sure the spec prose makes that
> very clear to implementors, since it assumes the illustration reflects
> reality in defining the processing model last I checked...
>
> -Boris
>