Re: Specifying

On 2/29/12 9:26 AM, Jonas Sicking wrote:
>> The main application of seems to be relative timing, which doesn't particularly require any origin. It seems to me to be a bit easier to allow an arbitrary origin, so that the implementation doesn't have to track a zero time and subtract. Do some important applications require zero to be start of navigation?
> It might be interesting to align with requestAnimationFrame. It
> currently uses Jan 1st 1970 as 0 time though there's a note that that
> might change. See step 2 in

I would love that, but...

While Gecko provided a way to get an opaque time stamp that could be 
compared to (and subtracted from to get milliseconds) the 
requestAnimationFrame timestamps, other implementors did not.  As a 
result content using requestAnimationFrame commonly uses JS Date() 
objects to record the start of the animation or whatever other time the 
argument to the animation frame callback is compared to.  It simply had 
no other option.

And since that content commonly uses the unprefixed form of 
requestAnimationFrame if that's available to be "future proof", it's not 
like prefixes are saving us here.

In addition to that, converting existing scripts that use 
setTimeout/setInterval to the new API is made easier if the 
script-visible timescale roughly matches JS Date().  This might have 
been OK to forgo, I guess, but it's what motivated the original 
implementation in Gecko as an offset from the Unix epoch.  In 
retrospect, maybe it would have been better to not do that and use an 
arbitrary origin, thus forcing people to implement a parallel "what time 
is it now?" method.

In any case, I somewhat doubt requestAnimationFrame could change here. 
Too much web content is depending on those times being comparable to JS 
Date simply because it had no other choice.  :(


Received on Wednesday, 29 February 2012 17:30:46 UTC