Optimize Your Web Animation Workflow
This chapter is from the book
This chapter is from the book
This chapter is from the book
The animation code found on most sites is nothing short of a mess. If there’s one thing experienced motion designers miss about the old, ugly days of Flash, it’s a structured approach to motion design.
The contemporary approach to structuring animation code is twofold: leverage the workflow features of an animation engine (in this case, Velocity.js) to make your code more terse and expressive, and use code organization best practices so that it’s easy to modify your work later.
Say goodbye to deep-nesting JavaScript callbacks and to dirtying your stylesheets with unwieldy CSS animations. It’s time to up your web animation game.
CSS animation workflow
In an attempt to better manage UI animation workflow, developers sometimes switch from JavaScript to CSS. Unfortunately, once animations reach a medium level of complexity, CSS animations typically result in a significantly worse workflow.
Issues with CSS
While CSS transitions are convenient when used sparingly in a stylesheet, they’re unmanageable in complex animations sequences (for example, when all elements sequentially load into view upon page load).
CSS tries to address this issue with a keyframes feature, which lets you separate animation logic into discrete time ranges:
@keyframes myAnimation {
0% { opacity: 0; transform: scale(0, 0); }
25% { opacity: 1; transform: scale(1, 1); }
50% { transform: translate(100px, 0); }
100% { transform: translate(100px, 100px); }
}
#box { animation: myAnimation 2.75s; }
This specifies separate points within an animation’s timeline at which particular property values should be reached. It then assigns the animation to an element with an ID of #box, and specifies the duration of the keyframe sequence to complete within. Don’t worry if you don’t fully grasp the syntax above—you won’t be using it in this book. But before moving on, consider this: what happens when a client asks you to make the opacity animation one second longer, but keep the rest of the properties animating at their current durations? Fulfilling this request requires redoing the math so the percentage values properly align with a 1-second increase. Doing this isn’t trivial, and it certainly isn’t manageable at scale.
When CSS makes sense
It’s important to point out a situation in which you should be using CSS rather than JavaScript for UI animation: when you’re animating simple style changes triggered by a user hovering over an element. CSS transitions lend themselves beautifully to these types of micro-interactions, allowing you to accomplish the task in just a few lines of very maintainable code.
Working in CSS, you first define a transition on the target element so that changes in the specified CSS properties animate over a predetermined duration:
/* When this div's color property is modified, animate its change over a duration of 200ms */
div {
transition: color 200ms:
}
You then specify the value that each particular CSS property should change toward, per the transition rule. In the case of the hover example, the div’s text color will change to blue when the user hovers over it:
div:hover {
color: blue;
}
That’s it. In only a few lines of code, CSS handles interaction state for you: when the user hovers away from the div, CSS will animate the change from blue back to the preexisting text color over a duration of 200ms.
In contrast, coding this same effect in jQuery would entail the following:
$div
// Register a mouseover event on this div, which calls an animation function
.on("mouseover", function() {
$(this).animate({ color: "blue" }, 200);
})
// When the user hovers off the element, animate the text color back to black
.on("mouseout", function() {
// Note: We have to remember what the original property value was (black)
$(this).animate({ color: "black" }, 200);
});
This might not look so bad, but the code isn’t taking advantage of the fact that JavaScript provides an infinite amount of logical control. It goes out of its way to do something that CSS is designed for: triggering logicless animations that occur on the same element that the user is interacting with. Above, you’re doing in JavaScript what you could have done in fewer, more expressive, and more maintainable lines of CSS. Even worse, you’re not getting any additional feature benefits by implementing this functionality in JavaScript.
In short, if you can easily use CSS transitions to animate an element that’s never being animated by JavaScript (meaning there’s no potential for conflict), then you should code that animation in CSS. For all other UI animation tasks—multi-element and multistep sequences, interactive drag animations, and much more—JavaScript animation is the superior solution.
Let’s explore the fantastic workflow techniques JavaScript provides.