Re: transitions vs. animations

On Apr 7, 2010, at 8:17 AM, Brad Kemper wrote:

> 
>> ...- play-in animations are just finite
>> iterations, while play-during are infinite.  There is no concept of
>> "events" or "states" invented to handle them; they trigger purely
>> through CSS values changing, exactly like the current Animations
>> draft.  
> 
> Animations play for anything that you can write a selector for, including one with no pseudo-class. The values do not need to change to trigger them; they can be there as soon as the element is loaded with its specified values. 

Here's the basic problem with Animations. Currently they are triggered by two things. If animation-name changes, the animation starts (unless it changes to none in which case any current animation stops). If play-state changes animation resumes (if set to running) or stops (if set to paused). That provides a range of use cases where a change in style causes an animation to start or stop. But it doesn't provide for use cases where a one-shot animation wants to be retriggered again after it has run (as in Simon's slide+bounce use case). Solving that one problem would enable many more use cases and would bring animations closer to the transition model.

-----
~Chris
cmarrin@apple.com

Received on Wednesday, 7 April 2010 17:51:09 UTC