- From: Paul Bakaus <pbakaus@zynga.com>
- Date: Thu, 7 Jul 2011 08:46:57 -0700
- To: Boris Zbarsky <bzbarsky@MIT.EDU>, "public-web-perf@w3.org" <public-web-perf@w3.org>
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 >
Received on Thursday, 7 July 2011 15:47:37 UTC