Bringing setTimeout to ECMAScript

[John J. Barton]

On 11:59 AM, Boris Zbarsky wrote:
>
> Nowadays the clamp is there because sites use |setTimeout(f, 0)| when 
> they really mean "run this at 10Hz" and if you run it with no delay 
> then they swamp your event loop and possible render "wrong" (e.g. the 
> text disappears before the user has a chance to read it).
I'm not convinced that this  is the meaning. I use |setTimeout(f, 0)| to 
mean "schedule f after this event completes" or "push |f| onto the event 
queue"; I think that is the common meaning.   A delay value of zero is 
perfectly sensible, but we mean "zero seconds after other queued 
events", not "zero seconds after this event".  We assume (without real 
evidence I suppose) that UI and IO events can be queued while our JS 
(the caller of |setTimeout(f, 0)|) runs.

The essential logic of |setTimeout(f, 0)| is cooperative multiprocessing 
yield: we believe that our current event processing could be long enough 
to interfere with user interaction and |f| can be delayed without 
serious impact on the UI.   We have no reason to pick a value other than 
zero.  If we want to give the user 3 seconds to read text we use 3000.

The "swamp the event loop" case is logically unrelated to this case, 
just like setInterval is unrelated. Multiple repeated calls to 
|setTimeout(f,0)| are bugs and setInterval of zero would be a bug.  Of 
course the browser has to deal with theses cases,  but the lower limit 
on setTimeout seems like crude solution.

jjb