- From: Andy Matuschak <andy@andymatuschak.org>
- Date: Wed, 01 Jul 2009 07:24:38 +0000
- To: www-style@w3.org
- Cc: dino@apple.com
- Message-Id: <6D4B7A2B-A0E0-4776-BA5B-4F9B9689D341@andymatuschak.org>
Hello, folks! I'm trying to use CSS Animations in a larger project, and I've run into a few limitations that are giving me trouble. I've detailed them here in hopes that non-hideous workarounds might be suggested or that they might be fixed. PLAY/PAUSE I imagine this is a common request. Imagine a button animating into place, but which would stop if it were clicked. And for an authoring tool, the artist would need to be able to play and pause. The animation-play-state property is the obvious candidate for a solution, but the spec suggests it's going to be removed. I'd like to add my vote to it staying around. The suggested workaround (save the computed style; remove the animation; apply the style) doesn't work because of a race condition: the animation continues in a background thread between steps 1 and 2, so the animation appears to flick a few frames backwards after step 3. At least in WebKit's implementation. But this seems intrinsic to the concurrent nature of animation. SCRUBBING AND FEEDBACK While these tools might not be useful directly on a web page, any tools which view or author content with CSS Animations would benefit enormously from hooks for the current time. Implementing an accurate playhead for a given animation requires the ability to query its progress. A client which wanted to be able to scrub around the animation (extremely useful for content creation) would need to be able to set the animation's position. One can also imagine an animator wanting to see his work in slo-mo or high-speed to perform detailed critiques or quick reviews of a change. When implementing these features, one must keep in mind the timeline being affected. If I ask an animation to move to 2 seconds in, does that count the delay property's time? In some cases, that would be essential (scrubbing all animations at once); in others, that behavior would be detrimental (scrubbing just one animation). The solution must also handle the case in which an animation is added to an element after page load. FILL MODES Picture the following simple animation: - a box moves onto the page from the left - then another box moves onto the page from the right - they stay there In WebKit's implementation of CSS Animation, an element's style is reset to its values at time 0 after the animation finishes. I'm not clear on whether that's intended (I only see it in Apple's docs[1], not the spec), but this behavior makes it very difficult to implement the simple animation described above. Perhaps a good compromise would be something like Core Animation[2] and SIML's "fill modes", which specify how the values are clamped before and after an animation. Developers could then choose to have the style stick around after the animation had completed. EPILOGUE Thanks very much for your consideration. If CSS Animations' functionality is expanded in a few (hopefully) small ways, developers could create some really useful tools—which would in turn promote adoption of the new standard. - Andy Matuschak [1] http://developer.apple.com/safari/library/documentation/InternetWeb/Conceptual/SafariVisualEffectsProgGuide/Animations/Animations.html#//apple_ref/doc/uid/TP40008032-CH6-SW1 [2] http://developer.apple.com/documentation/graphicsimaging/Reference/CAMediaTiming_protocol/Introduction/Introduction.html#//apple_ref/doc/constant_group/Fill_Modes
Received on Thursday, 9 July 2009 16:03:18 UTC