Snap.svg Morphing Icon Button — Path-to-Path Icon Animation Snippet

Most "icon morph" buttons on the web fake it: two separate icons cross-fade, or a hamburger's three lines individually rotate and translate into an X via CSS transforms. This snippet does something more literal — the underlying d attribute of a single <path> element morphs directly from one shape's coordinates into another's, using Snap.svg's path.animate({ d: newPath }, ...).

What .animate({ d: ... }) actually interpolates

SVG path data is a sequence of commands (M, L, C, etc.) each carrying coordinate points. When you animate the d attribute, Snap.svg does not understand the *shapes* geometrically — it walks the current path's list of points and the target path's list of points, in order, and linearly interpolates each corresponding pair over the animation's duration. Point 1 of the start path glides toward point 1 of the end path, point 2 toward point 2, and so on.

Why this snippet's two paths morph cleanly

HAMBURGER = 'M6,9 L28,9 M6,17 L28,17 M6,25 L28,25' — three separate 2-point line segments (M start point, L end point), six points total.

A checkmark is naturally just two strokes — one short diagonal down, one long diagonal up — which would be only four points, structurally mismatched with the hamburger's six. This snippet's CHECKMARK string deliberately splits the first, shorter stroke into two collinear segments (M6,17 L10,21 M10,21 L14,25) purely to pad the point count back up to six, then adds the second stroke (M14,25 L28,9) — three M/L pairs, six points, matching the hamburger exactly. The extra midpoint at 10,21 sits exactly on the line between 6,17 and 14,25, so it changes nothing about how the checkmark *looks*; it only exists to give the morph a point to interpolate toward. Because both strings have the same number of commands in the same order with the same number of coordinate pairs, each point maps onto a sensible corresponding point on the other shape, and the interpolation reads as one coherent shape smoothly folding into another.

What happens when path structures don't match

If the two path strings had a different number of points or a different sequence of command types (say, one uses M/L/L and the other M/C/C with curves), Snap.svg's simple linear point interpolation has no semantic understanding of "this line corresponds to that curve." It still animates *something* — but the correspondence becomes arbitrary point-index pairing, and the mid-animation frames often look like the path is being dragged inside out or crossing over itself in an ugly, unpredictable way. Clean morphs are a path-authoring discipline, not an automatic feature: you get a good morph by deliberately constructing both path strings with matching command counts and orders, often by adding "dummy" points to the simpler shape so it structurally mirrors the more complex one.

The rest of the interaction

stroke is switched in the same click handler and eased by a CSS transition on the path, so the icon's color fades from white to green in step with the shape change (it is deliberately not animated through Snap, which reads the current rgb() value back and fails on it), and mina.easeinout (Snap's built-in easing namespace) shapes the timing curve so the morph accelerates then decelerates rather than moving at constant speed.