- Browser Support
- CSS Animations
- The @Keyframes Rule
- animation-* Properties
- Animation Events
- Transition or Animation
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Transition or Animation
One of the questions you might be asking yourself is when you should use a transition and when you should use an animation. You can create most of the examples in this and the previous chapter using either transitions or animations. So which should you choose when you want to animate something?
Similarities
You can start to answer that question by thinking about the similarities and differences of transitions and animations. One thing they both have in common is their properties. About half the animation-* properties have a counterpart transition-* property. The timing functions, for example, are the same, except for using the word animation or transition to start the property name.
Both can listen for changes to CSS property values and interact with JavaScript events. Triggering events like those in the following list can make changes in CSS property values that start either animations or transitions:
- :hover
- :link
- :active
- :visited
- :focus
- :checked
- :disabled
You can also start transitions and animations through changes in media queries or class changes via simple JavaScript that changes the appropriate property values.
Differences
Let’s switch gears and think about the differences. Although both transitions and animations can run in response to a trigger, only animations can run automatically on page load. Transitions require a trigger to run. If you need your animation to run automatically, you have only one choice.
Transitions are limited to initial and final state keyframes. Animations can build as many intermediate keyframes as necessary or desired. This gives you more control over your animation and allows you to create more complex and sophisticated animations. Transitions are for simple animations.
Transitions don’t change properties. You set values up front in the CSS intrinsic to the specific elements. Transitions define the change only between property values and not the values themselves. Animations can change property values inside each keyframe. The values don’t need to be declared outside the animation either, making animation more dynamic.
Transitions can’t loop. They run once when triggered and then run in reverse when the trigger is removed. Otherwise they don’t run. You can loop animations as many times as you want and set them to run in reverse or alternate between forward and reverse. Once again CSS animations offer you more control than CSS transitions.
Once you start using JavaScript to further control your transitions and animations, it quickly becomes clear that transitions are easier to work with. It’s more difficult making changes to the values inside keyframes than it is the intrinsic values on elements.
As a general rule, you’ll write more code using CSS animations as opposed to CSS transitions, assuming both are trying to do the same thing.
When you get down to it, animations are abstractions of transitions. States are pulled out from the specific case to work in a more modular fashion. Transitions are a specific case of the more general animation. If you find yourself using the same transition code over and over, you might decide to rewrite it as an animation.
Choosing Transitions or Animations
If what you want to create is a simple animation between two states, keep your code simpler and lighter, or use JavaScript in the animation, then transitions are probably a better choice.
If what you want to create is going to be something more complex with a need for more than two states or if your animation needs to loop or run in either direction and start itself, animations are your choice.
In general, choose CSS transitions for simple animation that require less control, but better integration with JavaScript. Choose CSS animations for more complex and flexible animations that offer you greater control.
There’s one question in regard to transitions and animations you might still be wondering about: Does one perform better than the other? To answer that question, let’s look at performance.
Performance
The short answer is that you shouldn’t see any performance difference between transitions and animations, assuming both are doing the same thing in the same way. Performance has more to do with what properties are being changed as opposed to whether those changes happen through transitions or animations.
To render webpages, a browser first calculates the CSS styles that apply to the HTML elements. Then it lays out the page by working through the geometry and position for each element. Next comes painting where pixels are filled in before finally drawing everything to the screen on composite layers. Browsers use two different execution threads to do all these things and render webpages: the main thread and the compositor thread.
The main thread is responsible for laying out pages and painting elements. It computes the CSS styles applied to HTML elements, and it runs JavaScript. The compositor thread draws bitmaps to the screen via the graphic processing unit (GPU). It determines which parts of the page are visible or will soon be visible. It determines what’s likely to be scrolled to next and moves the parts of the page when someone does scroll. Both threads communicate with each other, sending and requesting information.
The main thread tends to be busier for longer periods of time, and while busy it’s not responsive to input. The compositor thread, on the other hand, tries to remain responsive because it has to be aware of scrolling.
Main thread responsibilities are more CPU intensive, while compositor responsibilities look to the GPU more frequently. GPUs can draw the same bitmaps over and over in different positions quickly. They can scale and rotate bitmaps quickly as well.
To create more performant animations, you generally want to stay away from layout and painting changes and instead make compositing changes. Compositing changes can be made on separate compositing layers, so the browser doesn’t need to repaint or rework the layout of other layers.
TABLE 4.1 lists CSS properties that affect layout and painting.
TABLE 4.1 CSS PROPERTIES
PROPERTIES THAT AFFECT LAYOUT |
PROPERTIES THAT AFFECT PAINTING |
width |
color |
height |
border-style |
padding |
border-radius |
margin |
visibility |
display |
background |
border-width |
text-decoration |
border |
background-size |
top |
background-image |
position |
background-position |
font-size |
background-repeat |
float |
outline-color |
text-align |
outline |
overflow-y |
outline-style |
font-weight |
outline-width |
overflow-y |
box-shadow |
left |
|
right |
|
font-family |
|
line-height |
|
vertical-align |
|
clear |
|
white-space |
|
bottom |
|
min-height |
It turns out that there are currently five things browsers can animate cheaply in terms of performance: translation, scale, rotation, opacity, and some CSS filters. The first three should have you thinking back to transforms. Anything beyond animating these five types of properties probably won’t run as smooth.
Consider moving an element to a new location, which is something you’ve done a few times throughout this book. You can use a transform to move the element, or you can adjust properties like top and left. The former uses the GPU, while the latter uses the CPU. You want to take advantage of the GPU where possible and take advantage of the hardware acceleration it provides. If you think back to the first example in this chapter, you moved an element by adjusting its left value and then by applying a translation transform. The approach using translation ran smoother, and this is why.
It won’t matter whether you use CSS transitions or CSS animations when it comes to performance, but you should think about performance when creating either. Transforms, opacity, and some CSS filters don’t require layout or painting changes and so are preferred properties for animating.
This doesn’t mean you shouldn’t animate other properties. You can still create a smooth animation with other properties. Just realize that if you have the choice, you should opt for changing a transform, opacity, or CSS filter instead of another property.