Ceci est une ancienne révision du document !
Last time, we looked at how it’s possible to include animations in an SVG file that is loaded as an image. We introduced the general idea by animating the fill and stroke colors, and the stroke width, of a square we’d drawn in Inkscape. If we’re just working with a square – or even a rounded rectangle – we could equally achieve the same effect in HTML by animating the “background” and “border” CSS properties, with no need to go near SVG. But the important point to note is that we actually used CSS to animate properties that only make sense for SVG. In other words, although CSS is most commonly used with HTML, we can still use it to modify many SVG-only values. Furthermore, we can animate those properties not only on squares and rectangles, but also on arbitrary paths. By reusing the same animation that we had in the previous article, we can produce the same set of three snapshots, but this time of a more complex shape. For this example I created a star in Inkscape and converted it to a path. The first CSS rule, which previously had a selector of “rect”, also needed to be updated to change the selector to “path”.
But what if you want to animate more than just the style of your elements? Perhaps you want to make them move around, to spin, or to change size. You might even want the shape of the path itself to change. All this and more is possible with SVG… but, as will become clear, I don’t necessarily recommend doing it. As I’ve previously discussed in this column, there was a time when the W3C went full tilt in favor of XML. They defined and specified a wide range of XML languages – including SVG and XHTML (a pure XML version of HTML) – as well as working on various supporting technologies that could work with any XML language. One of these technologies was the “Synchronized Multimedia Integration Language”, or SMIL (pronounced “smile” apparently). SMIL is itself an XML language that describes how an XML document should change over time, or in response to certain interactions such as mouse movements and clicks. In the case of SVG, therefore, SMIL can be used to describe the way in which arbitrary attributes should change over time, allowing any part of the image to be animated.
If the W3C’s plan for XML domination had panned out, SMIL would probably have become a universally implemented technology for animation and multimedia. In practice, however, browsers veered away from the XML-centric approach in favor of the more lax requirements of HTML, and Microsoft never implemented SMIL in their browsers. Faced with an animation standard that wasn’t supported by Internet Explorer, it’s no wonder that so much early animation on the web was outsourced to Flash. The result was that SVG languished for a long time and SMIL never really took off. In the meantime, CSS gained more and more abilities that were once the remit of SVG, and has begun to encroach on the domain of SMIL with CSS animations and transitions. The penultimate nail in the SMIL coffin came with the release of version 45 of Google’s Chrome browser, which officially listed the technology as deprecated. It would still work for the time being, but that was notification that it’s eventually going away. After a backlash from the community they revoked this announcement, so SMIL is no longer deprecated in Chrome – but it’s only a matter of time before they decide that CSS animations are capable enough for them to try again. So that’s why I don’t really recommend using SMIL: with no support in Internet Explorer or Edge, and the prospect of being deprecated then removed in Chrome at some indeterminate point, it’s not a technology that can be relied on as a viable solution for use on the web at large.
Given this situation I’m not going to discuss SMIL in any great detail. But as it is (currently) usable in (most) web browsers, I’ll spend a couple of articles giving you a brief introduction in case you feel it is a technology that you can use and wish to investigate further – and as an insight into the sort of web we might have now, had Microsoft played ball, and XML gained stronger support from the browser vendors. There are four types of animation that can be performed using SMIL with SVG, in each case by adding the relevant animation tag (shown in brackets) inside the element you want to animate: • Animate the attributes of an SVG element (<animate>). • Animate the transformation that can be applied to an SVG element (<animateTransform>). • Animate the color of the fill and stroke (<animate> or <animateColor>). • Animate the position and, optionally, rotation of an object by making it follow another path (<animateMotion>).
Let’s look at a simple example, by trying to replicate the CSS animation of the same red star I used earlier. In this case we will need to animate the fill and stroke color, and the stroke width, using the <animate> tag. So rather than having those values stored as CSS properties, they need to be moved out to independent attributes. This results in our SVG file looking something like that shown top right. Note that, for simplicity, I’ve rounded all the coordinates down to whole numbers. There’s also a transform attribute that translates the star 20 units to the right, and 20 units down: I could have done the calculations to adjust the coordinates for the path, removing the need for this entirely. As Inkscape seems rather keen to put transforms onto its content, however, I decided to leave it in to better represent the sort of (minimised) output you might see from the program.
As with the CSS animations from last time, I’m going to start by just animating the fill color. This involves putting the <animate> tag as a child element of the <path>. In case you’re not very familiar with XML, in the previous code the path is written as a self-closing tag: <path … />. This can legitimately be rewritten as a non-self-closing tag: <path …></path>. It’s this latter approach we’ll need in order to add a child element (note that the rest of the SVG file and many of the path attributes have been omitted for clarity - shown below). The new element is pretty self-explanatory: attributeName defines which attribute in the parent element we’re animating, from and to are the start and end values, dur is the duration of the animation, and fill=“freeze” is used to make sure the attribute retains the last value, rather than flipping back to its original value.
That’s easy enough, but our original animation wasn’t a simple transition from one value to another, it also had a specific intermediate value, giving us three keyframes in total. That can be achieved with SMIL as well, by replacing our “from” and “to” attributes with “values” and “keyTimes” attributes which hold the three values we want to hit, and the proportion of the way through the animation that each is applied. The values in each list are separated by a semicolon. Code is shown top right. I’m using a generic <animate> element for animating this fill color. There is also a specific <animateColor> element that could be used instead, but since <animate> can do everything that <animateColor> can achieve, plus more, there’s no point using the latter these days. Even the SMIL specification now recommends using <animate> rather than <animateColor>, so who am I to argue.
Our original animation not only changed the fill color, but also the stroke color and width. This obviously entails animating three attributes – which we do just by using three <animate> elements (shown right). Notice that I’ve had to adjust the stroke-width values somewhat to get a similar result to the CSS animated version. I’m not sure why there’s a difference – perhaps the CSS values are interpreted as pixels, whilst the SMIL values are treated as SVG user units, based on the viewBox declared at the start of the file. Whatever the underlying reason, a little tweaking was required but I was nevertheless able to produce the same result. Animating attributes works well where the attribute can hold only a single, simple value, such as a length or color. The “transform” attribute is a more complex case, as it can hold a combination of translate(), rotate, scale(), and skew() functions. If your element already has a transformation applied – as many will do if they’re created in Inkscape – you probably want your animation to be added to the current transformation rather than replacing it entirely. To achieve this requires more than a simple <animate> element; it needs something that understands the syntax and structure of the transform attribute. It needs <animateTransform> (next page, top right).
Here I’ve used a couple of <animateTransform> elements to zoom and rotate the star during the course of its animation. The first element scales the star (type=“scale”), first making it bigger (1 > 1.5) and then smaller (1.5 > 1 > 0.75), covering four keyframes in the five second duration. You might think that attributeName=“transform” is redundant when the element itself is called <animateTransform> – and I would agree with you – but the animation doesn’t work without it. The second element rotates the star. In this case the values each consist of three space- or comma-separated numbers. These represent the amount of rotation (in degrees), and the x and y coordinates to be used as the center of rotation. I’ve selected 40 for each, to put the center roughly in the middle of the star, so it doesn’t spin off-screen entirely.
Thanks to the scale animation, however, it does still move around quite a bit. As the star is scaled in size, so its center point moves and the values in the rotation animation are no longer correct. This could be accommodated, to some extent, by tweaking the x and y coordinates in the rotation, or by adding another animation to set a translate() transform to compensate for the moving center point. A better approach would be to re-draw the star centered on the 0,0 coordinates, then position it on the page by tweaking the transform attribute on the element itself. That way, there’s no need to specify a center point for the rotation, and the values for the “rotate” animation could be reduced to a simple list of angles. You’ll have noticed that both the <animateTransform> elements have an additive=“sum” attribute. SMIL animations can be configured so that the animated values completely replace any previous value on the element, or so that the effects of the animation are cumulative. Without this extra parameter, the scale animation replaces the transform=“translate(20, 20)” attribute that Inkscape created; then the rotate animation replaces the scale animation. The result is that the star only rotates, and doesn’t scale – and it does so in the wrong location. The additive=“sum” attribute tells the browser to keep any existing transforms around, and add the new animated value to them to give a cumulative effect. In other words, the star both zooms and rotates, and does so (roughly) in the location specified by Inkscape’s translate() value.
Over the years, CSS has gained ever more of SVG’s capabilities, with the result that the SMIL animations I’ve shown so far can all be implemented as CSS animations. The fill and stroke we covered last time, but even <animateTransform> has a counterpart in CSS, now that the latter supports a “transform” property that allows elements to be translated, rotated, scaled, and skewed. Unlike SVG, it also offers a few options for transforming your element in three dimensions. But there are still some tricks up the SMIL sleeve which CSS animations can’t compete with (yet). One of these is the ability to animate a path between one shape and another. Much like animating a color, this is just a special case of animating an attribute – in this case the “d” attribute that holds the data representing the shape of a path. As a reminder, here’s what the path data for our star looks like: d=“m 40,15 6,18 19,0 L 49,45 56,64 40,53 24,65 30,45 14,34 34,34 Z”
I’m going to animate the star turning into a large arrow, pointing to the top right of the screen. To do this, I just use another <animate> element, transforming the “d” attribute from its default value to a new path definition. This will do the trick: By commenting out the other <animate> and <animateTransform> elements (using the XML/HTML method of wrapping them in <!– and –> tags), we can see what this path animation looks like in isolation. Here (above) are six frames from the transition. Removing the comment tags to reinstate the other animations results in a star that smoothly changes to an arrow whilst it’s rotating, changing size, and it transitions from a red fill with a thin dark red outline to a blue fill with a thick dark blue outline (via a purple fill along the way). Stacking up multiple individual transitions to create one larger animation is something that SMIL excels at.
It’s important to note that the animated “d” values must all contain the same number of parameters for a smooth transition. Obviously the browser wouldn’t know how to animate from a 5-pointed star to a 12-pointed star; which lines should the new nodes appear on? But the same goes for the other parameters in a “d” attribute – if you want curved lines in your animation, you need to start out with them curved (even if the curvature is visually non-existent) to ensure that each part of the animation contains the same line types and number of coordinates for all the nodes and Bézier control points. If your paths contain different line segments the animation will still take place but, rather than a smooth transition from one shape to another, you’ll get sudden, discontinuous jumps from shape to shape. To my eye, SMIL animation is easier to follow than its CSS counterpart. Admittedly, it’s rather verbose which can result in having to edit a lot of elements to make a simple timing change. But that verbosity also has its advantages, as we’ll see next time – when we’ll also send our star on a trip along a path.