A card must animate from its slot in a grid to a full-width detail view, and animating its width, height, top and left is visibly janky. What is the FLIP technique, and how does it animate that layout change smoothly?

## The problem FLIP solves Some animations are *about* layout. A card grows into a detail view, an item flies from a list into a cart, a list reorders and every row slides to its new place. The naive implementation animates the properties that describe geometry — `width`, `height`, `top`, `left`, `margin` — and every frame of that animation asks the browser to redo layout for the affected part of the page and repaint it. On a small page you might get away with it; on a real one, with a grid of many cards, the per-frame cost blows straight through the frame budget and the animation stutters exactly when it is most visible. FLIP, named by Paul Lewis, restructures the problem: instead of animating *toward* the final layout, you jump to the final layout instantly and animate the *appearance* of the old one away. ## The four steps **F — First.** Before touching anything, record where the element is: ```js const first = el.getBoundingClientRect(); ``` **L — Last.** Apply the end state for real — add the class, append the node to a new parent, change the grid template. Then measure again: ```js el.classList.add('expanded'); const last = el.getBoundingClientRect(); ``` At this instant the element is already in its final position. The browser has done its layout work, once. **I — Invert.** Compute the transform that maps the final box back onto the original one and apply it, without a transition: ```js const dx = first.left - last.left; const dy = first.top - last.top; const sx = first.width / last.width; const sy = first.height / last.height; el.style.transformOrigin = 'top left'; el.style.transform = `translate(${dx}px, ${dy}px) scale(${sx}, ${sy})`; ``` The element is now laid out in its final place but *looks* like it never moved. **P — Play.** Animate the transform back to identity: ```js el.animate( [{ transform: el.style.transform }, { transform: 'none' }], { duration: 300, easing: 'cubic-bezier(0.2, 0, 0, 1)' } ).finished.then(() => { el.style.transform = ''; }); ``` Every frame between start and finish interpolates one transform. No layout property changes during the animation at all. ## Why this is faster The expensive work — recomputing the geometry of the page — happens exactly twice, both times during setup, rather than once per frame for the duration of the animation. `transform` and `opacity` are the two properties browsers can update most cheaply during an animation, which is why every serious motion system funnels its animations into them. FLIP is the general trick for expressing a layout change in that vocabulary. It also composes: to animate a whole list reordering, run First on every item, apply the new order once, then Last/Invert/Play each item. The list relayouts once no matter how many rows move. ## What it costs you FLIP is not free, and a senior answer names the costs. - **Scaling distorts.** A `scale()` stretches everything inside the element — text, padding, borders, `border-radius`, shadows. A card scaled 3× vertically shows fat, blurry text mid-flight. The standard remedies: counter-scale the inner content with the inverse scale (fiddly, and it must be animated in step), animate an empty proxy element and crossfade the real content over it, or avoid scale entirely by animating only position when the size change is small. - **You force layout twice.** Both `getBoundingClientRect()` calls make the browser compute geometry on the spot. Two of them at setup is a fine trade for a smooth animation, but batch them — measure all elements, then write all styles — rather than interleaving reads and writes per item. - **You must not paint between Invert and Play.** If the browser renders a frame after you have applied the final layout but before the inverting transform lands, the element flashes into its end position. Apply the invert in the same synchronous block as the measurement. - **Interruption is your problem.** If the user re-triggers the animation halfway, you cannot resume from a static assumption — you remeasure from the element's current visual position, which is what the current transform produced. Using `Element.animate()` helps here: `getAnimations()` finds the running animation, and its current state is inspectable. - **The DOM really did change at step L.** Focus, scroll position, and anything an observer reacts to move at the moment you apply the final layout, not when the animation ends. That is usually what you want, but it can surprise code that assumes the visual state matches the layout state. ## When to reach for it, and what else exists Use FLIP when the animation is genuinely a layout change and the naive version measurably stutters. Do not reach for it for a fade, a slide with a known offset, or anything already expressible as a transform — you would be adding measurement code for nothing. Animation libraries implement FLIP under the hood for shared-element and list-reorder transitions, so on a project that already has one, the honest answer is often "use the library's shared-layout animation, and know it is FLIP inside". The View Transition API is the platform's own take on the same problem — you mutate the DOM, the browser handles snapshotting and animating between the two states — and it removes most of this code where you can rely on it; browser support is still uneven, so check your targets rather than assuming. And sometimes the right senior answer is to not animate the layout change at all: crossfade between the two states, or animate a simpler stand-in. A 200 ms crossfade nobody notices beats a 400 ms morph that drops frames.