The two answers

Correspondence has to be decided somewhere. There are two somewheres, and picking one decides almost everything else about what you end up building.

By the end of this page you should be able to read any morphing library's front page and say which of the two it picked, and what it gave up to be there. There is no third answer, and nothing gets both.

Solve it on the device

Ship a solver. When a morph is requested, take the two shapes, work out the pairing, and animate.

Two of the steps are the interesting ones. Matching decides which stroke becomes which, which is Part 2's problem arriving again with no new information to solve it. Aligning works out the rotation and scale between a matched pair. The other three are preparation and arithmetic. Here is the whole sequence, and the demo below runs it a step at a time:

1. Normalise. Convert every command to a cubic, so the two paths are comparable.
2. Resample. Redistribute points evenly along each subpath so both sides have the same count. The number is a quality dial rather than a fixed figure: too few and a curve reads as a polygon, too many and every frame costs more to build. Now the lists are the same length.
3. Match subpaths. Score every possible pairing on things like centroid distance and arc length, then pick the cheapest overall assignment.
4. Align. For each pair, find the rotation, scale and translation that best maps one onto the other. This is a Procrustes fit, and it is what stops a stroke turning inside out.
5. Interpolate and spring. Walk the numbers, drive the whole thing with spring physics.

None of that work is visible in the finished animation, which is most of why it is hard to reason about. So here it is one step at a time, on the pair this manual opened with. Every number below is computed in the demo rather than typed into it.

That is real engineering and it works on anything you hand it. The appeal is obvious: you import a library, you pass it two icons, and it animates. No build step, no configuration, nothing to learn.

Write it down

The other option starts from an observation that sounds too simple to matter.

You already know both icons at build time. They are in your repo. A hamburger is not going to become a different shape between now and when a user clicks it.

So why is a phone recomputing a fixed answer, on every page load, forever?

Write the answer down instead. Divide every icon in a set into the same fixed number of parts, each one a slot, one <path> per slot, and declare that slot 0 of any icon becomes slot 0 of any other. Correspondence stops being a search and becomes a fact about how the icons are drawn.

menu     slot 0: top bar     slot 1: middle bar   slot 2: bottom bar
cross    slot 0: "\"         slot 1: "/"          slot 2: parked

There is no matching step. There is no cost function. There is nothing to get wrong on someone else's device, because there is nothing left to decide.

What each one buys

Once correspondence is fixed ahead of time, every frame of the animation is knowable ahead of time. Which means it can be computed at build and emitted as CSS keyframes, and a menu-to-cross toggle ships zero bytes of JavaScript.

It also means a wrong pairing is fixable. When a solver picks something you dislike, there is nowhere to put the correction: it will re-derive the same answer on every device forever. When correspondence is data in your repo, you edit it and commit.

And slots have identity, so they can be choreographed individually. The middle bar can leave 60 milliseconds before the outer two rotate. A solver has one similarity per subpath and nothing to address.

What each one costs

The solver wins on effort, decisively. Install, pass two icons, done. It also handles pairs you cannot know in advance, which the other approach cannot do at all, ever.

Writing it down costs a build step. That is not a detail to engineer away, it is the shape of the trade: a build-time answer requires a build.

The honest comparison

That last row is the one people underrate, and it is the subject of Part 8. Measured over 300 arbitrary icon pairs, 7.7% produce a morph worth shipping. Something has to notice the rest, and only one of these two approaches has a moment at which to notice.

Which this manual follows

The second one, because it is the less documented of the two and because the consequences are more interesting.

That is a choice, not a verdict. If you need to morph a pair your code will not know until it runs, stop reading and go install a runtime solver. It is the right tool and no amount of build-time cleverness gets you there.

Everything from here is about what becomes possible once correspondence is something you write down. Part 4 is how you write it.