W3C home > Mailing lists > Public > public-web-perf@w3.org > July 2011

Re: Open Source Cross-Browser setImmediate in JavaScript

From: James Robinson <jamesr@google.com>
Date: Thu, 7 Jul 2011 10:32:05 -0700
Message-ID: <CAD73mdJKSSoPWZH7KjUN=Oknk47s9tbubnfu12RCSiDv_ZvRLg@mail.gmail.com>
To: Paul Bakaus <pbakaus@zynga.com>
Cc: Boris Zbarsky <bzbarsky@mit.edu>, "public-web-perf@w3.org" <public-web-perf@w3.org>
I know that at some point Dean Jackson was working on an API to scrub CSS
animations - you should bring up your use cases on the www-style or
public-fx lists and see what the status of that work is. It's definitely
something we need.

- James
On Jul 7, 2011 8:47 AM, "Paul Bakaus" <pbakaus@zynga.com> wrote:
> That's interesting and sad at the same time..
> It's a pain that transitions and animations currently can't be trivially
> started, stopped, restarted and overridden. There still needs to be a lot
> of work put into CSS Animations and transitions before we can actually
> expect normal developers to sanely work with them.
> Am 07.07.11 17:37 schrieb "Boris Zbarsky" unter <bzbarsky@MIT.EDU>:
>>On 7/7/11 10:11 AM, Paul Bakaus wrote:
>>> That's the thing ญ I'm wondering out the same thing, so I'd love to know
>>> where the difference really is. setTimeout often feels to slow ญ for
>>> instance, to start or restart CSS animations or transitions, you have to
>>> wait for a relayout, which is where I'm using setTimeout.
>>Of course that doesn't actually work correctly, per
>>unless you use a pretty long timeout value...
>>> My guess is that setImmediate wouldn't wait for layout batches to be
>>> finished, but only JS
>>If it's running on the same event loop as layout (which as far as I can
>>tell it is), then it would have to wait for layout to not be running.
>>> so you might call it while code is executing and
>>> would know it's executed right after the rest of your current stack has
>>> been worked off, but before layout changes.
>>I don't think it offers any such guarantees. Certainly not as currently
>>Note that layout can change synchronously if something flushes it, by
>>the way, so there's no async setup that can guarantee running before
>>layout changes.
Received on Thursday, 7 July 2011 17:32:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:31 UTC