Re: transitions vs. animations

On Mar 19, 2010, at 1:40 PM, Håkon Wium Lie wrote:

> Simon Fraser wrote:
> 
>> Transitions provide interpolation between existing CSS property
>> value changes. In other words, if the 'left' property changes from
>> 10px to 100px, without a transition it will change instantaneously.
>> With a transition, it will change over time. This allows
>> transitions to have a nice fallback behavior in older browsers
>> which don't support them; users won't see the nice smooth changes,
>> but the changes still happen.
>> 
>> The key concept with animations is that you apply style in order to
>> put an element into an animating state. Just as you use CSS to set
>> the highlight state of a button, you can use CSS to put an element
>> into a "bouncing" state. That state may be temporary (finite number
>> of iterations) or permanent (infinite). The properties in the
>> animation keyframes are applied after all other properties, and
>> override them, so animations don't provide nice fallback behavior
>> (older browsers simply won't show the animations).
>> 
>> I think these concepts are different enough to warrant keeping them
>> separate.
> 
> I agree that having a fallback (transitions) or not (animations) is a
> difference. But I'm unsure if that difference warrants one extra
> specification and another set of properties. And I don't think the
> "states" are fundamentally difference -- the "states" in transistions
> just seem to be a subset, or a cousin, of the states in "animations".
> 
> A better reason for having two different specs/property-sets would be
> if it makes sense have both on the same element. I.e., are there
> any use cases where you would set both a transition and an animation
> on the same element?

Yes, you could easily run a transition on one property of an element while animating
another, or apply an animation while an element is in the middle of a long transition.

Tying transitions and animations together would very much restrict the flexibility of both,
and unnecessarily constrain what authors can do.

Simon

Received on Friday, 19 March 2010 23:22:53 UTC