Re: transitions vs. animations

On Apr 8, 2010, at 12:38 PM, Tab Atkins Jr. wrote:

> I've seen a few sites (can't find a URL right now, sorry) that have a
> very cool animation on their main navigation using javascript.  The
> text of the nav link is naturally at the top of the block, but when
> you hover over it it drops the bottom quickly, bounces, and settles
> down.  When you unhover, it flies up and bounces the same way.
> 
> Without any fanciness, this is just a change in positioning.  With
> transitions, we can trivially make this a smooth slide from being
> positioned at the top to being at the bottom.

Actually, you can't transition from "top: 0" to "bottom: 0", just as you can't
transition between "height: auto" to "height: 50px". The reason is that the
user agent would have to do a layout in order to compute the final state
before starting the transition, and then, if some other state changes while
the transition is running, that final state becomes invalid.

> But to do the "fly and
> bounce" thing, you need an animation.  I want to use this idea of
> attaching an animation to a transition, as it generally *works* the
> way I want, but I want to override the default transition slide with
> my own keyframe path.

You could do the bounce effect with a more elaborate timing function.

> I think this sort of thing will be reasonably common, and so I believe
> that transition-animations should override the transition they're
> attached to, if they manipulate the same property.  I think we have
> reasonable freedom to later add an ability for the
> transition-animation to combine with the transition, rather than
> straight overriding it, but I don't think that's necessary *right now*
> to get it working.

If we end up attaching animations to transitions, then I agree that the
animation should override the transition. As I said in another email,
let's deal with additivity separately.

Simon