animation-delay<\/code><\/a>, but don’t necessarily want the viewer to visit the page and have some things not moving, waiting for their delay. <\/p>\nYou can set animation-delay<\/code> to a negative number, and it will push the playhead back in time, so that all animations are running when the viewer shows up. This is particularly useful when the animations share the same keyframe values and are differentiated in movement only by the delay. <\/p>\nYou can use this concept for debugging. Set animation-play-state: paused;<\/code> and then adjust the delay to different negative times. You’ll see the animation in different paused states along the tween. <\/p>\n.thing {\r\n animation: move 2s linear infinite alternate;\r\n animation-play-state: paused;\r\n animation-delay: -1s;\r\n}<\/code><\/pre>\nExample:<\/p>\n
See the Pen LVMMGZ<\/a> by CSS-Tricks (@css-tricks<\/a>) on CodePen<\/a>.<\/p>\nIn a fun demo, we see the two robotters hovering at a very slightly different time in order to feel a little more natural. We give the purple robotter a negative delay when we declare the hovering animation so that he’s moving when the viewer first sees the page.<\/p>\n
.teal {\r\n animation: hover 2s ease-in-out infinite both;\r\n}\r\n \r\n.purple {\r\n animation: hover 2s -0.5s ease-in-out infinite both;\r\n}\r\n \r\n@keyframes hover {\r\n 50% {\r\n transform: translateY(-4px);\r\n }\r\n}<\/code><\/pre>\nSee the Pen Robotter Love<\/a> by Sarah Drasner (@sdras<\/a>) on CodePen<\/a>.<\/p>\nThe Pains of Multiple Transform Values<\/h3>\n
For best possible performance, you should also be moving and changing things with transform<\/code><\/a>, and save yourself from the cost of repaints with margin, or top\/left and the like. Paul Lewis has a great resource called CSS Triggers<\/a> that break down these costs in an easy-to-see table. The gotcha here is that if you try to move things with multiple transforms, there are a number of problems. <\/p>\nOne big problem is ordering. Transforms will not be applied simultaneously as one might expect, but rather, in an order of operation. The first operation done is the one furthest on the right, then inwards. For example, in the code below, the scale will be applied first, then the translate, then the rotate.<\/p>\n
@keyframes foo {\r\n to {\r\n \/* 3rd 2nd 1st *\/\r\n transform: rotate(90deg) translateX(30px) scale(1.5);\r\n }\r\n}<\/code><\/pre>\nIn most situations, this is not ideal. It’s more likely that you’d rather all to happen concurrently. Furthermore, this becomes far more complex when you begin splitting the transforms into multiple keyframes with some values at the same time and some not, like so:<\/p>\n
@keyframes foo {\r\n 30% {\r\n transform: rotateY(360deg);\r\n }\r\n 65% {\r\n transform: translateY(-30px) rotateY(-360deg) scale(1.5);\r\n }\r\n 90% {\r\n transform: translateY(10px) scale(0.75);\r\n }\r\n}<\/code><\/pre>\nThis will lead to somewhat surprising, and less than ideal results. The answer, unfortunately, is often to use multiple nested <div><\/code>s, applying a single translation to each, so that no conflicts arise.<\/p>\nSee the Pen Show Order of Operations Transform Fail<\/a> by Sarah Drasner (@sdras<\/a>) on CodePen<\/a>.<\/p>\nThere are some alternatives, such as using matrix transforms (not intuitive to code by hand) or to use a JavaScript animation API such as GreenSock<\/a>, where there is no ordering sequence for multiple transform interpolations.<\/p>\nThe multiple div implementation can also help with troubling bugs with SVG. In Safari, you can’t declare opacity and transform in animation at the same time — one will fail. You can see the workaround in action in the first demo in this article. <\/p>\n
In early August 2015, independent transform declarations<\/a> have moved into Chrome Canary. This means we won’t have to worry about ordering much longer. You’ll be able to declare rotate<\/code>, translate<\/code>, and scale<\/code> separately. <\/p>\nDevTools Timing Helpers<\/h3>\n
Both Chrome<\/a> and Firefox<\/a> now ship with some tools specificially for helping work with animations. They offer a slider for controlling the speed, a pause button, and UI for working with the easing values. Slowing things way down, and seeing the animation at particular stopped points is pretty darn helpful for debugging CSS animations.<\/p>\nThey both use Lea Verou’s cubic-bezier.com<\/a> visualization and GUI. This is extraordinarily helpful, as you no longer have to do the back-and-forth from cubic-bezier.com to text editor to proofing. <\/p>\nThese tools allow us to fine-tune our animations much more intuitively. Here’s a look at the UI offered in both:<\/p>\n![](\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2015\/11\/chrome-devopt2.jpg\")
![](\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2015\/11\/firefox-dev-opt2.jpg\")
<\/figure>\nBoth Chrome and Firefox allows you to control the timing (speed up or slow down), and also manually scrub through the animation. More advanced timeline tools are coming in Chrome<\/a> that can look at multiple elements at at time. That will be nice, as working with only a single element at a time in an animation is fairly big limiting factor.<\/p>\nOne thing I have some trouble with is grabbing the element quickly enough if the animation is short-lived and fast. In those cases, I’ll usually set it to animation-iteration-count: infinite;<\/code> so that I can continue to play with it without having to fight time.<\/p>\nI also find it extremely helpful to slow the animation way down and then replay and adjust the timing in the browser with these tools. It allows you to pull apart each movement at a fundamental level and see how everything is interacting and what the motion progress looks like. If you refine it at that speed, when you adjust it to play faster, it will look much more masterful.<\/p>\n
Debugging CSS Animation Events with JavaScript<\/h3>\n
If you’d like to figure out exactly where and when each animation is fired, you can use a little JavaScript to detect and alert you to when each event is occurring, by hooking into animationstart<\/code>, animationiteration<\/code> and animationend<\/code>. <\/p>\nHere’s a demo of that:<\/p>\n
See the Pen Showing how to Debug Animation Play States in JavaScript<\/a> by Sarah Drasner (@sdras<\/a>) on CodePen<\/a>.<\/p>\nKeep Keyframes Concise<\/h3>\n
I often see people declare the same property and value at the 0% keyframe and 100% keyframe. This is unnecessary and leads to bloated code. The browser will take the properties value as the initial and ending value by default.<\/p>\n
Meaning this is overkill:<\/p>\n
.element {\r\n animation: animation-name 2s linear infinite;\r\n}\r\n \r\n@keyframes animation-name {\r\n 0% {\r\n transform: translateX(200px);\r\n }\r\n 50% {\r\n transform: translateX(350px);\r\n }\r\n 100% {\r\n transform: translateX(200px);\r\n }\r\n}\r\n <\/code><\/pre>\nIt could be written like this:<\/p>\n
.element {\r\n transform: translateX(200px);\r\n animation: animation-name 2s linear infinite;\r\n}\r\n \r\n@keyframes animation-name {\r\n 50% {\r\n transform: translateX(350px);\r\n }\r\n}<\/code><\/pre>\nDRY-ing Out Animations<\/h3>\n
Creating a beautiful and succinct animation usually means writing a very specific cubic-bezier()<\/code> easing function. A fine-tuned easing function works similarly to a company’s palette. You have your own specific branding and “voice” in your motion. If you’re using this all over a website, (and you should, for consistency) the easiest way to do so is to store one or two easing functions in a variable, just as we do with our palettes. SASS and other pre\/post processors make that simple:<\/p>\n$smooth: cubic-bezier(0.17, 0.67, 0.48, 1.28);\r\n \r\n.foo { animation: animation-name 3s $smooth; }\r\n \r\n.bar { animation: animation-name 1s $smooth; }<\/code><\/pre>\nWhen animating with CSS keyframes, we want as much help from the GPU as possible. That means that if you’re animating multiple objects, you want a way to easily prepare the DOM for the incoming movement and layerize the element. You can hardware accelerate a native DOM element (not SVG) with CSS by using a standard declaration block. Since we reuse that on all of the elements we\u2019re animating, it makes sense to save some typing, and add this in using a mixin or extend:<\/p>\n
@mixin accelerate($name) {\r\n will-change: $name;\r\n transform: translateZ(0);\r\n backface-visibility: hidden;\r\n perspective: 1000px;\r\n}\r\n\r\n.foo {\r\n @include accelerate(transform);\r\n}<\/code><\/pre>\nBe careful. Offloading too many elements at once can cause an inverse effect and performance to tank. Most animations should be fine, but be aware of this if you’re using something like haml to generate tons of DOM elements.<\/p>\n
Loops for Better Performance<\/h3>\n
Smashing Magazine recently published a great piece<\/a> showing the work behind the fantastic project, Species in Pieces<\/a>. In one particular section, the author goes into detail about how animating all of the pieces at one was causing performance problems. He states:<\/p>\nImagine that you’re moving 30 objects at the same time; you are asking a lot of the browser, and it makes sense that this would create problems. If you have a speed of 0.199 seconds and a delay of 0.2 seconds on each object, you would fix the problem by moving only one object at a time. The fact that the same amount of total movement happens doesn’t matter: If the animation is done as a chain, performance is immediately improved by 30 times.<\/p><\/blockquote>\n
You can take advantage of Sass or other pre\/post-processor for<\/code> loops for this kind of functionality. Here\u2019s a pretty simple one that I wrote to loop through nth-child:<\/p>\n@for $i from 1 through $n {\r\n &:nth-child(#{$i}) {\r\n animation: loadIn 2s #{$i*0.11}s $easeOutSine forwards;\r\n }\r\n}<\/code><\/pre>\nNot only that, but you can use them to stagger visual effects like color as well. (Hit replay to rerun the animation.)<\/p>\n
See the Pen SASS for loops in CSS Animations<\/a> by Sarah Drasner (@sdras<\/a>) on CodePen<\/a>.<\/p>\nAdjust Many Animations in Sequence<\/h3>\n
When you’re creating longer animations, the way to sequence multiple animations or events is usually to chain them together with progressive delays. So something like:<\/p>\n
animation: foo 3s ease-in-out, bar 4s 3s ease-in-out, brainz 6s 7s ease-in-out;<\/code><\/pre>\nBut let’s say you’re making refinements, and you discover that the second count of the first animation should change. This affects the delays of everything following it, so let’s adjust our timing for each one after. No big deal.<\/p>\n
animation: foo 2.5s ease-in-out, bar 4s 2.5s ease-in-out, brainz 6s 6.5s ease-in-out;<\/code><\/pre>\n