Re: transitions vs. animations

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.

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.

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome

Received on Saturday, 20 March 2010 14:20:02 UTC