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