Most "shrinking header" implementations swap two separate DOM trees at a breakpoint. Resizable Header is one motion.nav the whole time — a single element whose class names change and whose box framer FLIPs between them, so the shrink reads as one continuous move instead of a cut.

Structurally it's a <header> wrapping a single motion.nav — a shrink-0 logo on the left, a link row in the middle with room for a hover pill and an active underline, and a shrink-0 CTA plus mobile toggle on the right:

useScroll tracks scrollY; a useMotionValueEvent listener flips a single boolean the instant it passes scrollThreshold (default 24px). That boolean is the only thing driving the two class strings above — the layout prop on motion.nav does the rest, FLIPping the box from max-w-5xl/rounded-2xl to max-w-2xl/rounded-full on a spring instead of snapping:

The same 320/32/mass 0.9 spring as Mega Menu's panel morph — both are "resize a real box" animations, and both want that extra mass so a wide surface doesn't overshoot visibly on the way to its new width.

The link row carries two independent motion.spans, each bound to its own layoutId: a hover pill that fills whatever link the pointer is over, and a thin active underline that only follows a click. They don't know about each other — the hover pill can sweep past three links while the underline sits still on the one that's actually active:

sticky (default true) pins the header with sticky top-0 z-sticky; set it false for a header that scrolls away normally. For layouts where the page itself isn't the scrolling element — a modal body, a split-pane panel — pass scrollRef and useScroll tracks that container's scroll position instead of the window's. Below md, the link row and CTA hide entirely behind a hamburger button that opens an AnimatePresence dropdown sharing the header's border radius and shadow language.

Scroll it: one nav, one threshold, one spring — the bar becomes a pill and the two highlight tracks keep riding along underneath it.