W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2013

Re: Future feedback

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Sun, 12 May 2013 22:31:10 -0400
Message-ID: <5190506E.6030309@mit.edu>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:49 UTC