RE: [ResourceTiming] The clock base to use in ResourceTiming is not defined

On 9/27/13 7:42 PM, Boris Zbarsky wrote:
> 1)
> never defines "time" (unlike, say the Terminology section of Navigation Timing).
> 3) 
> keeps talking about recording "the current time", but as I said this 
> term is never defined.

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.

> 2)
> defines all the attributes as returning DOMHighResTimeStamp, but the DOMHighResTimeStamp
> type does not actually define what its 0 point represents.
> To be specific, even if we grant this, why is it "navigationStart" and not "the start of navigation
> of the document"?  Or is the claim that those are the same thing (in which case the way 
> DOMHighResTimeStamp is defined is pretty confusing)?

I can see that referencing navigationStart in the DOMHighResTimeStamp definition may be confusing to some. Also, the spec implicitly defines the 0 value instead of explicitly calling it out, which may cause confusion. To minimize this confusion, we can clarify the definition in High Resolution Time L2 with text like so:
"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. 
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 would be equal to the navigationStart attribute of the PerformanceTiming interface [NavigationTiming]."

We can also reference the 'navigation' definition [1] when using the term 'navigating' in the DOMHighResTimeStamp definition.

> Further, I believe that using DOMHighResTimeStamp for a _duration_ value is very misleading.  
> We should define a DOMHighResTimeDuration type for that.

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.



Received on Tuesday, 1 October 2013 23:14:40 UTC