Re: Open Source Cross-Browser setImmediate in JavaScript

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
>><http://lists.w3.org/Archives/Public/public-web-perf/2011Jul/0006.html>,
>>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
>>specified.
>>
>>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.
>>
>>-Boris
>>
>
>