Re: ISSUE-70: what to do about window timers?

On Apr 6, 2006, at 6:50 PM, Ian Hickson wrote:

> On Thu, 6 Apr 2006, Maciej Stachowiak wrote:
>>
>> Is there any reason this would be better than (Plan B):
>>
>> B. Window contains inelegant ECMAScript-specific Timer API for  
>> compatibility
>> but also adds new elegant and language-neutral Timer API.
>
> Please, please don't add a new timer API to JavaScript.

That would be Plan C, then. Robin's proposal was to add a new timer  
API, including to JavaScript, but as a separate spec.

I would like to note that if we don't add a timer API that works  
across languages, the SVG WG almost certainly will, and that  
effectively means all browsers that support SVG have to implement it  
on every global object anyway. (Or rather, we'll have a much harder  
time convincing them to remove it.) So realistically the only  
question at hand is "who defines it and in what spec".

I think the biggest problem with the JS timer API is the numeric IDs  
that you get back from the set functions and pass to the cancel  
functions. You can't just pass the number as a timer ID to other code  
that may wish to cancel the timer. You need to know the window object  
that started the timer and whether it was a Timeout or an Interval.  
So it's not obvious what to use for a sane concept of timer ID. I  
would guess existing code that cares stores just the number, which  
means it could break in a CDF situation and requires implicit  
knowledge in cancel code of what kind of timer it was.

Less severe issues with current API:

- You can't change the interval of a running timer.
- You can't have different initial and repeat intervals.
- Timer callback doesn't get the Timer as an argument, so if you want  
to make, say, a repeating timer that stops itself after some number  
of repeats, you have to store global state out of band to let it find  
its own timer ID.
- You can't check how much time is left on a timer (sometimes  
interesting for some uses).

So adding a better API would have actual benefits for JavaScript  
developers and not just be a gratuitous duplication.

I would also add that it's entirely possible to define a Timer API  
that solves these issues, but nontheless is implementable as JS  
library code, in case anyone wants to use it in UAs that don't  
support it directly. (Yes, third-party JS libraries could just  
provide that - no, I don't think that's a reason not to do it.)

Regards,
Maciej

Received on Friday, 7 April 2006 02:09:22 UTC