Icons in a rig share a slot count, but they do not all use every slot. A hamburger has three strokes and a cross has two. The third slot still exists, so it has to be somewhere and it has to paint nothing.
Conflating them is the mistake. A slot that is not in use needs:
Parking a spare slot at the centre of the canvas means a stroke that grows out of the middle of nowhere. Parking it on a sibling slot's geometry means it is born by splitting off that stroke, which reads as division rather than apparition.
That is a claim about motion, so here it is as motion. One slider, both choices.
parked is the three-line function from the rig: a slot with no geometry
of its own, carrying the number of the sibling it hides on. Here is the whole of the
minus icon from that chapter's rig, which is the only part of it this section needs.
import { lineSlot, parked } from "@/lib/morph";
// `minus` needs one of the rig's three slots. The other two park on slot 0, which is the
// stroke they will be born by splitting away from rather than appearing out of the canvas.
export const minusIcon = [lineSlot(6, 12, 18, 12), parked(0), parked(0)];The tempting shortcut is to rely on the overlap. If the parked slot sits exactly on its host, surely it is invisible and no opacity is needed.
It is not, and this was measured rather than reasoned about.
It gets worse with transparency. At stroke-opacity: 0.5 the doubled stroke measures 192
against 128 for a single one, so a translucent stroke visibly darkens wherever a slot is
parked.
So the compiler always emits a suppression track alongside the geometry. Parking decides where, and opacity decides whether.
Nothing that matters. The headline is zero runtime JavaScript, not one animated property, and two CSS properties is still zero JavaScript. Optimising for one property was optimising the wrong number.