CSS3: Animations vs. Transitions

In CSS, you have two techniques for visualizing change
that are competing for your attention:
Animations &
Transitions. In this article, let's examine the
similarities and differences between them so that you can
know when to use which.

Similarities

From a distance, both animations and transitions are very similar.
They both allow you to:

Specify which CSS properties to listen for changes on

Set timing (easing) functions to alter the rate of going from a
one property value to another

Specify a duration to control how long the animation or
transition will take

Programmatically listen to animation and transition-specific
events that you can then do with as you wish

Visualize CSS property changes.

Beyond this point, though, you will see that animations and
transitions diverge a bit and let their uniqueness shine through. Let's
look at those unique qualities in greater detail.

Differences

Animations and transitions show their differences when it comes to
how you trigger them to play, whether they loop easily, how complicated of a transition you can
define, how formal you must be in being able to use them, and how well
they play with JavaScript. Let's
explore those topics in greater detail.

Triggering

One of the major differences between animations and transitions can
be seen in how you trigger them to start playing.

A transition only plays as a reaction to a CSS property that has
changed. A common scenario is one where you use the
:hover pseudo class to change the value
of a CSS property:

To use the example visualized here, if a transition is defined, you
would be able to see the circle growing from its normal size to its
hover size. Another way of triggering a transition is to use
JavaScript to
programmatically add or remove CSS classes to simulate a CSS
property change. Rounding out our ways of making a property change, you
can use JavaScript to set an inline style that changes a property your
transition is listening for.

Animations, on the other hand, don't require any explicit triggering.
Once you define the animation, it will start playing automatically. Yep,
that's how animations roll!

Looping

This is pretty simple. Animations can be easily made to loop by
setting the animation-iteration-count
property. You can specify a fixed number of times you want your
animation to repeat:

animation-iteration-count: 5;

If you just want your animation to loop forever, you can do that as
well:

animation-iteration-count: infinite;

Transitions, on the other hand, don't have a property that specifies
how many times they can run. When triggered, a transition runs only
once. You can make a transition loop by fiddling with the
transitionEnd event, but that isn't
particularly straightforward - especially when compared with animations.

Defining Intermediate Points / Keyframes

With an animation, you have the ability to define keyframes which
give you more control over your CSS property values beyond just the
start and the end:

You can set as many keyframes as you want, and when your animation
plays, each keyframe will be hit with the specified property changes
reflected. This allows you to create the kinds of involved animations
that help HTML5 compete with more established animation technologies
like Flash more effectively.

With a transition, you don't have much control over anything beyond
the end result:

A transition simply goes from an initial state to the final state.
You cannot specify any points in-between like you can with an animation,
so a transition might not be a good choice if you are trying to create
the next
Teen Girl Squad sensation or a complex animation.

Specifying Properties Up-Front

The next thing I will describe is how formal animations and
transitions are when it comes to defining a transition between CSS
property values.

On the formal side, you have transitions. Every CSS property you want
recognized by your transition must be explicitly represented.

Upon hover, I specify a different value for both
background-color as well as
width. My transition specifies only
background-color though. This means your
browser is only listening for changes on the
background-color property.

If I wanted my transition to affect both the
background-color and width
properties, I will need to explicitly add another
transition entry for
width:

What About
transition: all?

You do not have to specify every property that you care about
when using a transition. You could simplify your life by using the
all value instead:
transition: all .5s ease-in. I do
not recommend this because you will take a performance hit. Your
browser is now listening for a whole lotta properties as opposed to
just a few that you know you will be modifiying. Unless you have a
strong need to do this, I would recommend specifying each CSS
property you wish to transition individually.

With animations, you have the ability to specify properties at a whim
in each keyframe without having to do anything that resembles declaring
them:

In this example, the height and
background-color of whatever element
I am animating will smoothly transition when the appropriate keyframe is
reached - even if the property was never listed before!

Interaction with JavaScript

In many cases, a transition or animation you declare in CSS will be
good enough. You specify in CSS your starting value, the ending value,
and any intermediate values that you want your properties to take. Your
animation or transition will read these values and take care of business
from there. This scenario works best when what you are wanting to do is
predefined. There will be times when you want to alter the value of a
property that you are animating based on some external input - a mouse
click, the result of some calculation, etc.

For such interactions, property values entirely predefined in CSS is
a bit limiting. You can decide in such cases to rely on JavaScript, but
going all-in on JavaScript alone may be too extreme as well. What you
want is a hybrid approach where your animation or transition is declared
primarily in CSS but certain aspects of which are manipulated using
JavaScript.

When it comes to combining JavaScript with either an animation or
transition, there is no contest - you almost always want to use
a transition. Using an animation with JavaScript is
possible...in much the same way it is possible to win at the
cinnamon challenge. It isn't impossible to make it work, but chances
are, you don't want to do it. The reason for this difference has to do
with how transitions and animations work.

Animations are very specific in what they do. The @keyframes rule clearly lays out the
path your animation will take as it is running. Attempting to change
your animation in JavaScript requires a very complicated series of steps
that involves actually modifying the @keyframes
style rule itself. If you've ever had to manipulate CSS that lives
inside a style rule, you know that it is pretty unintuitive.

Contrasting the predefined path of an animation is the transition.
Transitions are not as well defined as they may seem. Your transition
will kick in when a property it is listening for changes. This property
change can be set entirely via only CSS:

The transition doesn't care how the properties it is listening
for changes. As long as the property changes somehow, the transition
will get to work. This means, for interactive scenarios that don't
involve a predefined starting and ending point, you can do a lot of
interesting things by deferring all transition-related heavy lifting by
using the transition declaration. The actual values of the properties
you are wanting to transition can be specified using JavaScript.

Click anywhere in the gray box to have the circle move to the point
of the click. Keep clicking around to see the circle keep moving.

How this works is pretty simple. The actual movement is handled by
the transition. Knowing where to
transition to is handled by the JavaScript which sets the
top and left
property values on the element. Because the transition is listening for
changes to the top and
left properties, any change results in
your transition kicking in. The end result is exactly what you wanted.
Best of all, you didn't have to write any JavaScript for handling the
actual movement itself. As a bonus, because the transition is declared in CSS, your
browser optimizes it heavily so that it runs really smoothly.

This friendship between transitions and JavaScript is so full of win,
it hurts just writing about.

Conclusion

There you have it - a
candid look at what makes transitions and animations similar yet so very
different. My general approach for determining when to use which goes
like this:

If what I want requires the flexibility provided by having
multiple keyframes and easy looping, then I go with an animation.

If I am looking for a simple from/to animation, I go with a
transition.

If I want to manipulate the property values that I wish to
animate using JavaScript, I go with a transition.

Now, with enough effort and JavaScript tomfoolery, you can neutralize
any deficiences I list in deciding whether to use a transition or an
animation. My recommendations are based on the common cases where you take
a transition or animation mostly at face value. Herculean efforts to
change their default behavior is admirable but often unnecessary.

Did You Like This?

Getting Help

If you have questions, need some assistance on this topic, or just want to
chat - post in the comments below or drop by our friendly forums
(where you have a lot more formatting options) and post your question. There are
a lot of knowledgeable and witty people who would be happy to help you out

Share

Did you enjoy reading this and found it useful? If so, please share it with
your friends:

If you didn't like it, I always like to hear how I can do better next time.
Please feel free to contact me directly via e-mail, facebook, or twitter.

Kirupa Chinnathambi
I like to talk a lot - A WHOLE LOT. When I'm not talking, I've been known to write the occasional English word. You can learn more about me by going here.

MORE READING

HELLO and welcome

This site was started in 1998 with the goal of teaching designers and developers how to create cool things for the web. That we'd still be around today was never part of the plan. We figured the whole internet thing would have died down around 2004. I guess we were off in our calculations.