- From: Sean Hogan <shogun70@westnet.com.au>
- Date: Tue, 14 May 2013 13:27:46 +1000
- To: Boris Zbarsky <bzbarsky@MIT.EDU>
- CC: public-script-coord@w3.org
On 13/05/13 12:31 PM, Boris Zbarsky wrote: > On 5/12/13 8:38 PM, Sean Hogan wrote: >> If I setTimeout a task, which itself setTimeout's a task, which >> setTimeout's a task, etc, etc >> then each task is delayed by, say 4, 8, 12, 16 msec. > > Yes, I did have the caveat about this. > >> Moreover the page can be reflowed between tasks. > > _ANY_ async solution will have this property. What does it even mean > to be async if you don't allow reflows in the meantime? > Jonas addressed this. Maybe I should have left "asynchronous" out and referred to the Futures spec - http://dom.spec.whatwg.org/#futures - for 'queue a task'. >> why not expose it to the scripting environment? > > IE already does, as setImmediate. It may be worth looking at the > existing reasons people have given for not implementing that... > > But yes, the answer may end up being that setImmediate gets > implemented, in spite of the (well-founded, imo) concerns about abuse. > Surely DOM Future could be abused worse than setImmediate? Sean
Received on Tuesday, 14 May 2013 03:28:14 UTC