- From: Brian Birtles <bbirtles@mozilla.com>
- Date: Mon, 17 Feb 2014 15:53:10 +0900
- To: Dirk Schulze <dschulze@adobe.com>, "public-fx@w3.org" <public-fx@w3.org>
- CC: "www-style@w3.org" <www-style@w3.org>
(Cross-posting to www-style@w3.org. Please send replies to public-fx@w3.org) Hi, Dirk and I had a chat about adding animations on #svg and had a few ideas/questions. * Additive animation, what is it? Basically, the ability to define an animation that, rather than clobbering whatever value is already defined for a property, builds on it. Furthermore, it also between animations so that, for example, you can apply a 'spin' animation and a 'swell' animation to the same element and they combine into something beautiful. SVG has this, CSS doesn't (yet). * What's the problem? For most property types addition is fairly straightforward--it can often be defined using the same weighted-sum formula used for interpolation. But it's not always like that. Consider 'filter' and 'transform': * Use case #1: Two fade-out animations added together. Both animations start at the same time, and animate the filter property from 'opacity(1)' to 'opacity(0)'. Consider what happens when we try to add their intermediate results: If we match up the filter functions and add their components we end up with an animation that remains at 'opacity(1)' for half the duration then animates to 'opacity(0)'. If we just append the filter functions to a list we end up with a continuous animation from 'opacity(1)' to 'opacity(0)' with a kind of ease-out effect. * Use case #2: We apply an additive animation that goes from 'blur(0px)' to 'blur(10px)' to an element with 'filter: sepia'. If we match up filter function types we'll notice they don't match and either blow away the sepia effect or drop the animation. If we just append to the list of filter functions we get an element with a sepia effect that is gradually blurred. * Similar use cases occur for 'transform', e.g. applying a rotate animation to an element with a translation applied. * Observation: There are several ways of doing addition. For example, for transform lists you have at least: (a) Match up functions and add components (b) Append to the end of the list (c) Append to the end of the list and consolidate into a single matrix (i.e. post-multiplication) Note that lot of these kinds of addition are not commutative. For animation we use a well-defined priority stack to determine the order. * Suggestion: It might be useful to think of roughly two types of addition: 'component addition' and 'independent addition'. - For combining independent animations I think you want 'independent addition', e.g. appending filters to the end of the list - For other uses, 'component addition' is probably useful. For example, if CSS adds an 'additive' syntax independent of animations, 'component addition' is probably the desired behavior. Likewise for cumulative animation where each iteration of an animation builds on the previous iteration, you probably want 'component addition'. (SVG's animateTransform actually has both of these, although that is possibly only by accident.[1]) (* Detail: if you have a *lot* of independent additive animations with 'animation-fill-mode: forwards' then I guess the serialization of 'transform' or 'filter' could become very long if addition means appending to the list. I'm not sure how to fix this. We could consolidate transforms when the animation starts filling but I'm not sure how that would help filters.) (* Another detail: The guys behind the GSAP animation library[2] were encouraging the people working on Web Animations to investigate having predefined slots for each kind of transform animation so that they always add in the same order. We have yet to find a compatible way of doing this, however.) * Question: Dirk says the CSSWG ruled out the idea of adding transform animations by appending to the list of transform functions. Is that correct? If so, why? * Meta: I think CSS Transforms should come under the FXTF umbrella since it is defining features in SVG but Dirk mentions that no-one reads public-fx. If you're not following public-fx, please do! Best regards, Brian [1] http://brian.sol1.net/svg/animatetransform-issues/accumulation-of-transformations/ [2] http://www.greensock.com/gsap-js/
Received on Monday, 17 February 2014 06:53:40 UTC