W3C home > Mailing lists > Public > www-style@w3.org > February 2014

[css-transforms][filter-effects][web-animations] Thoughts about adding animations

From: Brian Birtles <bbirtles@mozilla.com>
Date: Mon, 17 Feb 2014 15:53:10 +0900
Message-ID: <5301B1D6.1070900@mozilla.com>
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

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:19 UTC