W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2008

Re: Proposal: High resolution (and otherwise improved) timer API

From: Maciej Stachowiak <mjs@apple.com>
Date: Fri, 03 Oct 2008 14:01:43 -0700
To: Aaron Boodman <aa@google.com>
Cc: "public-webapps@w3.org Group WG" <public-webapps@w3.org>
Message-id: <D1EDF78D-714D-43DF-8619-09C8DCF00304@apple.com>


On Oct 3, 2008, at 10:43 AM, Aaron Boodman wrote:

> Hi Maciej,
>
> Thanks for raising this. It's a good addition to the web platform. I'm
> definitely +1 to the idea.
>
> 2008/10/2 Maciej Stachowiak <mjs@apple.com>:
>> // should be implemented by Window objects
>> interface WindowTimer {
>>   Timer startTimer(in double delayInSeconds, in boolean repeating,  
>> in TimerHandler handler);
>> }
>>
>> - Perhaps the delay should be in possibly-fractional milliseconds  
>> rather than possibly-fractional seconds. But expressing  
>> microseconds as fractional milliseconds seems quite weird.
>
> To me, fractional milliseconds does not seem weird. On the webkit-dev
> thread, Peter Speck pointed out [1] that the unit of time in web
> development is milliseconds. Dates are in milliseconds, setTimeout
> takes millisecond arguments, etc. So to me, it would be weird to have
> a new timer API that suddenly uses seconds. And I tend to agree with
> Peter that doing so would be a common source of bugs for web
> developers.

I find the fact that Dates are in milliseconds convincing. It should  
be in milliseconds so people can reasonably do math with Dates and  
elapsedTime.

>
>
>> - Perhaps the argument order should be (handler, delay, repeating)  
>> instead, to be more like setTimeout / setInterval
>>
>> - Perhaps the "repeating" or even the "delayInSeconds" arguments  
>> should be optional, defaulting to false and 0 respectively, and  
>> possibly in combination with the above suggestion.
>
> You mentioned [2] that this is a bit weird because the function can be
> quite long and then it reads poorly for anonymous functions.
>
> I see your point, but we already have that problem with setTimeout and
> setInterval. And I feel like it's more important to have consistency
> where possible with these well-established APIs than fix this issue.

I don't think consistency on argument order is critical, but I see  
your point. We won't be 100% copying the argument order anyway since I  
don't think it is worth carrying over the quirky extra argument  
behavior of setTimeout and setInterval.

Regards,
Maciej
Received on Friday, 3 October 2008 21:02:24 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:28 GMT