CSS Transitions

CSS transitions tell the browser to apply any changes to specified style properties progressively, over a set period of time. The transition only applies if some other factor causes the style to change. Transitions don’t change the styles themselves.

CSS transitions are applied to an element with the transition shorthand property or by longhand properties of the form transition-*:

• transition-property sets the name of the style property to transition, if its value is changed. It can be all for transitioning every property (but be careful of this getting out of hand), or none (the default) to not apply any transitions.

  The transition-property can also be a comma-separated list of property names. All the other transition properties can either be given in matching lists, or as a single value that will apply to all properties.

• transition-duration sets the length of time over which each property will be changed, in seconds (s) or milliseconds (ms). It’s 0s by default, so no visible transition will be applied.

• transition-delay specifies an amount of time the browser should wait after the time when a new style value applies (for example, a :hover rule is triggered by a mouse-over), before starting the transition duration. It is useful for staggering changes to multiple properties, especially if one property cannot be smoothly transitioned.

• transition-timing-function describes the rate of change of the property value over the transition duration. There are various keyword values (including the default ease) and a cubic-bezier() function that allows you to specify the control points for a curve from (0,0) to (1,1).

  If none of the keywords create the effect you want, there are a number of websites that have copy-and-paste cubic Bézier functions, and Chrome and Firefox now both have visual timing-function editors in the dev tools.

The shorthand transition property sets all the values at once. For the timing values, the delay is always specified after a duration; other values can be set in any order, or omitted (which sets it to the default value). For a list of different transitions, each item in the list sets all the values for a particular transition property.

In Chapter 7, we used transitions to smooth out font-size change for text labels that were resized based on media queries (Figure 7-4):

svg text { transition: font-size 0.5s; }

Not all properties can be smoothly transitioned through a set of continuous values, like font-size can. There is no halfway point between font-family: Arial and font-family: Times. Keyword values and other properties with no valid mid-point will flip from the old to the new value when the transition timing function passes the midway position.

Originally, the CSS Transitions spec had a limited list of transitionable properties, and font-family was not on it. The spec has since been updated so that nearly all properties can be animated, using the midway “flip” rule.

Even in the browsers that have updated, transitioning the transition-* properties doesn’t work, and you can’t transition the display property, either. Animations and transitions are only calculated for elements that are currently being displayed.

You can’t transition to display: none, but you can transition to visibility: hidden. In SVG, the two are mostly equivalent, so visibility should be used if you want to add a transition effect before hiding an element. It works even in browsers that haven’t been updated to the latest spec—visibility was always a transitionable property.

For example, to fade out an element, you could transition opacity to 0 over a 0.5s duration, and transition visibility to hidden with a 0s duration but 0.5s delay. That way, you get the accessibility benefits of properly hiding the element—so it can’t receive keyboard and pointer events—but still have a smooth fade-out transition.

The following CSS would create that transition to apply whenever you added the aria-hidden="true" attribute to an element with JavaScript:

.may-be-hidden {
    transition-property: opacity, visibility;
    transition-duration: 0.5s, 0s;
}
.may-be-hidden[aria-hidden="true"] {
    opacity: 0;
    visibility: hidden;
    transition-delay: 0s, 0.5s;
}

The transition-delay for visibility is only applied when the element is in its hidden state. That means, when we unhide the element (remove the aria-hidden attribute), the delay won’t apply anymore. The visibility will immediately turn back on, so that you can actually see the opacity transition.

In general, if you want a different transition—or no transition at all—for different directions of a state change, you change the transition properties as part of the same style rule that changes the values.

CSS Keyframe Animations

CSS animations are applied to an element with the animation shorthand property or by longhand properties of the form animation-*.

CSS animations are more specifically known as CSS keyframe animations, and also require an @keyframes rule. Animations apply a series of new property values to an element. The timing of the animation cycle is set in the animation properties on the element, but the new style values are defined in the @keyframes rule set.

The @keyframes rule set is identified by a custom name, which is followed by curly braces ({}) containing CSS rules. So the following defines an animation effect named flicker:

@keyframes flicker { /* keyframe rules go here */ }

You have a lot of flexibility in the names you can use (only CSS-wide keywords like inherit and initial are forbidden). However, try to avoid picking a name that could be confused for an animation-related keyword (like alternate or backwards), or your shorthand animation declarations might not work as expected.

Inside an @keyframes rule set, the individual rules mostly look like normal CSS style rules, but with one key (ahem) difference: keyframe selectors don’t identify elements in the DOM, they identify positions in the animation cycle, as percentages of the animation duration time.

To set the same style properties to apply at multiple points in the cycle, you can use a comma-separated selector list. This means that these rules define the flicker effect as one that starts and ends at full opacity but applies zero opacity at the halfway point:

@keyframes flicker {
    from, to { opacity: 1; }
    50%      { opacity: 0; }
}

If you don’t specify the 0%/from or the 100%/to keyframe, both default to the current values on the element. So if your elements start at full opacity, this @keyframes rule is equivalent to the last one:

@keyframes flicker2 { 50% { opacity: 0; } }

In the original CSS animation draft—where only certain properties were animatable—nonanimatable properties specified in @keyframes rules were ignored completely. Under the latest spec, these properties “flip” from one value to the next when the timing function crosses the mid-point value, the same as for transitions.

However, animation properties and display still can’t be animated. If you use a CSS variable in an animation property, you also cannot animate that CSS variable. Otherwise, CSS variables are animated using the mid-point flip rule, since the browser doesn’t know what the intermediate values should be.

Declaring @keyframes does not have any effect on its own. To actually make an element flicker with that animation, you would need to reference the name of that keyframe set in the element’s animation properties.

There are eight longhand properties for animations:

• animation-name is the name you specified in the @keyframes rule (e.g., flicker), or a comma-separated list of multiple keyframe rules to apply. If it is a list, then you can give each animation its own distinct timing values, by giving the other properties as matching lists.

• animation-duration is the total time for one run of the keyframe cycle, from 0% to 100%.

• animation-delay is a wait time to apply from the time the animation rule applies to an element or the time the element is displayed in the document until the start of the first duration.

  The delay can be negative, which causes the animation to begin right away, partway through the animation cycle. We used negative animation delays for the stoplights in Example 1-8, so that the lights would be staggered, turning on at different times.

• animation-direction sets whether to apply the keyframes in normal order (0% to 100%), reverse order (100% to 0%), or to alternate back and forth in each iteration.

• animation-timing-function sets the transition timing function to be used between each keyframe value (that is, each rule in the @keyframes block). It defaults to ease.

  This is the only animation property that can be set within the keyframes rules, to give a unique timing function for the transition from that keyframe to the following one (in normal direction). So the following code creates alternating “in” and “out” eases between each keyframe:

  .ball {
    animation-name: bounce;
    animation-duration: 5s;
    animation-timing-function: ease-in;
      /* default for each keyframe transition */
  }
  @keyframes bounce {
    /* start high, then each bounce is smaller */
     0% { transform: translateY(-50px); }
    20% { transform: translateY(-40px); }
    40% { transform: translateY(-30px); }
    60% { transform: translateY(-20px); }
    80% { transform: translateY(-10px); }
    10%, 30%, 50%, 70%, 90%, 100% {
      /* the bottom of each bounce */
      transform: translateY(0px);
      animation-timing-function: ease-out;
        /* applies to transition _after_ this state,
           i.e., for the upwards bounces */
    }
  }

• animation-iteration-count is a number for how many times to repeat the keyframes cycle (default 1), or the keyword infinite.

• animation-fill-mode allows you to extend the final values of an animation after the animation is complete (forwards), to apply the initial values during the delay period before the animation starts (backwards), both, or none (the default).

• animation-play-state allows you to pause and restart an animation without resetting the values; the value is either running (the default) or paused.

You can also set all of the longhands using the animation shorthand, which takes a comma-separated list of complete animation descriptions. Just like with transitions, the duration time must always be given before the delay time, but otherwise the values can be given in any order. Any of the subproperties can also be omitted from any animation in the list, which sets it to the default value.

The stoplight animation from Chapter 1 (Example 1-8) used the following code to define the keyframes, the shared animation properties, and then the negative delays that cause each light to start at a different point in the cycle:

@keyframes cycle {
    33.3% { visibility: visible; }
    100%  { visibility: hidden;  }
}
.lit {
    animation: cycle 9s step-start infinite;
}
.red    .lit { animation-delay: -3s; }
.yellow .lit { animation-delay: -6s; }
.green  .lit { animation-delay:  0s; }

That animation shorthand is equivalent to the following long-hands:

.lit {
    animation-name: cycle;
    animation-duration: 9s;
    animation-timing-function: step-start;
    animation-iteration-count: infinite;
    animation-delay: 0s; /* re-set to initial */
    animation-direction: normal;    /* re-set */
    animation-fill-mode: none;      /* re-set */
    animation-play-state: running;  /* re-set */
}

The step-start timing function forces all frame changes to be discrete switches from one value to the next. For visibility, that would happen anyway—since it can only take discrete values—but step-start forces the switch to happen at the beginning of each transition period instead of at the mid-point.

We also used CSS animations for some of the stroking examples in Chapter 13 and its supplementary material. In Example 13-8 (which cycled chain-link dashes around the shape) we used the following code:

animation: cycle 0.5s 20 linear;

The linear timing function was essential to create the appearance of continuous movement, without any speeding up or slowing down during the 20 iterations.

In contrast, in the supplementary line-drawing example, we used an ease-in timing function, which caused the transitions (drawing the path and fading in the fill color) to start slowly but end sharply.

Although we didn’t include the CSS code in Chapter 18, we also used CSS animations and transitions to enhance the confetti and gem collection games. Example 19-1 provides the CSS used in the final version of the figures (Figure 18-9). It assumes SVG text elements, but could easily be adapted for HTML elements.

#gameboard {
    max-height: 100vh;
    max-width: 100%;
    background: #224;
}
.count { /* class for all the text elements */
    fill: lightYellow; /* or use `color` if using HTML text */
    font: 20px Consolas, monospace;
}
#timer, #scoreboard { /* the specific numbers being updated */
    font-size: 300%;
}
#scoreboard {
    transition: font-size 1s;        
}
.clicked {
    opacity: 0.1;
    pointer-events: none;
}
.miss {
    color: #88f;
    stroke: currentColor;
    stroke-width: 4px;
    stroke-opacity: 0.5;
    fill: currentColor;
    fill-opacity: 0.5;
    animation: flicker-fade ease-in-out 3s forwards;       
}
@keyframes flicker-fade {
    from { opacity: 1;
           animation-timing-function: ease-out;            
         }
    60%  { opacity: 0.2; }
    70%  { opacity: 0.3; }
    80%  { opacity: 0.1; }
    90%  { opacity: 0.2; }
    to   { opacity: 0.0; visibility: hidden; }
}
#timer[aria-live] {
    animation: flash-color 0.3s alternate infinite;        
}
@keyframes flash-color { /* again, use `color` for HTML text */
    to { fill: tomato; }                                   
}

.game-over #scoreboard {
    font-size: 800%;
    animation: flash-color 0.5s 16 alternate;              
}
.game-over .clickable { fill: black; }
.game-over .clicked {
    opacity: 1;
    filter: drop-shadow(0 0 3px gold);
}

By defining all the animation effects in the game using CSS, the JavaScript code was able to focus on the game logic and event handling. The classes and attributes set by the script are meaningful (semantic), not specific to particular styles. The entire game could be restyled, including the animation effects, without the JavaScript being changed.

Benefits and Limits of Animating SVG with CSS

Animating SVG—or any other web content—with CSS has a number of benefits. CSS transitions, in particular, are wonderful in their simplicity, often only requiring a single line of code to enhance an existing interactive project. Keyframe animations have a slightly more complicated syntax, but they are still fairly simple to write compared to the complexity of the effects you can create.

CSS animation effects also have performance benefits. Because the effects are declarative, the browser knows what future changes will be required, and can optimize rendering calculations to avoid repeating all the work every time it repaints the screen. It can also skip calculations entirely if it knows that an element is currently off-screen. And it can adjust the repaint frequency to prioritize other processing tasks, such as event handling. In many cases, the animation updates can run on a separate processor thread than JavaScript and events—or even on a separate processor, the GPU instead of the CPU.

You can usually create acceptable unanimated fallback in browsers that don’t support CSS animations. If transitions are not supported, you just have instantaneous value changes. If keyframe animations are not supported, you get whatever base value you set on the element, with the keyframe declarations ignored. So the only extra effort is to ensure that those base values create an acceptable appearance and a functional website.

But CSS animations and transitions have their limitations. Limitations that are important for animated SVG include:

• They can only animate CSS properties. For SVG, that leaves out many attributes that you often want to animate. The possibilities will improve once there is better browser support for SVG geometry and transforms in CSS, but there is no spec yet for converting many SVG attributes to CSS properties.

  SVG features you can’t animate with CSS, even in SVG 2, include viewBox, polygon/polyline points, filter parameters, and geometric attributes on text and graphical effects elements.

• Although an element can have multiple animations, you must set all animations (or all transitions) in the same property declaration. If you apply a different animation (or transition) property to the same element with a different CSS selector, one replaces the other. If you have two classes that apply independent animation effects, you’ll need a separate rule for the combination of both classes:

  .flicker { animation: flicker 0.3s infinite alternate; }
  .grow    { animation: grow 5s forwards; }
  .flicker.grow {
      animation: flicker 0.3s infinite alternate,
                 grow 5s forwards;
  }

  If you do create a graphic with multiple interactive animations being set and removed by different classes, be sure to test carefully. There are now rules in the spec for how it should behave, but browsers may not have caught up.

• Similarly, there is no way for changes made by one animation effect to add to changes from another animation. If both animations are changing the opacity or the transform property on the same element, CSS cascade rules apply, and the last animation (in the animation-name list) wins out.

  To create a cumulative effect, you often need to add extra nested elements (e.g., <g> groups) to your DOM, one for each animation effect.

• You can’t easily coordinate one animation effect to start after another animation finishes. You either need to string them all together in a single @keyframes rule set, or adjust the animation-delay on the second effect to always match the duration on the first effect—and then adjust the delay on a third effect to match the sum of durations of the first two effects, and so on.

  CSS variables and calc() will make this easier, but it can still be fussy for long animation sequences.

• You cannot set an animation to repeat at regular intervals with a delay between repeats; you need to incorporate the delay into the percentage values used in the @keyframes rule set.

• You cannot precisely coordinate animations on different elements. The animation timeline for each element starts (or re-starts) when that element is added to the DOM, when it is given a display other than none, or when the animation effect is applied. If anything delays DOM or CSS parsing (or scripted execution), some elements will get a head start compared to others.

• You can pause animations easily, but trying to fast-forward or rewind animations by adjusting CSS properties is fussy and awkward.

In other words: CSS animations and transitions are wonderful for many effects, but they are not the solution for all your animation needs on the web.

Animating Attributes, Declaratively

The primary SMIL animation element, conveniently named <animate>, can modify nearly any attribute or style property on another SVG element. It can switch instantly between values or transition smoothly between them, and can do it at a fixed time, in response to a DOM event, or chained after another animation.

In the simplest case, <animate> provides an interpolation service. You specify the attribute or style property you want to change, the value you want to change it to, and the duration (length of time) it should take to get there.

The browser determines in-between values between the “base” value set on the shape and the to value set in the animation, and updates the attribute for every frame as the animation proceeds. This is the same as CSS transitions, except that the attribute you’re changing does not need to have a CSS equivalent.

For instance, suppose that you wanted to show a circle that grows from a dot to a certain size. That would be animating the r attribute from 0 to the full size. The code for defining that animation with <animate> is given in Example 19-2.

<svg xmlns="http://www.w3.org/2000/svg" xml:lang="en"
     xmlns:xlink="http://www.w3.org/1999/xlink"
     width="100%" height="100%" viewBox="-200 -200 400 400">
    <title>Animated Circle</title>
    <circle r="0"
            fill="darkOrchid" stroke="plum" stroke-width="16">
        <animate attributeName="r" to="190"
                 dur="5s" fill="freeze" end="10s"/>
    </circle>
</svg>

The <animate> element, by default, animates its parent element. So we include it as a child of the <circle> element.

Most of the attributes on the <animate> in Example 19-2 are mostly self-explanatory:

• attributeName specifies the name of the attribute we want to change (here, r, the circle’s radius). The “attribute” can also be a style property.

• to specifies the new value that we want to transition the attribute to.

• dur defines the duration of the animation (here, 5 seconds). Durations are by default infinite, which means that if you don’t specify a duration, nothing will change in your lifetime. Durations can be in seconds (s), milliseconds (ms), or even minutes (min) or hours (h), or a combination like 03:30 (3 minutes, 30 seconds).

The confusing attribute in Example 19-2 is probably fill="freeze".

This fill attribute comes from SMIL, not SVG, and has nothing to do with the fill color of the circle. Instead, it tells the browser how to “fill up” any extra time after the duration of the animation completes. The freeze value says to keep the last value of the animation “frozen in time” indefinitely, unless another animation replaces the value.

The default for SMIL’s fill is remove, which means that once the animation is over, the animated effect is removed. The attribute reverts to the base value set on the element. Here, that would revert our circle down to nothing.

And that’s a problem. Freezing the value is all very well for browsers that applied the animation, but without SVG/SMIL support Example 19-2 is a picture of an empty screen.

To design animations with acceptable fallback, you need the base values to create an acceptable static graphic. This usually means setting the base value to whatever value you were going to “freeze” in place anyway.

Then, how do you create an entry or reveal animation? With the from attribute, which gives an explicit starting value for the animation:

<circle r="190"
        fill="darkOrchid" stroke="plum" stroke-width="16">
    <animate attributeName="r" from="0" to="190"
             dur="5s" />
</circle>

Note that the to attribute on <animate> is still required. Unlike in CSS, to in SVG/SMIL does not default to the base value.

Complex Animations

A single from-to <animate> effect isn’t terribly impressive. But you can create complex combinations of different animation elements, animating the same or different properties, on the same or different elements, simultaneously or in sequence. An individual <animate> element can also have multiple values (similar to CSS keyframes) and repeats.

In addition to <animate>, there are three other SVG/SMIL animation elements:

• <set> applies a discrete change, setting an attribute to a different value for a specified duration.

• <animateTransform> applies a specific transformation function (translate, rotate, scale, skew, or matrix).

• <animateMotion> applies a complex transformation, defined not with transformation functions but by the route, or motion path, that you want the element to follow as it moves. The motion path can reference an existing SVG <path> element, by using a child <mpath> element to create the cross-reference.

The <animateMotion> effect is one of the highlights of SVG/SMIL, allowing the creation of elegant effects with a simple, declarative format.

Example 19-3 uses <animateMotion> to create an infinitely repeating animation, such as you might use for a loader image (a placeholder image for when you are loading other content). It also demonstrates a few more of the SVG/SMIL animation timing attributes. Figure 19-1 shows three different stages of the animation—but you’ll need to run the code to get the full effect.

Figure 19-1. Three stages of an infinite animation of shapes moving around a path

<svg xmlns="http://www.w3.org/2000/svg" xml:lang="en"
     xmlns:xlink="http://www.w3.org/1999/xlink"
     viewBox="0 0 400 160" width="4in" height="1.6in">
    <title>Motion on a Path, with &lt;animateMotion&gt;</title>
    <defs>
        <polygon id="bead" points="-8,0 0,-8 8,0 0,8"
                 stroke-width="2" />                       
    </defs>
    <path id="track" fill="none" stroke="dimGray"
          d="M200,80 C-50,280 -50,-120 200,80
                     C450,280 450,-120 200,80Z" />         
    <use xlink:href="#bead" fill="orchid" stroke="indigo">
        <animateMotion dur="5s" repeatDur="indefinite"
                       rotate="auto">                      
            <mpath xlink:href="#track"/>                   
        </animateMotion>
    </use>
    <use xlink:href="#bead" fill="gold" stroke="tomato">
        <animateMotion dur="5s" repeatDur="indefinite"
                       rotate="auto" begin="-1s">          
            <mpath xlink:href="#track"/>
        </animateMotion>
    </use>
    <use xlink:href="#bead" fill="springGreen" stroke="seaGreen">
        <animateMotion dur="5s" repeatDur="indefinite"
                       rotate="auto" begin="-2s">
            <mpath xlink:href="#track"/>
        </animateMotion>
    </use>
    <use xlink:href="#bead" fill="skyBlue" stroke="mediumBlue">
        <animateMotion dur="5s" repeatDur="indefinite"
                       rotate="auto" begin="-3s">
            <mpath xlink:href="#track"/>
        </animateMotion>
    </use>
    <use xlink:href="#bead" fill="indianRed" stroke="firebrick">
        <animateMotion dur="5s" repeatDur="indefinite"
                       rotate="auto" begin="-4s">
            <mpath xlink:href="#track"/>
        </animateMotion>
    </use>
</svg>

The code for Example 19-3 amply demonstrates a significant limitation of the SVG/SMIL syntax: it is not DRY at all. Each <animateMotion> element is almost identical, but the attributes and child <mpath> element all need to be repeated. There is no equivalent to the cross-references used in SVG patterns and gradients to make one effect a template for another.

For <animateMotion> in particular, an important limitation is that you can’t easily include a fallback static position for unsupporting browsers. The extra transformation from the motion effect is added to whatever position or transformation the element already had; it doesn’t replace a base attribute. Without SMIL support, all the beads are drawn centered over the origin of the SVG.

We’ll consider another—cross-browser compatible—way to create this effect in the section on scripted animations.

Benefits and Limits of SVG/SMIL Animation Elements

The SVG/SMIL animation elements have a number of capabilities that CSS animations and transitions don’t, some of which we’ve covered here and some of which we describe in the supplementary material:

• They can animate attributes, not only styles.

• Many independent animations can be set on the same element, and animations of the same property can be additive.

• Progressive animations can be defined as accumulative repeats.

• Animations on the same or different elements can be synchronized or chained together, optionally with time offsets.

• By tying an element’s begin time to its own end time, plus an offset, you can create animations that repeat after a delay.

• You can specify the number of repeats in terms of the total animation time instead of as a repeat count.

• Animation times are coordinated for the entire document; with JavaScript, you can pause or reset all animations in sync.

• Animations (or <set> changes to any value) can be triggered by any DOM event, not only the ones that create CSS pseudoclasses.

• You can animate the display property (although, for SVG, display is only a benefit relative to visibility if you are hiding and showing text spans).

However, the syntax also has some limitations compared to CSS:

• Each animation element can only animate a single target element, and there’s no easy way to copy attributes from one animation to another. This means a lot of repeated code for many designs.

• There is no shorthand way to create alternating animations, or animations from a specified value to the base value specified on the element, so you end up repeating values.

• There are no keyword easing (timing) functions, there’s no way to create bounce/overshoot easings without adding extra values, and there is no way to specify that the same easing should apply for multiple transitions in a values list. Overall, the easing syntax is just painful to use compared to CSS.

• Applying a backward fill to a delayed animation requires a separate <set> element.

• You cannot easily pause individual animation effects in process.

• Transitions to and from a state that can last an indefinite amount of time (e.g., a hover effect, or a toggle button) are very difficult to coordinate using the event-triggered timing model.

But of course the biggest limitation of the animation elements is the lack of support in Microsoft browsers. This limits their practical use on the web, which means that other browsers don’t have a strong incentive to improve their implementations. Bugs accumulate and performance is ignored.

The solution in most cases is JavaScript, which we’ll discuss in the next section.

But JavaScript does not work in SVG used as images, or in some non-web SVG applications. And it is often overkill for simple decorative animations that can be defined in a few lines of SVG/SMIL code.

That means there is still a use for SVG/SMIL on the web, but not as the centerpiece of an animated web interface.

Triggering Regular Updates

In Chapter 2, we used JavaScript to animate our stoplight graphic. It wasn’t a continuous animation, but it was an animation. The update function (cycle() in Example 2-2) changed which versions of the lights were visible to create the effect of one light switching off and another light switching on.

To trigger our cycle updates once every 3 seconds, we used the setInterval() JavaScript function. We also used setInterval() in Chapter 18, to update the countdown timer in our game.

The setInterval() function is a core JavaScript function. It takes two parameters: a function object and a time in milliseconds. The browser will then run that function repeatedly until the interval is cancelled, with a delay between runs of approximately the number of milliseconds you specify.

setInterval() and the similar, but nonrepeating setTimeout() used to be the only options available for regularly updating JavaScript animations.

If you’re creating a discrete animation that only updates every few seconds—like the stoplight—then setInterval() is still a great choice.

The problem comes when you want to update your animation frequently, like every 16ms for a 60fps continuous animation. setInterval() is a little too bossy. The browser will try to keep up with that interval even if it has other code to run, and even if the web page is currently in a nonactive browser tab (although browsers are changing both behaviors, to keep interval-based code from locking up your computer completely).

Even the every-100ms update we used for the timer in Example 18-5 (10fps) is getting a little too frequent for setInterval().

If the timer code were more complicated, and the game were inline in a web page with a lot else going on, there could be noticeable lags. If the timer ran indefinitely—instead of for max 15 seconds—it could slow down your browser if you left it open in a background tab.

Modern browsers have a better solution for triggering animation updates: requestAnimationFrame().

The requestAnimationFrame() method asks the browser to run a function—which you specify as a parameter—the next time the browser is ready to update the visual rendering of this web page.

If the web page is currently in a nonactive browser tab, the function won’t run until the user switches back to view the page. When the page is visible, the browser will adjust how frequently it updates, to provide a balance between animation smoothness and overall performance.

The behavior of requestAnimationFrame() is closer to setTimeout() than setInterval(): by default, it runs the function only once. If you want the animation to continue, your update function itself needs to request another frame.

Because you don’t know exactly when your function will run, or how frequently, you’ll need to check the current time in your update code. You could do this by grabbing the Date.now() system timestamp, but the browser passes a dedicated animation timestamp as a parameter to your update function.

If you have multiple animation functions, they’ll all get the exact same timestamp value for the same animation frame.

The following code adapts our timer code in Example 18-5 to use animation frames instead of fixed intervals, and to use the animation timestamp instead of Date.now():

var endTime;
requestAnimationFrame(updateTime);
function updateTime(t) {
    if (!endTime) {
        endTime = t + timeLimit*1000;
    }
    var timeLeft = endTime - t;
    if (timeLeft <= 0) {
        endGame();
        timeLeft = 0;
    }
    else {
        requestAnimationFrame(updateTime);
    }
    timer.textContent = (timeLeft/1000).toFixed(1);
}

The initial request (outside of the update function) starts the animation running. The function then requests additional animation frames until the time expires.

The timer won’t run in the background if you switch to a different browser tab, but the time will be correct if you switch back to this tab.

However, because we are now relying on the animation loop itself for the timestamps, our timer only starts when the first frame of the animation is painted, not when the initial request was made. If you need an independent start time, you can use the performance.now() method to get a compatible timestamp outside of the animation loop.

As before, the updateTime() function checks whether the time has run out. The request for the new animation frame only runs if that isn’t true, so the loop will stop automatically when the timer reaches 0. Note also that the new request isn’t the last line of the function. It doesn’t need to be; it is only queuing the request to run later.

There is also a cancelAnimationFrame() method, which you can use instead of adding an if test in your animation loop. Similar to clearInterval(), it requires a token value that is returned when you call requestAnimationFrame():

/* in the updateTime() function... */
frame = requestAnimationFrame(updateTime);

/* separately */
function stopTimer() {
    if (frame) { cancelAnimationFrame(frame); }
}

requestAnimationFrame() isn’t perfect. It only runs if the browser is repainting the web page, but it doesn’t include a check for whether the part of the web page you’re updating is currently visible. If you’ve got many inline SVGs within a large web page, you’ll want to add your own check to determine which ones are onscreen and therefore need updating.

Beyond that, the main limitation of requestAnimationFrame() animations—compared to CSS, SMIL, most JS animation libraries, or the future Web Animations API—is that you need to write your own code to calculate the updated graphic at each frame. That makes it incredibly flexible. But it can be easy to get tangled up in all that flexibility.

Calculating the Current Value

Broadly speaking, there are two main approaches to calculating animation progression:

Interpolation

Interpolation animation is the type of tweening animation used by CSS animations and transitions, SVG/SMIL, and the Web Animations API (level 1, anyway). The animation is defined by the amount of change that you want to apply, and the amount of time that it should take.

To create your own interpolation function, you convert the current time into a proportion of the animation duration, and then convert that into a proportion of the distance between your initial and final values. The conversion from time percentage to value percentage can be linear (one-to-one, the easiest choice), or it can use an easing function, equivalent to the timing functions used in CSS animations and transitions.

Physics-based animation

Used primarily for motion, physics-based animation defines the properties of the moving objects (particularly their speed and acceleration), and calculates their motion from that. The “physics” used in the animation calculation can be as realistic or as simplistic as you want. How long it takes the objects to reach a given position is determined entirely from the calculations you use.

Physics-based motion is preferred in games, where you don’t want everything to be predetermined. In games, you will often change the properties of the objects—such as their speed or their direction—based on user interaction or randomization.

There is really no end to the possible calculations you could integrate into an animation loop. So we’re not going to try to discuss them here. There are plenty of other good resources on game and animation design if you are interested.

Instead, as a simple example of a JavaScript animation loop, we’re going to recreate our motion-along-a-path graphic from Example 19-3.

This is an interpolated animation, since we know exactly how we want the “bead” elements to move, and how long they should take. Specifically, we are interpolating the distance along the path. Each bead should move the same distance along the path in the same time period, completing a full loop every 5 seconds (which was the dur in our <animateMotion> elements).

To transform our beads into the correct position, we therefore need to figure out the (x,y) position of a point that is a certain distance along the path. That sounds like a lot of math, but luckily the browser does it for us.

The <path> element has a method called getPointAtLength(). (In SVG 2, all the other basic shape elements will have the method, too.) You pass in a distance in user units (px), and you get back a point object with x and y properties for the coordinates of that point on the path.

We also want to rotate our beads to match the angle of the path. Unfortunately, there is no getAngleAtLength() method for paths. So we need to do a little bit of math ourselves.

By getting two different points from the path—close to each other but not identical—we can calculate the approximate rate of change of the curve at that point. The relative x and y change can then be converted to a tangent angle, using a little bit of trigonometry (an arc-tangent function, to be precise).

Example 19-4 provides the code. The visual result is the same as Figure 19-1.

<svg xmlns="http://www.w3.org/2000/svg" xml:lang="en"
     xmlns:xlink="http://www.w3.org/1999/xlink"
     viewBox="0 0 400 160" width="4in" height="1.6in">
    <title>Motion on a Path, with JavaScript</title>
    <defs>
        <polygon id="bead" points="-8,0 0,-8 8,0 0,8"
                 stroke-width="2" />
    </defs>
    <path id="track" fill="none" stroke="dimGray"
        d="M200,80 C-50,280 -50,-120 200,80
                   C450,280 450,-120 200,80Z" />               
    <use xlink:href="#bead" fill="orchid" stroke="indigo" />
    <use xlink:href="#bead" fill="gold" stroke="tomato" />
    <use xlink:href="#bead" fill="springGreen" stroke="seaGreen" />
    <use xlink:href="#bead" fill="skyBlue" stroke="mediumBlue" />
    <use xlink:href="#bead" fill="indianRed" stroke="firebrick" />
    <script><![CDATA[
(function(){
var track = document.getElementById("track"),                  
    trackLength = track.getTotalLength(),
    beads = document.querySelectorAll("[*|href='#bead']"),     
    nBeads = beads.length,
    dur = 5000; //duration of one loop of track, in ms

function update(time) {
    var t = (time % dur)/dur, /* position in repeat cycle */   
        distance, /* distance along the path for this bead */
        point,    /* SVGPoint for that distance */
        point2;   /* SVGPoint for a slightly different distance */
    for (var i=0; i<nBeads; i++) {
        distance = trackLength * ( (t + i/nBeads) % 1 );       
        point = track.getPointAtLength(distance);              
        point2 = track.getPointAtLength((distance+2)%trackLength);
        angle = Math.atan2( (point2.y - point.y),
                           (point2.x - point.x) );             
        beads[i].setAttribute("transform",
            "translate(" + [point.x, point.y] + ")"
            + "rotate(" + angle*180/Math.PI + ")" );           

    }
    requestAnimationFrame(update);    
}
requestAnimationFrame(update);        
})();
]]> </script>
</svg>

This version of the animation runs in every browser, including MS Edge and Internet Explorer. But if you want to use it as a loader, remember to embed it with <object>, not <img>, or copy it as inline SVG: the script won’t run at all in SVG used as an image.