SMIL and timing charts: planning SVG animation on paper

You want to animate an SVG's viewBox. CSS shrugs. You want the animation to keep playing when the SVG is dropped into an <img> tag. JavaScript shrugs. That's the corner SMIL still owns, and a piece on Smashing Magazine spends its time on the part everyone skips: how to plan the sequence before you type a single tag.

The tag, and the thing it can do

SMIL is the animation syntax that lives inside SVG. You nest an <animate> element inside the shape you want to move, tell it which attribute to change, and give it a duration:

<animate
  attributeName="fill"
  to="someOtherColor"
  dur="someDuration"
/>

That is the whole primitive. <animateTransform> covers the transform attribute, <set> handles a discrete jump. Per the article, each SMIL tag targets one element and one property at a time. So a fade-plus-slide is two tags. A palette shift across three shapes is three. The author's own line: "SMIL has a problem: it gets bloated quickly."

The upside is what those tags can reach. Geometry attributes — viewBox, stroke-width, clip-path references, fill-opacity — animate declaratively, no script attached. The article notes that many SVG attributes now have CSS property counterparts (geometry properties have been supported across the major browsers since 2024), but viewBox is called out as one that still has no CSS equivalent. It's also the reason SMIL survives in <img>-embedded SVG: the browser runs the animation, but it won't run any script inside that same file.

Timing charts as the source of truth

Once you have five or ten of these tags, the file stops telling you what happens when. The Smashing piece proposes a diagram that is deliberately low-tech: draw a horizontal or vertical line per animation, mark the start with a circle and the end with a bar, and stack them in temporal order. Labels carry the duration; you do not scale the lines to the millisecond. A dot lights up at t=1s; a bar drops at t=1.3s; the next line begins where the previous one ends.

Two things fall out of the chart. You can see, at a glance, which animations should share a start point — and you can spot the ones that should be chained to another animation's edge instead of pinned to an absolute timestamp. That is where syncbase timing comes in.

Pinning one animation to another

Syncbase values let you write a begin attribute in terms of another animation's id. The example from the source:

<animate
  id="colorChange"
  begin="1s"
  ...
/>

<animate
  id="opacityChange"
  begin="colorChange.end - 300ms"
  ...
/>

The second animation starts 300ms before the first one ends. Quote from the piece: "Using syncbase values, the beginning of an animation is positioned in time relative to the .begin or .end of some other animation." Change colorChange's duration later and every downstream begin moves with it. The chart is the map; syncbase is how you wire the map into the file.

A caveat the article calls out: with a negative offset, browsers may jump the animation "to where it would have been had the computer peeked into the future." So a syncbase reference to a not-yet-started animation with - 300ms on the front is not the same as a plain delay. Draw the chart first; you'll catch it there before the browser catches it for you.

What this actually unlocks

The through-line of the piece is not that SMIL is better than CSS animation. It's that SMIL is still the tool when the thing you need to move is an SVG attribute CSS does not model, and that a multi-shape sequence written straight into markup is only maintainable if you have a plan sitting next to the file. A line-segment chart on paper (or in whatever drawing tool is open) is that plan.

Two things worth trying on the next SVG you touch: animate viewBox with SMIL to reframe a diagram, and rewrite one existing keyframe sequence as id-chained SMIL to see whether the chart-then-code loop reads better than a wall of @keyframes percentages. If the chart looks tangled, the animation will be tangled. Fix it on the page first.