Re: transitions vs. animations

On Mar 20, 2010, at 7:19 AM, Håkon Wium Lie wrote:

> Also sprach David Singer:
> 
>>>>> 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?
> 
>> an element that rotates continuously (e.g. a clock hand), that is
>> moved to different places smoothly on user input?
>> rotation=animation, smooth moving=transition.
> 
> In my mind, these are both animations triggered by different events.
> 
> In the current model, one set of properties are tied to user input (it
> seems that most transitions are combined with :hover, no?) and another
> set of properties are not. We call the first set "transitions" and the
> second set "animations". Transitions have slightly simpler syntax with
> no need for @-rules, while animations can be more expressive.

It's a misconception that most transitions are triggered directly by
user events. In the majority of the content that we've written, transitions
are triggered by JS changing the class name on an element, which
is normally associated with some state change in the content. This may
be initiated via a user event, or it may not.

Let me repeat the conceptual difference between transitions and
animations:
Transitions: automatic interpolation between existing CSS property values.
Animations: using rules to put an element into an animating state.

> I propose that we reduce the set of properties to one, have a unified
> syntax, use one name (animations) and add methods for attaching
> animations to different type of events, including :hover and (say)
> :anti-hover. I don't have a concrete proposal for this, the potential
> benefits seem valuable enough to warrant a whiteboard discussion.

I'd be happy to talk about this at the F2F.

Simon

Received on Saturday, 20 March 2010 15:51:17 UTC