[High Resolution Time] Erratum

This is a clarification in the specification:
[[
Section 4.2 The DOMHighResTimeStamp Type currently states,

    The DOMHighResTimeStamp type is used to store a time value measured
relative to the navigationStart attribute of the PerformanceTiming
interface [NavigationTiming], the start of navigation of the document,
or a time value that represents a duration between two
DOMHighResTimeStamps.

It should state,

    The DOMHighResTimeStamp type is used to store a time value measured
relative to the start of navigation of the document, or a time value
that represents a duration between two DOMHighResTimeStamps.

    Note

    The time value of the start of navigation of the document in an
attribute of type DOMHighResTimeStamp is equal to 0. The same time value
described with an attribute of type DOMTimeStamp is equal to the
navigationStart attribute of the PerformanceTiming interface
[NavigationTiming].
]]
http://www.w3.org/2012/12/hr-time-errata.html




On Tue, 2013-10-22 at 23:57 +0000, Jatinder Mann wrote:
> Seeing that we updated High Resolution Time L2 [1] time origin section to reduce the confusion around the navigationStart attribute, I think it'll be worthwhile making a similar change for the High Resolution Time L1 [1] errata. In particular, the errata should state:
> 
> Section 4.2 The DOMHighResTimeStamp Type currently states,
> 
> "The DOMHighResTimeStamp type is used to store a time value measured relative to the navigationStart attribute of the PerformanceTiming interface [NavigationTiming], the start of navigation of the document, or a time value that represents a duration between two DOMHighResTimeStamps."
> 
> It should state,
> 
> "The DOMHighResTimeStamp type is used to store a time value measured relative to the start of navigation of the document, or a time value that represents a duration between two DOMHighResTimeStamps.
> 
> Note
> 
> The time value of the start of navigation of the document in an attribute of type DOMHighResTimeStamp is equal to 0. The same time value described with an attribute of type DOMTimeStamp is equal to the navigationStart attribute of the PerformanceTiming interface [NavigationTiming]."
> 
> This change does not change the conformance of the spec, just clarifies the text to reduce confusion. Philippe, this should be a simple change?
> 
> [1] https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/HighResolutionTime2/Overview.html#sec-time-origin 
> [2] http://www.w3.org/TR/2012/REC-hr-time-20121217/ 
> 
> -----Original Message-----
> From: Boris Zbarsky [mailto:bzbarsky@MIT.EDU] 
> Sent: Tuesday, October 1, 2013 5:50 PM
> To: Jatinder Mann
> Cc: 'public-web-perf@w3.org'; Philippe Le Hegaret (plh@w3.org); 'arvind@google.com'; James Simonsen (simonjam@google.com)
> Subject: Re: [ResourceTiming] The clock base to use in ResourceTiming is not defined
> 
> On 10/1/13 7:14 PM, Jatinder Mann wrote:
> > I think it's reasonable that the terminology section for the Resource Timing, User Timing, and Navigation Timing L2 specs define what they mean by current time, and clarify which definition of time is being used. This clarification is useful specifically since Navigation Timing L1 uses a different definition. I'll take an action to update those specs.
> 
> Great, thank you!
> 
> > To minimize this confusion, we can clarify the definition in High Resolution Time L2 with text like so:
> 
> That sounds good too.
> 
> > A duration is just a delta between two time values. Seeing that the DOMHighResTimeStamp definition specifically calls out that it can be a delta of two DOMHighResTimeStamps, and seeing that DOMTimeStamp doesn't have an analogous duration type, I think its fine to not define a separate duration type.
> 
> I can live with that, though I still think it's a bit confusing to do it that way.  With the other proposed clarifications this will be much less of a problem.
> 
> -Boris
>

Received on Friday, 25 October 2013 21:37:10 UTC