Re: [HighResolutionTime] comments on

On Tue, 20 Mar 2012 23:21:47 +0100, Jatinder Mann <>  

>> I think it's ridiculous to have a spec that defines a single method. It  
>> would make sense to fold this into the spec that defines the Performance
>> interface:   
> The High Resolution Time spec defines the DOMHighResTimeStamp type and  
> method. As other specifications may be interested in  
> using a DOMHighResTimeStamp type (e.g., requestAnimationFrame) but not  
> interested in Navigation Timing, having a separate spec makes sense. In  
> addition, not only is Navigation Timing in CR (waiting to go to PR), it  
> doesn't even use high resolution time.
> We have already defined extensions to the Performance interface in many  
> specifications.


>> The spec says that the timer is accurate to at least a tenth of a  
>> millisecond, there's hardware
>> that doesn't support that accuracy. It should say to be as accurate as  
>> possible, but is not required
>> to be more accurate than a tenth of a millisecond.
> If High Resolution Time doesn't require at least a tenth of a  
> millisecond, it won't be providing any higher resolution than  
>, one of the goals of this feature.


> I believe all latest Windows (since '95 I believe), iOS, and Android  
> hardware support sub-millisecond resolution clocks; what hardware were  
> you thinking of?

This might not be a problem in the majority of cases, but I've been told  
that at least a few years ago some cases was no better than 10ms  
resolution (maybe it wasn't a hardware limitation but a limitation  
somewhere else). This is apparently mostly changed today, but I still  
think the spec shouldn't say to do something impossible when facing  
underlying limitations. (For instance, timer resolution might be reduced  
intentionally to not drain the battery.)

> If we think there is enough new hardware that won't be able to support  
> sub-millisecond resolution, I am fine changing the MUST clause to a  
> SHOULD clause.

The spec doesn't have this as a MUST clause currently.

>> The spec should call out whether the clock should be ticking while the  
>> document is not "fully active" (as defined in HTML).
> To be clear, you are bringing this up because you want to know if  
> includes the "time of suspension" when a page is in  
> the session history?


> I don't understand why we wouldn't want to include the time of  
> suspension - defines the current time since the start  
> of navigation. Let me know if I misunderstood your intention here.

Right, I'd just like it to be called out explicitly.

> Thanks,
> Jatinder

Simon Pieters
Opera Software

Received on Wednesday, 21 March 2012 14:14:11 UTC