- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Sun, 12 May 2013 22:31:10 -0400
- To: Sean Hogan <shogun70@westnet.com.au>
- CC: public-script-coord@w3.org
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? > I believe setImmediate also allows the page to reflow before the task is > executed. Yes, like every async solution. > If I queue a task, which itself queues a task, which queues a task, etc, > etc > then these tasks are executed asynchronously but not delayed. > Also the page is not unnecessarily reflowed. The setup you describe can have reflows between task executions. > 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. > To repeat what I said above: > since all browsers already have this feature internally (or will need it > for DOM Futures) > why not expose it to the scripting environment? I would be much happier with exposing this one, for sure, since it doesn't have any obvious abuse potential. -Boris
Received on Monday, 13 May 2013 02:31:41 UTC