Every number in these lessons is a knob. Drag it, retype it, break it — the reading is the smaller half.

The faded rows are the road ahead, not a promise — the order moves when a lesson turns out to depend on one further down. Say so if you want something pulled forward. Bundled from the working files on 2026-09-05. Editing the CSS in a playground affects only this page, and nothing you change here is saved back to the repo.

Screens teleport. Brains don't.

Every object you have ever tracked with your eyes travelled through the space between where it was and where it ended up. Your visual system is built on that assumption — it is how you know the thing that arrived is the same thing that left. A screen breaks the assumption constantly: a menu that was not there is now there, fully formed, and you have to work out where it came from.

That work is small, but it is real, and it is the thing animation exists to remove.

This gives you a sharp definition of bad. Bad animation is not ugly animation — it is animation that adds work. It makes you wait. It moves things you were not asking about. It draws your eye to the wrong place. A page where everything animates is a page where nothing is emphasised, because emphasis is a contrast effect and contrast needs something still to push against.

And it gives you a definition of good that has nothing to do with taste: good animation is animation you do not notice, that leaves you feeling the interface was quick.

The gate

Before the how, the whether. The deciding variable is not how nice the animation is — it's how often the user will see it.

The logic is the first principle again. A first encounter with a modal is a moment of genuine confusion — where did this come from — and motion resolves it. The four-hundredth time you hit ⌘K, there is no confusion left to resolve. All that remains is the wait. Delight has a half-life; friction does not.

Sometimes the best animation is no animation. Emil Kowalski, You don't need animations

Now feel the difference

Three dots. Identical duration — the slider proves it. The only variable is the curve. Hit Race and watch which one you believe is fastest.

They arrive together. They always did. But ease-in feels slower than ease-out, and at 600ms it feels almost broken — like the page is thinking before it responds.

Read the little graphs to see why. Horizontal is time, vertical is progress. The playhead traces the curve as it plays.

• ease-in hugs the bottom at the start: time is passing, nothing is happening. That dead window sits exactly where the user's attention is highest — the instant after they acted.
• ease-out leaps up immediately, then flattens. The user gets confirmation in the first few frames, and the tail end — where nothing important is left to communicate — is where the time gets spent.
• linear is a straight diagonal, and reads as mechanical. Nothing with mass starts and stops instantaneously.
• ease-out-strong is the same shape as ease-out, pushed harder. This is the difference between motion that feels intentional and motion that feels like a default, and it is why the CSS keywords are rarely the right final answer.

So: entrances and exits get ease-out. Things responding to a user get ease-out. This is not a stylistic preference — it is front-loading the information into the window where the user is looking.

The full decision tree — including when ease-in-out and linear are right — is in Reference 01. Ease-in has essentially no place in UI.

Build the canonical entrance

This is the fade-and-rise you have seen on every well-made marketing page, including the one that started this. Edit the CSS; the preview updates as you type. Replay re-mounts the element so the entrance runs again.

Three things in that snippet are doing real work, and each is a rule:

1. Opacity and transform, and nothing else

These two are the only properties the browser can hand entirely to the GPU. It composites them without recalculating layout or repainting anything. Animate height, margin, or top instead and the browser redoes layout every single frame — for the animated element and potentially everything around it. That is where jank comes from. Comeau's cost hierarchy: height/width/left are expensive, background-color is middling, transform/opacity are nearly free.

2. Named properties, never all

transition: all 400ms works today and betrays you in three months, when someone adds a background-color to the card and it now lazily fades on hover for reasons nobody can find. Name what you mean.

3. 24px, not 200px

Set the translate to 200px in the playground. It stops reading as this element is arriving and starts reading as this element is flying in from somewhere. The motion should be just enough to imply the element came from somewhere — a suggestion of travel, not a journey. The Claude page uses 10px, 20px and 24px, and nothing larger.

The mistake to see once

Two cards. One starts at scale(0), one at scale(0.95). Replay a few times and watch the left one.

The left card is a magic trick; the right card is an object arriving. The difference is five hundredths of a unit of scale.

Why it matters is the first principle again: scale(0) has no size, so there is no object for your visual system to track — it has to accept that something materialised. A deflated balloon still has a shape. Starting from 0.95 gives the eye something to follow the whole way, so the arrival reads as continuous rather than as a cut.

Somewhere between 0.95 and 0.4 it stops working. Find that point yourself — that is the kind of judgement that does not transfer by being told.

The page that started this

Worth knowing what you were actually admiring. I pulled the source of claude.com/claude-for-chrome on 2026-07-29. It is not React — it's Webflow driving GSAP, with Lottie for the illustrated bits and Lenis for smooth scroll.

But the numbers inside it are the numbers from this lesson:

GSAP's power scale is just named curve strength — power1=Quad through power4=Quint, per the GSAP docs. So power2.out ≈ cubic-bezier(0.215, 0.61, 0.355, 1), and power4.out is the same shape as the --ease-out-strong you just raced. Reference 01 has the full translation table — that table is your reverse-engineering tool.

Retrieval

Close the reading above before answering. Getting one wrong here is more useful than getting it right by scrolling up.

Read this next

Primary source: “Great animations” — Emil Kowalski. Ten minutes, and the highest-density statement of this whole topic in existence. It lays out seven properties of good motion; this lesson only covered two and a half of them. Read it before the next lesson.

If you want the mechanics interactively, Josh Comeau's Interactive Guide to CSS Transitions is the best explainer of transitions anywhere, with a sandbox mode.

You have 16.7 milliseconds. That is the entire budget.

At 60Hz the browser gets about 16.7ms to turn your CSS into pixels on the glass, and it has to do it again before the next refresh, and the one after that. Miss the deadline and the frame doesn't arrive late — it doesn't arrive. The previous frame stays up twice as long. That doubled frame is what you see as a stutter, and there's a precise vocabulary for it that I'll lay out in a moment.

Lesson 0001 was about when and how fast. This one is about what — and the surprise is that whether motion looks smooth has almost nothing to do with how much you animate. It has to do with which property, because the property decides how much work the browser has to redo on every single one of those frames.

The words, first

I'm about to use a handful of terms that get thrown around as if everyone already feels what they mean. Most of them are informal. Here is exactly what each one refers to, so you can hold me to it.

Two more, and these are the ones the second half of the lesson depends on.

Where a property enters the pipeline

Every frame runs the same assembly line, top to bottom:

So the budget sorts itself, and it isn't a matter of taste:

Why those two are the free ones is worth understanding rather than memorising. Once an element sits on its own compositor layer, the browser has already rasterised it into a texture. Moving that texture, scaling it, rotating it, or turning down its alpha are operations the GPU performs on the finished picture. Neither property can change what any pixel is — only where it lands and how much of it you see. That is the whole reason they're cheap, and it also tells you exactly where they'll let you down. We'll get to that.

Feel the bill

Two lanes of identical squares. The bottom lane only ever animates transform and opacity — that's your control, the shape of a healthy frame. The top lane animates whatever you pick. Watch the counter, and more importantly watch the lanes.

Start on margin-left and drag the element count up, and watch the frame strip under the two lanes. Each bar is one frame, and the bar's height is how long that frame took. Even, short, green bars sitting below the dotted line is what smooth looks like. As you add elements, the top lane's bars start growing past the line and turning orange, then red — those are frames that missed the 16.7ms budget, and the top lane visibly stalls and jumps. The bottom lane keeps moving evenly the whole time.

If 400 elements doesn't faze your machine, push to 1200. The number where it breaks is your hardware; the fact that it breaks at all is the property. The control lane has no breaking point in this range, because compositing 1,500 already-drawn rectangles is precisely what GPUs were built to do.

Then work down the list. background-color and border-radius are noticeably cheaper than margin-left — layout is skipped, and layout is the expensive stage. box-shadow is the paint tier's worst offender because a blurred shadow means sampling a lot of pixels per element. And transform + opacity puts both lanes on the same animation, which is your sanity check that the lanes are otherwise identical.

The part nobody mentions

Now the demo that actually changes how you write code — and first, plainly, what the button does, because it isn't magic. Jam main thread runs this:

const end = performance.now() + 900;
while (performance.now() < end) { /* do nothing, on purpose */ }

That's a loop that spins uselessly for 900 milliseconds and refuses to return. Because JavaScript on a page gets one thread, and that loop is holding it, the browser cannot do anything else for those 900ms — it can't run other code, can't recalculate layout, can't paint. It is a deliberately stupid way to reproduce something your real app does all the time by accident.

Set the property to margin-left and press it. It counts down from three first, so you can look away from the button and watch the two lanes instead. Three things happen at the moment the banner turns red:

• The top lane stops dead. It's animating margin-left, which needs layout, which needs the main thread. The thread is busy, so no frames.
• The bottom lane keeps moving, perfectly evenly. It's animating transform, which was handed to the compositor thread — and that thread has nothing to do with the loop.
• The frame counter freezes and the little green square keeps spinning. The counter is incremented by JavaScript, so it's stuck; the square is a CSS transform, so it isn't. That pair is the clearest single picture of what "two threads" means.

When it unblocks, look at the frame strip: one enormous red bar sits where roughly 54 frames should have been. The worst frame readout puts a number on it — around 900ms instead of 16.7. Drag the block duration up to 2500ms if you want it to be unmissable.

That freeze is not a contrivance. It's a heavy React re-render, a large JSON parse, a hydration pass, an expensive IntersectionObserver callback — the ordinary stuff of real apps. A composited animation is the only kind that stays smooth while your app is busy — where "busy" means exactly what the loop above simulates. And your app is busiest at precisely the moments things are animating: route changes, modal opens, list loads.

This also explains why native scrolling stays smooth on a page whose JavaScript is struggling — scrolling is handled by the compositor too — and why a scroll handler that animates top feels awful. That one is back on the main thread, in the same queue as everything else.

“So why not transform everything?”

Because scale is not width. Transform scales the finished picture — including the text, the border radius, and the border. Both cards below travel from narrow to wide. Only one of them stays itself.

The scaled card's text smears, its corners flatten into ellipses, and its border thickens on two sides and not the others. Push scaleX to 6 and it's grotesque. This is the direct consequence of the thing that makes transform cheap: it is operating on a picture that was rasterised at the old size.

So the honest rule is not “always transform.” It is:

The professional version of the width problem is FLIP — measure the first and last positions in JS, apply an inverting transform, then animate it away, so the layout change happens once and the motion is composited. That's how GSAP's Flip plugin and the View Transitions API both work underneath. It's a later lesson; for now, know the name and know it exists.

The one everybody hits: height

height: auto has no numeric value to interpolate, so the classic accordion either snaps or gets faked. The two-line fix most people never learn is a grid track: an fr unit interpolates, and 1fr resolves to the content's real height.

The grid version still costs layout — fr is a track size, and track sizes are layout. That is fine, and saying so is the point:

Same reasoning rescues box-shadow, which is the paint tier's most common trap because every card hover wants one. Animating the shadow itself re-rasterises a blur on every frame. Instead, put the shadow on a pseudo-element that already exists at full strength, and animate its opacity:

.card { position: relative; }
.card::after {
  content: "";
  position: absolute; inset: 0;
  border-radius: inherit;
  box-shadow: 0 12px 28px rgb(0 0 0 / 0.18);
  opacity: 0;
  transition: opacity 200ms ease-out;   /* free tier */
}
.card:hover::after { opacity: 1; }

The shadow is painted once, at load. The hover only changes an alpha. This trade — pre-render the expensive thing, then animate opacity between states — is one of the most reusable moves in the craft, and it works for gradients and filters too.

will-change, and how to misuse it

will-change: transform tells the browser to promote an element to its own compositor layer now, before the animation starts, so the promotion cost doesn't land on the first frame. It is a real optimisation and it is the most over-applied property in CSS.

Every promoted layer holds its own texture in GPU memory. Put will-change: transform on a grid of cards and you've allocated a texture per card, permanently, for an animation that plays for 200ms when hovered. On a phone that is how a fast page becomes a slow one.

• Default to not using it. Browsers already promote elements they can see are animating.
• Apply it to the handful of elements that are about to animate — on hover of a parent, say — and remove it when the animation ends.
• Reach for it when you have measured a stutter on the first frame, not because a blog post said it makes things faster. Full details in MDN's own warning, which is unusually blunt.

Drill: verify it yourself (3 minutes)

You now have a claim that is checkable, so check it. This is the reverse-engineering muscle from lesson 0001, pointed at cost instead of easing.

1. Open any site you admire. DevTools → ⌘⇧P → “Show Rendering”.
2. Tick Paint flashing. Hover things, open a menu, scroll. Green rectangles are repaints. A well-built site flashes almost nothing while animating.
3. Tick Frame Rendering Stats and scroll hard. Watch for dropped frames.
4. Record a few seconds in the Performance panel while triggering the animation. Purple bars are Layout, green are Paint. On a good page, animation produces almost neither.

When I read the source of the page that started this course on 2026-07-29, every animated value was a y offset, a scale, or an alpha — GSAP's y: 10, y: 20, y: 24 compile to translate3d, not to top. Not one entrance animated a width, a height, or a margin. That page feels expensive partly because it never spends.

Retrieval

Close the page above. Wrong answers here are worth more than right ones obtained by scrolling.

Read this next

Primary source: “Animations guide” — web.dev. The canonical version of this lesson from the people who build the rendering engine, including the full property-to-stage tables. Ten minutes.

If the pipeline itself is what you want more of, MDN on animation performance and frame rate covers layers and rasterisation properly. And the height problem is on its way to being solved in CSS itself — interpolate-size: allow-keywords makes height: auto animatable, though support is still narrow enough that the grid trick remains the safe answer today.

One element arriving is a transition. Twelve elements arriving is an argument about what matters.

You can now pick a curve (0001) and pick a property that doesn't cost anything (0002). Both of those are decisions about a single element. Almost nothing on a real page animates alone — a hero has an eyebrow, a headline, a subhead, two buttons and an image, and they all want to enter at once.

Let them, and you get a flash: everything appears simultaneously, nothing is emphasised, and the eye has no entry point. It reads as a page that finished loading, not as a page that arrived.

There's a second effect that's easy to miss. Spreading the same total movement across time reduces how much is moving at any one instant, and simultaneous motion is most of what makes a page feel frantic. A staggered entrance is calmer than a synchronised one even though it contains exactly as much animation.

The two numbers

Everything about a group entrance falls out of two pieces of arithmetic. Both are in the readout below.

total   = duration + (n - 1) × step
overlap = step ÷ duration

Total is what the user waits. Overlap is what it feels like — and it's the one nobody says out loud. Drag things until the timeline underneath makes sense; the bars are when each item is actually moving.

1. Pull stagger step to 0. A flash. Everything lands on one frame and the group has no direction.
2. Push it to 260. Now watch the timeline: the bars stop touching. Each item finishes before the next starts, and you get the machine gun — a list being dealt out like cards. Total blows past two seconds.
3. Now find the band. Somewhere around 50–80ms against a ~400ms duration, the bars overlap heavily and the eight arrivals resolve into a single wave with a direction.

Check it against the page that started this course. Measured on 2026-07-29, it uses stagger: 0.075 — 75ms — against durations of 0.2 to 0.45s. That's an overlap ratio between 0.17 on its slowest sections and 0.38 on its fastest — inside the band, with the quickest 200ms transitions sitting right at its edge, which is exactly where a short UI transition should land.

Why per-item stagger breaks

Set the lab to 20 items and leave the step at 75ms. Total: about 1.8 seconds. The last item arrives so late that a user who scrolled to it already believes the page is broken.

This is the trap in every "add a stagger" ticket: the value is chosen against a mockup with six items and shipped against a grid with forty. There are exactly two honest fixes.

1. Budget the total, derive the step

Decide the whole orchestration is allowed 600ms, then step = budget ÷ (n − 1). More items means a tighter step, and the entrance keeps its length no matter what the CMS returns.

GSAP has both behaviours and names them, which is worth knowing because you will read it in other people's source: stagger: 0.075 means 75ms each, while stagger: { amount: 0.6 } means 600ms total, divided among however many there are. Motion's stagger() is the same idea. When you see amount, someone was thinking about exactly this problem.

2. Stagger fewer things

Only the first six or eight items need to arrive in sequence; the rest can come in as one group, or not animate at all. Nobody is auditing your grid for consistency — they're looking at the top of it.

The mistake to see once

Stagger with @keyframes means animation-delay, and animation-delay has a trap that transition-delay does not. Delete the word backwards from the CSS below and replay.

Without a fill mode, an element sits in its normal state during its delay — fully visible — and then snaps to the animation's first keyframe the instant the delay ends. Five boxes appear, then blink out one by one, then rise. It looks like a bug because it is one.

backwards tells the element to adopt the first keyframe's values during the delay. both does that and holds the last keyframe afterwards, which is what you usually want.

Transitions don't have this problem: their "before" state is just the element's resting CSS, so a delayed transition simply sits there looking correct. That alone is a decent reason to prefer transitions for entrances.

Build the hero

Here's the pattern worth taking to real work: one custom property per element carrying its position in the sequence, and one line of arithmetic doing the stagger. No :nth-child chains, and the delay survives reordering the markup.

Two judgements are buried in that markup, and they're the difference between orchestration and a for-loop.

The two buttons share one index

They're one unit — a decision point, not two independent objects. Give them --i:3 and --i:4 in the playground and it immediately feels fussy: you've asserted that "Get started" matters more than "Read the docs" by a measurable 70 milliseconds, and the user's eye now travels left-to-right through a button pair it wanted to compare at a glance. Stagger between groups, not between every element.

The art moves slower, not later

It gets 560ms instead of 420ms. Larger objects that move at the same speed as small ones read as weightless — this is straight out of animation's classic weight principles, and it's why the hero image on a good marketing page always feels slightly more settled than the text above it. Give .art the same duration as everything else and it reads as a sticker.

Set --step to 240ms and the whole thing falls apart in the way you now have vocabulary for: the overlap ratio goes from 0.17 to 0.57, the total from about 840ms to 1.5s, and five elements become five events.

When not to stagger

Lesson 0001's gate applies to whole orchestrations, not just single animations, and it bites harder here because stagger multiplies the wait.

• Menus and dropdowns. The user opened it to click something. Staggering the items delays the moment the list is readable. Fade the container, not the children.
• Scroll reveals on long grids. People scroll faster than your stagger. Items arrive after the eye has already passed them, which reads as lag. Keep it under 40ms and cap how many participate.
• Anything a returning user sees daily. A 900ms hero orchestration is delightful once and a tax on the fortieth visit.
• Exits. Almost never stagger an exit. The user has decided; drawn-out departure reads as the interface arguing. If you must, reverse the order and halve every number — which is 0001's enter/exit asymmetry applied to a group.

Retrieval

Read this next

Primary source: GSAP — Staggers. Even though we're writing CSS, this is the clearest statement of the whole model anywhere: each versus amount, from: "center", and grid-aware staggering across rows and columns. Read it as vocabulary for what you saw in the lab.

If you want the same ideas in the React-flavoured stack, Motion's stagger() is a short page and the API mirrors GSAP's closely. And MDN on animation-fill-mode is the two-minute version of the mistake above.

Everything you learned about a group entrance still applies. The only new variable is when it starts — and that one variable splits into two techniques that behave nothing alike.

In lesson 0003 the hero arrived on page load, and you chose the moment. Below the fold you don't: the reader chooses it, by scrolling, at a speed you can't predict. There are exactly two ways to connect scrolling to motion, they look identical in a screenshot, and picking the wrong one is the most common scroll-animation mistake on the web.

They're called trigger and scrub. Rather than define them at you, I want you to feel the difference first — it takes about a minute, and the rest of this lesson reads completely differently afterwards.

What you just saw

In trigger mode, scrolling past a point starts an ordinary animation — the same kind you've written in every lesson so far, with a duration and an easing curve. Once started it runs on its own clock and finishes no matter what the reader does next. Stop scrolling and it still completes.

In scrub mode, there is no clock. Scroll position is the animation's progress. Half-scrolled means half-animated, and it stays half-animated for as long as the reader sits there.

The word for this in animation tools is playhead — the marker showing which moment of an animation you're currently looking at, like the progress dot on a video. Normally time moves the playhead. In a scrub, the scrollbar moves it, and it goes backwards just as happily as forwards.

Now the comparison table is worth reading, because every row is something you just watched happen:

GSAP's ScrollTrigger does both, which is why people conflate them: scrub: true flips one into the other with a single property. In CSS the same split exists as animation-timeline: view() (scrub) versus an IntersectionObserver that adds a class (trigger).

Where it fires: the one number to get right

An IntersectionObserver fires when the element crosses the edge of a root box. By default that root is the viewport, and the edge is the very bottom — so the animation starts the instant one pixel of the element appears. That's too early: the element animates while it's still off-screen, and the reader arrives to find it already finished.

rootMargin moves that edge. It takes CSS-shorthand values and grows or shrinks the root box:

new IntersectionObserver(callback, {
  rootMargin: '0px 0px -15% 0px',   /* top right bottom left */
  threshold: 0
});

Drag the fire point in the lab above and watch the dashed line move. Around -15% is a good default: the element is meaningfully on screen when it starts, and it finishes well before it reaches the reader's centre of attention. Push it to -45% and you get the classic bad version — the reader is already looking directly at the element when it decides to move.

threshold is the other knob, and it's the wrong one for reveals. It asks "what fraction of the element is visible," which for anything taller than the viewport can never be satisfied. Leave it at 0 and control the timing with rootMargin.

The cardinal sin, which you must never ship

Every scroll reveal works by starting the element at opacity: 0. Which means if the thing that's supposed to reveal it never runs, your content is invisible — not unanimated, gone. A JS error above your observer, a blocked script, a bot, a reader who scrolled past before the observer attached: all of these produce a blank page, and every one of them is a content bug, not an animation bug.

The fix is three lines and belongs in the <head>, before the browser paints:

<script>document.documentElement.classList.add('js');</script>

<style>
  /* Un-hidden by default. Only a page that ran JS gets to hide anything. */
  .js .reveal { opacity: 0; transform: translateY(20px); }
</style>

Same idea if you use CSS scroll-driven animations later in this lesson: the animated state is the exception, the visible state is the baseline. And it's why the reveal below the fold is always a fade in from hidden — never a fade out that you undo.

Stagger it by batch, not by index

Three cards in a row cross the line together, and you want lesson 0003's stagger. The tempting version is to key the delay off the element's index in the list. Don't — card twelve then waits twelve steps for something that started when card ten crossed. Stagger by position within the entries the observer just handed you:

const io = new IntersectionObserver((entries) => {
  let batch = 0;
  for (const entry of entries) {
    if (!entry.isIntersecting) continue;
    entry.target.style.transitionDelay = `${batch * 60}ms`;
    entry.target.classList.add('is-revealed');
    batch += 1;
    io.unobserve(entry.target);   // reveal once, then stop watching
  }
}, { rootMargin: '0px 0px -15% 0px' });

Two details worth naming. The observer batches entries that crossed in the same frame into one callback, which is exactly the group you want to treat as one gesture. And unobserve is not an optimisation — it's the thing that makes the reveal permanent.

Which is the other setting in the lab. Flip re-trigger to "every time" and scroll up and down: the content re-hides. The second viewing answers no question the first didn't, and on a page that people scroll back through it degrades into flicker. Reveal once.

The CSS version, with no JavaScript at all

Modern CSS can drive an animation from scroll position directly. animation-timeline: view() replaces the animation's clock with the element's own progress through the scrollport — which, by the table above, makes it a scrub. animation-range says which slice of that progress the animation occupies.

The range keywords are the part worth memorising: entry is the phase where the element is crossing into view, cover is the whole time any part of it is visible, and exit is it leaving. So entry 10% cover 30% means "start once 10% into entering, finish 30% of the way through the visible span."

Note three things in that CSS. The animation is declared inside @supports, so a browser without the feature simply shows the cards — the cardinal-sin rule, satisfied without any JavaScript. The timing function is linear, because the reader supplies the curve. And there's no duration, because animation-range replaced it.

Support is real but not universal, and it's moving; check MDN's compatibility table on animation-timeline rather than trusting a number written in a lesson. The @supports gate means you never have to care very much.

So which do you reach for? The honest answer for reveals is still the observer, because a reveal wants a trigger and CSS scroll timelines are a scrub. But scroll-driven CSS is genuinely better than JS for everything that should be a scrub — reading-progress bars, parallax, image reveals — because it runs off the main thread, and that's exactly lesson 0002's argument arriving in a new place.

Now the harder question: should it animate at all?

You can build these now, which makes this the right moment to ask — and the answer is often no. Scroll reveals are the single most over-applied effect on the web, and the argument against them is unusually strong. On page load, motion earns its keep by directing attention: the reader has just arrived and doesn't know where to look. Below the fold, they scrolled toward this section deliberately. They already committed. Their attention is not in question.

Which is also the practical answer to the most common failure mode: revealing so much, so often, that a reader scrolling at normal speed is permanently reading content that is still in motion. Reveal sections, not paragraphs.

Reduced motion

The full treatment gets its own lesson. The scroll-specific version is short: remove the travel, keep the fade. A reader who asked for reduced motion still needs to see the content appear, and a 200ms opacity change is not what they were objecting to.

@media (prefers-reduced-motion: reduce) {
  .js .reveal { transform: none; }
  .is-revealed { transition-duration: 200ms; }
}

Deleting the reveal entirely is also fine — as long as the un-revealed state is visible, which it is, because you followed the rule at the top.

Read this next

Primary source: MDN — the Intersection Observer API. Read the "Intersection observer options" section slowly; the root/rootMargin/threshold model is the whole thing, and MDN's diagram of the root box is clearer than any explanation of the sign rule.

For the CSS half: scroll-driven-animations.style is a large gallery of runnable demos by the Chrome team's Bramus Van Damme, and the fastest way to see what the technique is actually good at. The narrative version is Chrome's scroll-driven animations guide, and the reference pages are MDN on scroll-driven animations and animation-range.

Nobody has ever complained that a dismissed dialog left too quickly.

Lesson 0001 gave you a rule with no exceptions in it: ease-out, or nothing — fast at the start, settling gently into place, because that's what physical things do when they arrive. Four lessons later it's time to say the part I left out. That rule was about arriving. Leaving is a different event with a different audience, and it wants almost the opposite treatment.

This matters more than it sounds like it should, because exits are where UI motion most often goes from "nice" to "why is this so slow." And it's the one thing you cannot fix by choosing a better curve — you have to notice it's a separate decision at all.

Why leaving is not arriving, backwards

Go back to what motion is for. An entrance has real work to do: something new is on screen, the reader doesn't know it's there, doesn't know where it came from, and doesn't know what it's related to. Motion answers all three, and it's worth spending 300ms to answer them.

An exit has almost none of that work. By the time something is leaving, the reader has already read it, already decided about it, and — usually — just clicked the thing that dismissed it. There is no comprehension left to support.

There's a perceptual asymmetry underneath this too. Waiting to see something is anticipation; waiting for something to go away is an obstruction, because whatever you want next is behind it. The same 300ms is pleasant in one direction and irritating in the other.

Three words, defined

The ratio

Below are two copies of the same notification, opened and closed by one button. The left one uses whatever settings you choose. The right one is the naive version — its exit is an exact mirror of its entrance, which is precisely what a single transition declaration gives you if you never think about it.

Press Open both, then Close both, and watch the right panel specifically. The state label under each panel tells you which phase it's in.

The default settings are a 320ms entrance and a 180ms exit — a ratio of about 0.56. That range, roughly half to two-thirds of the entrance, is where almost every well-behaved interface lives. Drag the exit up to match the entrance and the right and left panels become identical; that's the version most UI ships with.

Then drag the exit past the entrance and watch what a 600ms dismissal feels like. Nothing is technically wrong. It just feels like the interface is arguing with you.

Exit duration 0 is a legitimate setting and the lab will tell you so. A toast that simply vanishes is not a bug. The reader's attention has already moved on, and the only thing you lose is the small courtesy of showing where it went.

The curve flips too

The ratio is the big win, but the easing matters and it's the part people miss. Recall what the two families actually do:

An ease-out exit decelerates at the end, which means it spends its final milliseconds crawling the last few pixels while barely visible. That's the worst possible place to spend time — it's the part of the animation with the least information in it. An ease-in exit does the opposite: it starts gently, so the departure is legible, then gets out fast.

--enter: 320ms cubic-bezier(0.23, 1, 0.32, 1);   /* ease-out, strong */
--exit:  180ms cubic-bezier(0.4, 0, 1, 1);      /* ease-in */

Set the exit easing in the lab to one of the ease-out options and close the panels. The lab will call it out, but you should be able to feel it first: the panel hangs around at 5% opacity for a beat longer than it should.

Which way does it go?

The lab's exit direction control is a smaller decision but a real one. A panel that slid up into view can leave two ways:

• Reverse — back down the way it came. Reads as cancelled, undone, put back. Right for a dismissal, a cancel, an escape key.
• Continue — keeps travelling in the same direction and off. Reads as completed, sent, filed. Right for a message that was submitted or an item that moved somewhere.

Most of the time you want reverse, because most dismissals are cancellations. But if the thing genuinely went somewhere — an email sent, a card archived — continuing in that direction is doing real work: it's telling the reader where it went.

The engineering problem

Here's the part that trips everyone, and it's not about taste at all.

To animate something out, it has to still be on the page while the animation runs. But the thing that triggers the exit is usually the same thing that removes it. So the naive version is:

closeBtn.onclick = () => {
  panel.classList.add('closing');   /* start the fade-out */
  panel.remove();                   /* ...and immediately delete it */
};

That produces no animation whatsoever. The element is gone in the same frame, so there's nothing left to fade. Entrances never have this problem — the element is already there and you're just changing its style. Exits have it every single time.

The old answer was to do that bookkeeping yourself — add the class, listen for transitionend (or set a timer for the same duration), and remove the element in the callback:

closeBtn.onclick = () => {
  panel.classList.add('closing');
  panel.addEventListener('transitionend', () => panel.remove(), { once: true });
};

This works, and it's what the lab above does. It's also why AnimatePresence exists in Motion, and why every React animation library has some equivalent: React unmounts a component the instant its condition goes false, so the library's entire job is to hold the element in the tree a bit longer. When we get to React, that will be the one thing to understand about it — the API looks like magic, and it's really just a delayed removal.

The CSS answer

Modern CSS can now do this without any JavaScript, and it needs two features that only make sense together:

• transition-behavior: allow-discrete — permits discrete properties like display to participate in a transition. Instead of flipping immediately, display: block → none now waits until the end of the transition. That's the "keep it alive" half.
• @starting-style — declares the values an element should animate from the first time it appears. Without it there's no "before" for the browser to animate out of, so entrances from display: none just pop.

The demo below is pure CSS and HTML — a checkbox, a label and a panel, no script at all. Toggle it, then change the two durations independently.

Why the panel is position: absolute. An earlier version of this demo left it in normal flow, and the entrance looked broken while the exit looked fine — which is a strange enough asymmetry to be worth explaining. In flow, the panel takes up space, so the instant display flips to block the button is shoved (92px, in that layout) with no animation at all. You saw a jump, then a fade. On the way out, allow-discrete holds display: block for the whole 160ms, so the same jump happens after the fade finishes, where it's much harder to notice. Same bug, hidden in one direction. Taking the panel out of flow removes it entirely — which is also what every real popover does, and why lesson 0002's warning about Layout keeps turning up in lessons that aren't about performance.

The mechanism worth taking away from that CSS is not the two new keywords — it's where you put the transition declaration. A transition on the resting rule governs the journey to that rule, so the base rule's transition is your exit and the :checked rule's transition is your entrance. That's how you get two different durations and two different curves out of plain CSS, and it works with or without the discrete-animation features.

Support for @starting-style and transition-behavior is good in current browsers but not universal — check MDN's compatibility tables rather than trusting a number here. Degradation is graceful: an older browser shows the panel appearing and disappearing instantly, which is the un-animated baseline, not a broken page. Same principle as lesson 0004's @supports gate.

Interruption

One more thing the lab can show you. Turn on Auto-cycle, then click Close both mid-entrance. The panels turn around from wherever they are rather than finishing first.

That's a property of CSS transitions you get for free: they interpolate from the current computed value, not from a fixed start. Keyframe animations don't behave this way by default, which is a real argument for transitions in interactive UI. If a user can open and close something quickly — and they can — the exit must be able to become an entrance again halfway through.

When not to animate the exit

• Anything keyboard-initiated. Escape to close means the person is in a hurry and probably not looking at the animation. Cut it short or cut it entirely.
• High-frequency UI. Lesson 0001's frequency rule applies harder to exits: a menu you open forty times a day should close instantly.
• Anything blocking what comes next. If a modal's exit delays the page behind it becoming usable, the exit is costing real time.
• Error and destructive states. When someone cancels out of something worrying, get out of the way immediately.

And for reduced motion, exits are the easy case: drop the travel, shorten the fade, or remove it altogether. Unlike an entrance, an exit almost never carries information that has to survive.

Read this next

Primary source: Chrome — "Four new CSS features for smooth entry and exit animations". This is the clearest single write-up of @starting-style, transition-behavior: allow-discrete, and the overlay property, with runnable examples of exactly the pattern above.

Reference pages for the two features: MDN on @starting-style and transition-behavior. If you're building dialogs or menus, the Popover API gives you the open/close behaviour, focus handling and light-dismiss for free, and animates with the same two features.

And re-read the "interruptible" section of Emil Kowalski's "Great animations" now that you've felt it — it'll land differently than it did before lesson 0001.

Libraries don't save you judgment. They save you plumbing.

Everything you've learned so far — ease-out in, ease-in out, exits at half, transform and opacity only, overlap under 0.35, reveals get a trigger — is tool-independent. Those are the decisions. A library can't make any of them for you, and picking the wrong one won't save a badly-timed animation.

So the question isn't "which tool is best." It's narrower and much easier to answer: what does this specific animation need to be able to do? Four things separate the tools, and you can feel all four in about ninety seconds.

What you just saw

Play is a tie. Three different technologies, one indistinguishable result. Most animation on most sites is exactly this: something changes, something moves, it's over. If that's your whole requirement, use the simplest thing that works and stop thinking about it.

Interrupt is where lane 2 falls apart. The transition eases back from wherever it had got to — 40-ish percent — because a transition interpolates from the current computed value, always. The keyframe animation snaps to zero, because a running @keyframes owns the property outright: take the animation away and the element is instantly wherever the base rule says it is. There is no "from here."

Pause flips the loser. Keyframes have animation-play-state: paused. Transitions have nothing — no pause, no scrub, no playhead of any kind. A transition is a one-way trip between two states that the browser is managing on your behalf, and you are not invited.

Seek is where the Web Animations API stops being optional. Lane 3 sets currentTime to a number and lands there. Lane 2 gets there with a negative animation-delay, which works and is a genuinely useful trick, but the moment you are computing negative delays to fake a playhead you have outgrown declarative CSS. Lane 1 can't participate at all.

The four real tools

Now the table is consolidation rather than introduction, because you've felt three of the four.

The first three are free in every sense: no download, no dependency, no version to keep current, and no risk that the animation is missing while a bundle loads. That is a real argument, not a purist one. Reach past them when there's a capability you actually need — not by default.

What the two libraries actually give you

Both get described as "animation libraries," which hides the fact that they solve completely different problems.

Motion solves React's problem, not animation's

Lesson 0005 named the hardest part of an exit: the element has to outlive the state change that removed it. In plain CSS you now know two answers — allow-discrete with @starting-style, or a setTimeout matching the duration. In React neither works, because when state says the component is gone, React removes it from the DOM on the next render and there is nothing left to animate.

AnimatePresence is the fix, and it is worth understanding that it is not magic: it keeps the component mounted after you've said to remove it, runs the exit, and then unmounts. Delayed removal, with the bookkeeping done for you.

Two more things Motion does that are genuinely hard by hand:

• Layout animations. An element's position changes because the layout changed — an item was filtered out, a card moved to a new column. Motion measures before and after and animates the difference with a transform. That's the FLIP technique, and doing it by hand is measurably annoying.
• Springs. Motion expresses stiffness and damping instead of duration and curve, which is a different model of time — one that survives interruption naturally because the spring just gets a new target. That's its own lesson.

No JSX in this lesson, deliberately. When Motion arrives properly it gets a lesson of its own, with the React parts introduced slowly.

GSAP solves choreography

Everything in lesson 0003 was one group with one stagger, which CSS handles fine. GSAP earns its place when the sequence has structure: this starts, then this overlaps by 0.2s, then these four stagger, then the whole block reverses on a scroll-out. A GSAP timeline is a first-class object — you can name positions, insert relative to a label, reverse the whole thing, and seek to any point in it.

Expressing that in CSS means hand-computing every delay, and then re-computing all of them when you change one duration. That arithmetic is the plumbing GSAP saves you.

The other half is ScrollTrigger, which is the scrub half of lesson 0004 done properly — pinning, snapping, scrub with smoothing, and a set of callbacks at the boundaries. Native scroll-driven CSS is genuinely closing the gap for simple cases; it does not yet do pinning.

The decision, in the order you should ask it

Read that top-down and take the first yes. The order isn't arbitrary — it goes from least to most machinery, and the honest observation about production code is that most of it should stop at line 1 and a lot of it stops at line 2.

The mistake this lesson exists to prevent

Reaching for GSAP to fade in a card.

It's a common one, and it doesn't look like a mistake, because the result is fine. The cost is indirect: a dependency for something the platform does natively, an animation that can't start until JavaScript has loaded and parsed, and — the part that actually bites — the loss of the free interruptibility you got in lane 1 of the lab. GSAP can be interruptible, but you have to arrange it.

The inverse mistake is rarer but more expensive: hand-writing a twelve-step timeline with setTimeout because adding a library felt like defeat. If you find yourself maintaining a table of delays, the library was always the right call.

What doesn't change, no matter what you pick

Everything that matters, which is the actual point of this lesson.

• Ease-out for entrances, ease-in for exits. GSAP calls it power2.out; Motion takes an array or a named ease; CSS takes a cubic-bezier. Same curve.
• Exits run about half the entrance. No library defaults to this. You have to decide it.
• transform and opacity are free; everything else buys pipeline stages. GSAP animating width costs Layout every frame exactly like CSS animating width does.
• Overlap ≤ 0.35, and check the total separately. GSAP's stagger makes the arithmetic easier; it does not make a 2-second hero entrance acceptable.
• prefers-reduced-motion is yours to honour in all five.

A library that made those decisions for you would be a design system, not an animation library. None of these are.

Read this next

The MDN page for Element.animate() is short and is the fastest way to see that WAAPI isn't exotic — it's keyframes and options, in JavaScript. The API overview covers the playback controls you used in lane 3.

For the library side, skim rather than study: GSAP's Timeline docs to see what choreography-as-an-object looks like, ScrollTrigger for the pinning and scrub features native CSS doesn't have yet, and Motion's layout animations, which is the clearest short demonstration of why that one is hard by hand.

And Reference 02 — The Numbers is new: the six things worth memorising from lessons 0001–0005, and the syntax that isn't. It exists because of your question about how much of this you're supposed to be able to rebuild from memory. The answer is the six, and nothing below the line.

A menu that appears near a button and a menu that comes out of a button are the same pixels, in a different order.

Every scale you've written so far has quietly used the default, transform-origin: 50% 50% — the element grows from its own centre, in all four directions at once. That default is right for exactly one situation, and popovers, menus, tooltips and dropdowns are not it.

This is a small lesson about a single property. It's here because it's the most common tell of amateur popover motion, it costs nothing to fix, and once you've seen it you cannot stop seeing it.

What you just saw

The ring never moves. That's not a trick of the demo — it's the definition. transform-origin is the fixed point of the transform: the one place on the element that scaling and rotation leave exactly where it was. Everything else moves relative to it.

So the question "where should this scale from?" is really the question "which point on this element must not move?" And for anything anchored to a trigger, the answer is obvious once you ask it that way: the corner touching the button. That corner is where the panel came from. If it moves, the panel didn't come from anywhere.

On the right-hand lane, the ring sits in the middle of the panel, so the anchored corner starts some distance away and travels in. At the default scale of 0.85 that's about 14px of travel — small enough that you'd never file a bug about it, large enough that the panel reads as sliding into place near the button rather than opening out of it. Most motion problems are this size.

transform-origin is free in the sense of lesson 0002: it changes the matrix the compositor applies, not which pipeline stages run. Setting it costs the same as not setting it. There is no performance argument for leaving it at the default — only inattention.

Picking the origin

The rule is a mirror. Whatever edge of the panel is pinned to the trigger, the origin goes on that edge.

Percentages and lengths work too, and are what you want when the trigger isn't at a corner — transform-origin: 24px 0 puts the fixed point 24px in from the panel's left edge, on its top edge, which is how you aim it at a button sitting somewhere in the middle of a toolbar.

Computing it, when the position isn't known in advance

A popover whose placement flips depending on available space can't have a hardcoded origin. Measure instead. This is a case where a couple of lines of JavaScript are the right tool — lesson 0006's ladder, question 1: it isn't two fixed states, it's a computed value.

function aimAt(panel, trigger) {
  const p = panel.getBoundingClientRect();
  const t = trigger.getBoundingClientRect();

  // The trigger's centre, expressed in the panel's own coordinate space.
  const x = (t.left + t.width  / 2) - p.left;
  const y = (t.top  + t.height / 2) - p.top;

  // Clamp to the panel's edges — an origin outside the box is legal but
  // reads as the panel being flung from off-screen.
  panel.style.transformOrigin =
    `${Math.max(0, Math.min(p.width, x))}px ${Math.max(0, Math.min(p.height, y))}px`;
}

Call it after the panel is positioned and before it animates. If you're using the Popover API, that means inside the beforetoggle handler.

CSS anchor positioning is starting to make the placement half of this declarative, and it exposes the resolved side to CSS — which will eventually let the origin be chosen without measuring. Support is still uneven; check MDN's anchor positioning page rather than trusting a number written here.

The whole thing, in pure CSS

Same checkbox pattern as lesson 0005, so the exit asymmetry comes along for free. The only new line is transform-origin — change it to center and watch the menu detach from its button.

It governs rotation too

Everything above was about scale, but the origin applies to the whole transform. Rotation is where it becomes physical: change the origin and you change what kind of object you're describing.

Turn on add a rotation in the lab and tour the corners again. The left-hand panel now reads as unfolding from the button. The right-hand one reads as a card someone tossed onto the screen. Same 8 degrees.

For SVG, percentages resolve against a different box by default, and transform-origin: center often won't do what you expect. Set transform-box: fill-box first and percentages start behaving like they do in HTML. See MDN on transform-box.

Two mistakes worth naming

Scaling from zero. Drag the lab's scale down to 0.2 and open it. The panel arrives as a magic trick, and on the way in the text is unreadable — genuinely unreadable, not just small, because the browser is rasterising type at a fraction of its size. Anchored elements want 0.85 to 0.95. The scale is a hint about where it came from, not a birth.

Origin on the wrong element. If your panel has a wrapper that also transforms, the origins compose and you'll chase the bug for twenty minutes. Put the scale and the origin on the same element, and let the wrapper handle position only.

When to leave it alone

Two cases, and they're both about honesty.

A centred modal didn't come from anywhere in particular — it's a mode change, not an expansion of a control. Centre origin, small scale, brief fade. Aiming it at the button that opened it would be a lie about the interface's structure, and it looks like one.

A toast or banner comes from an edge of the screen, not from a point on itself. That's a translate, not a scale, and the origin never enters into it. If you find yourself setting an origin on a toast, you've probably picked the wrong transform.

And for prefers-reduced-motion: the origin is the cheapest part to keep. Drop the scale to something tiny or remove it entirely and keep a short fade — but if you keep any scale at all, keep the correct origin. It's the part carrying the meaning.

Read this next

MDN's transform-origin is short and worth reading in full for the value syntax — keywords, percentages, lengths, and the third value for 3D. transform-box is the SVG footnote above, and will save you an afternoon eventually.

If you're building anchored things generally, CSS anchor positioning and position-area are where the placement half of this problem is heading, and getBoundingClientRect() is what the snippet above leans on.

Then go find a real dropdown — your own, or any site with an avatar menu — and watch its top corner. You now have a fast, reliable way to tell whether anyone thought about it.

Every animation you've written has answered the question how long? A spring refuses to be asked.

Duration-and-curve carries a hidden assumption: that at the moment the animation starts you already know where it's going, and that nothing will change its mind on the way. For most UI that's true, which is why the model has served you fine for seven lessons.

It stops being true the moment a human is holding the thing. Drags, flings, sheets that can be caught mid-flight, a toggle clicked twice in 200ms — in all of those the target changes while the element is moving, and a function of time has no way to represent that.

What you just saw

At the interruption, the grey trace has a corner and the orange one has a curve. That corner is a velocity discontinuity, and it's the entire lesson.

A tween is a function of time. Give it a start value, an end value, a duration and a curve, and its position at any instant is fully determined. Change the target mid-flight and there is nothing to do but throw the old function away and start a new one from wherever the element happens to be — and the new function's opening velocity comes from the curve, not from what the element was doing a millisecond ago. With ease-in-out it stops dead and starts again. With a strong ease-out it yanks straight into a fast reversal. Both are corners. Neither has any memory.

A spring is a function of state — position and velocity. Changing the target changes one term in a force equation that is still being solved, and the velocity term is untouched. The dot keeps moving the way it was already moving and curves into the new direction, the way a thrown object does. That's what the readout is telling you: the spring carried real velocity across the change; the tween carried none.

Notice what you never typed: a duration. The settles in number is derived — the lab simulates the spring offline until it stops moving and reports how long that took. With a spring, duration is an output. That is the source of both its power and most of its annoyance.

The three numbers

A spring isn't a curve you pick, it's a rubber band you describe. Three properties describe it, and the motion is whatever falls out.

Those three interact, which is why tuning by dragging sliders feels like guesswork. It isn't, though — they collapse into one number that predicts the feel almost completely.

The damping ratio, which is the number that actually matters

ζ = damping ÷ (2 × √(stiffness × mass))

The lab prints it. It answers one question — does this overshoot, and by how much? — and that question is most of what a reader perceives.

Critically damped is a genuinely useful landmark: it's the boundary. Below it you're buying bounce; above it you're buying nothing at all. If you don't want bounce, aim at ζ ≈ 1 rather than cranking damping up, or you'll ship something that feels like it's moving through honey.

Here's what the lab's presets actually measure, so the numbers are attached to something:

Two things worth noticing. Bouncy is the slowest — bounce is not free, it's paid for in time. And gentle and snappy have almost the same ζ; the difference between them is stiffness alone. That's the practical tuning method: set ζ for how much bounce you want, then use stiffness for speed.

Settling time is not perceived duration

A spring approaches its target asymptotically — mathematically it never quite arrives, so "settles in 733ms" is really "gets within a rounding error in 733ms." The visible motion is over well before that. The tail is real in the numbers and invisible on screen.

This is the single most confusing thing about springs in practice, and it's why Motion added a second way to describe one. Instead of stiffness and damping, you can give it visualDuration — how long it should look like it takes — and bounce, from 0 (none) to 1 (extremely bouncy).

// Physics-first: precise, and hard to reason about.
{ type: 'spring', stiffness: 420, damping: 30, mass: 1 }

// Perception-first: the same idea, in units you can actually judge.
{ type: 'spring', visualDuration: 0.35, bounce: 0.2 }

Reach for the second one. You'll tune it in a third of the time, and the two axes are genuinely independent: visualDuration sets the stiffness, bounce sets ζ, and mass is pinned to 1 so it stops being a knob at all. That's the tuning method from the previous section — set ζ for bounce, then stiffness for speed — with the axes already pulled apart for you. Keep the physics parameters for when you're matching something specific.

bounce is ζ, inverted

These are not the same number, but they're one subtraction apart. Straight out of Motion's source, in both the duration and visualDuration paths:

ζ = 1 − bounce          // clamped to [0.05, 1]

So bounce: 0 is ζ = 1 — the critically damped row above. bounce: 0.3, the default, is ζ = 0.7. bounce: 1 is ζ = 0.05, which is very nearly frictionless and looks it. The lab's presets convert the same way: no bounce → 0, gentle → 0.21, snappy → 0.27, heavy → 0.42, bouncy → 0.66.

Two consequences worth carrying around.

You can't express overdamped. ζ > 1 is off the map — every bounce of 0 or below clamps to ζ = 1, so the third row of the ζ table is unreachable through this API. That's a deliberate omission rather than an oversight, given that the verdict on overdamped was "slower for no benefit." But if you ever want deliberate sludge, you need the physics parameters.

bounce is linear in ζ, and ζ is nowhere near linear in what you see. The first overshoot of a step response is exp(−πζ ÷ √(1 − ζ²)), which falls off a cliff:

The name invites a wrong reading: bounce: 0.25 overshoots by under 3%, not 25%. And going from 0.25 to 0.5 roughly sextuples the visible overshoot. Nearly all shippable UI lives between 0 and 0.4 — above that you're making something that is meant to be funny.

Springs in CSS, honestly

CSS has no spring. What it has is linear(), an easing function that takes an arbitrary list of output values instead of four control points — so you can hand the browser the shape of a spring, sampled.

The lab generates it for whatever spring you've dialled in; it's in the box at the bottom. Values above 1 are how the overshoot survives:

transition-duration: 629ms;
transition-timing-function: linear(
  0, 0.073, 0.223, 0.396, 0.561, 0.703, 0.816, 0.898, 0.949,
  0.988, 1.01, 1.021, 1.025, 1.024, 1.02, 1.017, 1.013,
  1.009, 1.006, 1.003, 1.002, 1.001, 1
);

When to use one

Yes: anything the user can grab. Drag-and-release, sheets and drawers, swipe-to-dismiss, a knob on a toggle, carousel snapping. Anything whose target can change mid-flight. Anything that should feel like it has physical weight.

No — and these matter more:

• Orchestration. Lesson 0003's arithmetic — total = duration + (n−1) × step — needs a duration. Springs don't have one, so a spring-driven stagger has no predictable total length. Use tweens for anything choreographed.
• Exits. Lesson 0005: get out of the way, fast, and don't come back. An overshoot on the way out is an element changing its mind about leaving. Tween exits, even when the entrance is a spring — the asymmetry is correct.
• Anywhere overshoot would be a lie. A progress bar can't go past 100%. A panel that overshoots past a container edge exposes whatever's behind it. A counter that springs past its value and back is telling the reader something false for 200ms.

Overshoot is not decoration — it's a claim that the thing has mass. That's true of a card you flung and false of a dropdown menu.

Three mistakes

Bounce on everything. There's a phase everyone goes through where the whole interface is made of jelly. The tell is bounce above about 0.3 on things that aren't being directly manipulated. Menus, tooltips and modals should almost always be ζ ≈ 1 or a plain tween.

Springing opacity. Opacity clamps at 1, so the overshoot is invisible — you get none of the character and all of the long tail, which reads as a fade that's mysteriously slow to finish. Spring the transform, tween the opacity alongside it at a short fixed duration. That pairing is what most good spring animations actually are.

Overshoot into a clip. If the parent has overflow: hidden, or the element sits flush against an edge, the overshoot is either invisible or ugly. Check the container before you buy the bounce.

Reduced motion

Springs are the worst offender here, and it's worth being blunt about it. Oscillation is precisely the kind of movement that triggers vestibular symptoms — more so than travel distance, which is what most prefers-reduced-motion handling worries about.

The fix is not a stiffer spring. Under reduced motion, replace it with a short tween or a plain fade. bounce: 0 is a compromise nobody asked for; a 120ms fade is an answer.

Read this next

Josh Comeau's "A Friendly Introduction to Spring Physics" is the best interactive treatment of the three numbers anywhere — read it if the sliders in the lab still feel arbitrary.

Motion's spring docs for visualDuration and bounce, and react-transitions for how a spring gets attached to a specific property — which is where the spring-the-transform, tween-the-opacity pattern above gets written down.

For the CSS side: MDN on linear(), Chrome's write-up for why it exists, and Jake Archibald's linear() generator, which does what the lab's output box does but with more control and a point-reduction pass.

prefers-reduced-motion: reduce is a request for less movement. It is not a request for a faster website, and those are different axes.

Somebody turned on a setting in their operating system — Reduce motion on macOS and iOS, Show animations off on Windows, Remove animations on Android. The browser forwards it to your CSS. Most of the people who set it did so because motion on a screen makes them feel physically unwell: nausea, dizziness, headache. That's vestibular — your inner ear's balance system, which takes moving imagery as evidence that your body is moving, and objects when the rest of your body says otherwise.

So this isn't a preference in the way dark mode is a preference. And the value in the spec is reduce, not none.

What you just saw

That reset in the middle option isn't a straw man I built for the lab. It's this, more or less verbatim, and it is in an enormous number of stylesheets:

@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
}

It gets the ambient band exactly right — that large drifting gradient is the single riskiest thing on the stage, and the reset stops it dead. Then it does two things you should not want.

It freezes the spinner. animation-iteration-count: 1 applies to every looping animation on the page, and a spinner's whole job is to loop. What's left is a static ring next to the words "Syncing 3 files…", with nothing corroborating them. The interface now claims to be working and shows no evidence of it. That's not a reduced experience, it's a broken one.

And it turns the entrances into jump cuts. A jump cut is the card appearing in its final position in a single frame, with nothing in between. Notice what 0.01ms actually did there: the card still moved 24px. It just did it too fast for you to see the path. The displacement is identical; only the smoothing is gone. For a reader who is sensitive to motion, an unexplained instant relocation is not obviously easier to take than a short smooth one — and it's harder for everyone to follow, because the thing that told you where the card came from has been deleted.

Why 0.01ms and not 0s, though? Because events. A duration of zero means some browsers never fire transitionend or animationend, and any JavaScript waiting on that callback to remove a class, unmount a node or release a focus trap simply hangs. 0.01ms is fast enough to be invisible and slow enough to still be an animation. Whoever wrote that reset knew exactly what they were doing — the mistake is treating a safety floor as a policy. Keep it at the bottom of your stylesheet to catch third-party CSS you don't control. Then write real rules for the code you do.

Three kinds of motion, three different answers

The reason a global rule can't be right is that "animation" isn't one thing. Sort every effect on a page into one of three buckets and the decision makes itself.

That third row has standing, not just taste. WCAG 2.3.3, Animation from Interactions asks you to let users turn off motion triggered by interaction unless the animation is essential to the functionality. A loading indicator is the textbook essential case. Reach for that exception honestly, though: "essential" means the information is unavailable without it, not that you like the effect.

What actually causes the problem

Worth being specific, because it changes what you cut first. Roughly in descending order of risk:

Two things to take from that. First, opacity is the workhorse substitute — it carries the "something changed here" signal with no direction, no displacement and no depth cue, which is why "fade in place" is the default answer for the whole informational bucket. Second, none of these have a number attached. There's no threshold in the spec, no "under 20px is fine." These are heuristics from accessibility practice, so when a case is genuinely borderline, fade it.

Springs, specifically

Lesson 0008 ended by pointing at this row. Oscillation is near the top of the risk list, and a spring's whole appeal is that it oscillates.

The tempting fix is to keep the spring and set bounce: 0 (or push the damping ratio to 1). Don't. You've removed the overshoot but kept the long asymptotic tail — a spring approaches its target and never quite arrives, so what you've built is a slow, soft, oddly indefinite move that is still drifting a second later. That's a compromise nobody asked for.

Under reduce, replace the spring outright with a short tween — 120–200ms, ease-out, no displacement. In Motion that's useReducedMotion() returning a boolean you branch the whole transition on, not a parameter you soften.

How to wire it, structurally

Three idioms, and only one of them scales.

1. Override. Write full motion, then take it back inside @media (prefers-reduced-motion: reduce). Reads naturally and is what everyone starts with. The failure mode is that it's opt-out per component — the day someone adds a new animated card and forgets the override, that card is unprotected and nothing tells you.

2. Opt-in. Put the motion itself inside @media (prefers-reduced-motion: no-preference), so the still version is the default and animation is the exception. Genuinely safer, and correspondingly annoying: every animated rule in the codebase now lives inside a media query.

3. A custom-property switch. One media query for the whole design system, and every component that reads the variable is covered the moment it's written:

:root {
  --travel: 24px;      /* how far things move */
  --dur: 380ms;
  --ease: cubic-bezier(0.23, 1, 0.32, 1);
}

@media (prefers-reduced-motion: reduce) {
  :root { --travel: 0px; }   /* that is the entire policy for informational motion */
}

.card {
  opacity: 0;
  transform: translateY(var(--travel));
  transition: opacity var(--dur) var(--ease), transform var(--dur) var(--ease);
}
.card.in { opacity: 1; transform: none; }

When --travel goes to zero the transform animates from none to none, the opacity transition is untouched, and the card cross-fades in place at full duration — without the component knowing the preference exists. That is exactly what the lab's third policy does; the CSS panel next to the stage has been showing you this rule the whole time. Ambient and status motion still get named individually, but there are only ever a few of those, and naming them is the point.

In Tailwind this is the motion-safe: and motion-reduce: variant pair — motion-safe:translate-y-6 gives you idiom 2 per-utility, motion-reduce:translate-y-0 gives you idiom 1. Prefer motion-safe:: an unprefixed utility is unprotected, and a motion-safe: one that you forget to write just means no animation, which fails in the safe direction. Docs here.

JavaScript gets none of this for free

The media query reaches CSS. It does not reach el.animate(), or GSAP, or Motion, or your IntersectionObserver from 0004. Ask directly:

const reduce = matchMedia('(prefers-reduced-motion: reduce)');

const travel = reduce.matches ? 0 : 24;

// People toggle this mid-session — often *because* your page made them queasy.
reduce.addEventListener('change', (e) => applyMotionPolicy(e.matches));

Reading .matches once at boot and caching it is the common bug. Someone hits your page, feels ill, goes to system settings, comes back — and your single-page app is still running the animations it decided on three minutes ago. The lab's live readout under the table is doing exactly this listen-and-repaint, which is why it updates if you change the real OS setting while this page is open.

Framework equivalents: Motion's useReducedMotion(), and GSAP's gsap.matchMedia(), which scopes whole timelines to a media query and reverts them cleanly when it stops matching.

Two more places CSS won't save you: scroll-behavior: smooth — a scripted smooth scroll is large-area motion the user didn't initiate, so gate it — and the scroll-driven animations from 0004. A scrubbed parallax is the single highest-risk pattern on the risk table and gets no automatic protection whatsoever.

Three ways to get this wrong

Treating it as a performance switch. Cutting durations is the reflex, and it's the wrong axis — you've made the same displacement happen faster. If you only change one number, change the distance.

Removing the animation and the element with it. This one bites hard. An element that starts at opacity: 0 and is only ever made visible by its own keyframe becomes permanently invisible the moment you write animation: none in your reduce block. The global reset happens to dodge this — 0.01ms is still an animation, so it still lands on its end state — but hand-written overrides don't. Every time you write a reduced-motion rule, actually turn the preference on and look at the page. Which brings us to:

Never testing the reduced path. In Chrome: DevTools → ⋮ → More tools → Rendering → Emulate CSS media feature prefers-reduced-motion. Set it to reduce and leave it there while you build the reduced version; you'll find the invisible elements in about ten seconds. Better still, spend a day with it on at the OS level (macOS: System Settings → Accessibility → Display → Reduce motion). Every one of those rendering emulations is worth knowing, but this is the one you'll use weekly.

What this changes about the previous eight lessons

Not much, structurally, and that's the good news. Everything you've built already separates transform from opacity because of 0002's four-property budget — and that separation turns out to be exactly the seam you cut along here. Reduced motion drops the transform and keeps the opacity. You've been writing reduced-motion-ready CSS since lesson two without knowing it.

The three things that need real re-examination: the stagger (a stagger of fades is fine; a stagger of slides is eight separate displacements), scroll scrubbing, and springs. Go back through anything you've built with those and give it the three-bucket sort.

Read this next

Val Head, "Designing Safer Web Animation For Motion Sensitivity" is the source most of the risk table traces back to, and it's written by someone who talked to affected people rather than reasoning from first principles. Read it before you argue with anything above.

MDN on prefers-reduced-motion for the exact semantics of the two values, and web.dev's write-up for the <video> and <picture> cases — you can swap an autoplaying video for a still frame with the same query, which is out of scope here but is the next thing you'll need.

WCAG 2.3.3 for the essential-motion exception, in the actual words of the standard, in case you ever have to defend keeping something.

Every animation in this course so far has been the page acting. Hover and press are the page answering.

That changes two things. First, the clock started before your animation did. Nobody has an expectation about when a scroll reveal should fire — but a finger that has already moved is waiting for the screen to agree, and it is counting. Second, whether half of this code runs at all is decided by hardware you don't control. There is no hover on a phone. Not "hover is awkward on a phone" — the event that turns a hover state off is never generated at all.

What you just saw

On the mouse, a hover state is self-cancelling. pointerenter turns it on, pointerleave turns it off, and you never think about it again. That symmetry is the only reason bare :hover has ever worked.

A finger doesn't do that. It arrives out of nowhere and it leaves without a forwarding address, so browsers on touch devices synthesise the mouse half: on tap they apply :hover, and — having no leave event to work with — they keep it applied until you touch something else. Your button stays lit. Your card stays raised. The dropdown you were proud of stays open behind the page the user has already moved on to.

This is not a browser bug. It's a browser doing the only reasonable thing with a rule you wrote for a device that isn't there. The fix is to stop writing that rule for that device:

@media (hover: hover) {
  .btn:hover { background: var(--accent-700); }
}

Note what is not inside those braces. :active stays outside. A finger cannot hover, but it can absolutely press — that's the entire input.

The 0.1 second line

Press-down has a hard ceiling, and it isn't taste. But a number you're told is a number you forget, so find it yourself first. The two buttons below are identical except for one value, and which side holds which is shuffled — so your first press is an opinion, not a confirmation.

The number you found in step 3 was probably somewhere near a tenth of a second. It isn't a coincidence and it isn't about buttons. Jakob Nielsen's three response-time limits named it in 1993:

0.1 second: Limit for users feeling that they are directly manipulating objects in the UI.

Past that line the feeling changes category. Under it, you pushed the button. Over it, you asked the computer to push the button and it did, shortly afterwards. Nothing about the pixels changed — the same 4%, the same curve — but the sense of touching the thing is gone. That is why the lab hides which side is which: told in advance that 400ms is worse, you would have agreed without ever checking, and this is a limit you want in your hands, not in a note.

So: press-down 0–100ms. Zero is a legitimate answer. And a useful corollary — at 80ms, every easing curve in Reference 01 looks identical, because there aren't enough frames to tell them apart. This is the one place in the course where you can stop thinking about the curve. Use ease-out and spend the attention elsewhere.

Down fast, up slow

That's the release tab. One side uses a single duration for both directions, which is what almost everyone ships; the other goes down fast and comes back slowly. Every setting of the symmetric side fails, and they fail differently — fast-and-symmetric snaps back like a switch, slow-and-symmetric breaks the ceiling you just found. No single number works in both directions, which is the whole point:

.btn {
  transition: transform 180ms var(--ease-out);   /* coming back up */
}

.btn:active {
  transform: scale(0.96);
  transition: transform 80ms var(--ease-out);    /* going down */
}

Note that the release duration is declared on the base rule and the press duration inside :active. A transition belongs to the state being entered, so the rule that turns the press on owns the going-down time, and the resting rule owns the coming-back time. Override only the transform and you get one duration in both directions by accident — which is exactly B.

Going down is your action, so it has to be instant. Coming back up is the system letting go, and a slightly soft release reads as physical resilience — you get most of what a spring would give you for one extra line and no library.

Who moved first

Now the third tab, which is the one that matters beyond this lesson. Both sides spend the same number of milliseconds. One spends it on a panel it slides in for you; the other spends it on the button under your finger. Push the slider to 300ms and press each a few times.

300ms on the panel is unremarkable — it's Reference 02's number for exactly that kind of move. 300ms under your finger is broken. Same duration, same curve, same property, opposite verdict. So the duration was never a property of the animation; it was a property of who started it.

This is also why lesson 0005's rule — exits run about half the entrance — isn't a separate fact to memorise. An exit is usually the system clearing something away, an entrance is usually the system bringing it in, and both are on the system's side of the line. The moment a gesture crosses it, the halving rule stops applying and the tenth of a second takes over.

Why scaling down reads as "physical"

Of the free properties from lesson 0002, scale is the only one that maps onto a physical press. Smaller means further away; further away under a finger means pushed. Opacity has no direction, rotation has the wrong one, and translation reads as the button sliding rather than yielding — though a 1px translateY is a good second choice when you want a key rather than a surface.

The number is not a constant, though. Scale is a ratio and displacement is what the eye reads, so the same scale on a bigger element is a bigger move:

edge displacement = (1 − scale) × width ÷ 2

Keep the edge displacement in the 2–4px band and derive the scale from the width, rather than reusing 0.96 everywhere and wondering why it looks wrong on the big cards. For anything full-width, stop scaling and darken the background instead — no displacement, same acknowledgement.

Origin matters here too, and lesson 0007 already gave you the rule: scale from where the gesture is anchored. For a press that's the centre, because the finger is somewhere in the middle of the target and the whole surface is yielding together. It's the one common case where the default transform-origin is also the right answer — which is why it's easy to forget it was ever a decision.

:hover, :active, or JavaScript

The ladder from lesson 0006 applies unchanged: two pseudo-classes cover the overwhelming majority of hover and press work, and reaching for pointer events when :active would do is how a button acquires 40 lines of state management and a bug where it stays pressed.

Gating it properly

There are four media features here and people reach for the wrong two. hover and pointer describe the primary input; any-hover and any-pointer describe any input the device has.

You will see @media (hover: hover) and (pointer: fine) a lot — Reference 01 says it, and I'm walking it back here. The and (pointer: fine) narrows the query to devices with a precise pointer as well, which excludes hover-capable inputs that aren't precise, and buys you nothing: sticky hover is caused by the absence of a leave event, not by imprecision. Gate on hover alone.

And note the direction of failure, which is the same argument 0009 made for Tailwind's motion-safe:. Writing the positive query — "when hovering is possible, add this" — means that forgetting the query leaves you with no hover effect, which is a nicety missing. Writing the negative one — "when hovering is impossible, undo this" — means forgetting leaves a stuck state on a phone. Prefer the version whose failure mode is boring.

Hover intent, in CSS

A cursor crossing your nav on its way to somewhere else shouldn't set off every submenu it passes over. The usual answer is a JavaScript timer; the usual answer is usually unnecessary. An asymmetric transition-delay does it:

.tip {
  opacity: 0;
  transition: opacity 120ms var(--ease-out);
  transition-delay: 0ms;        /* leaving: go now */
}

.trigger:hover .tip {
  opacity: 1;
  transition-delay: 300ms;      /* arriving: wait and see */
}

The delay applies on the way in and not on the way out, so a cursor passing through gets nowhere near 300ms and nothing happens, while a cursor that stops gets its tooltip. Leaving is immediate because the person has already decided.

JavaScript earns its place here in exactly one case: a submenu the cursor must cross a gap to reach, where it briefly leaves the trigger and hasn't arrived at the panel. That's the "safe triangle" problem, and it needs real cursor-trajectory logic. Everything short of it is a delay.

Keyboard gets neither

A keyboard user never hovers and never presses, and they are the reason this can't be left as a CSS detail. Any hover state that signals this is interactive needs a :focus-visible twin — not necessarily an identical one, but something in the same place doing the same job.

.btn:focus-visible { outline: 2px solid var(--ink); outline-offset: 2px; }

:focus-visible rather than :focus because the browser already knows the difference between a click and a Tab and will only show the ring for the one that needs it. This is why the old outline: none reflex is unnecessary as well as harmful — the problem it was solving no longer exists.

What reduced motion does to all of this

Good test of 0009's three buckets: where does press feedback go? Try to answer before reading on.

It's the safest thing on the page. Check it against the risk table: tiny area, no parallax, no depth manufactured beyond a 2px edge move, monotonic, short, and — the bottom row of that table — it answers a gesture the user just made. A press scale is at the safe end of every axis at once. Keep it under reduce.

What you do cut: hover effects with real travel. A card that rises 8px, a row that slides right, an arrow that shoots sideways. Same treatment as everything else — set the distance to zero and keep the colour change:

.card { --lift: 6px; }
.card:hover { transform: translateY(calc(var(--lift) * -1)); background: var(--paper-2); }

@media (prefers-reduced-motion: reduce) {
  :root { --lift: 0px; }        /* the same one-line switch from 0009 */
}

Three ways to get this wrong

1. Press feedback slower than hover feedback. If the button responds faster to being looked at than to being pushed, the hierarchy is inverted and it reads as broken without anyone being able to say why. Press is always the fastest thing on the element.
2. Hover states on things that aren't interactive. A card that lifts on hover is promising a click. If the whole card isn't clickable, you've spent the affordance on a lie and people will click the middle of it.
3. Testing with a mouse only. Chrome DevTools' device toolbar changes the viewport and touch emulation, and the lab above simulates the event sequence — but neither is a phone. The sticky hover, the missing :active, the tap that fires twice: those show up on hardware. This is the same failure as shipping an unlooked-at reduced-motion version.

What this changes about the previous nine lessons

Lessons 0001–0009 all answered "how long should this take?" with a property of the thing: modals are 300ms, toasts are 180ms, heroes are 500ms. That was the right model because in every one of those cases the system went first.

From here on there's a second question in front of that one — who moved first? If the answer is the user, the duration budget collapses to a tenth of a second and the device they used decides which rules exist at all. Reference 02's duration table still holds; it just now has a row above it that overrules it.

Read this next

Nielsen's three response-time limits is from 1993 and describes hardware that no longer exists, which is precisely why it's still cited — the limits are properties of people, not of computers. Short, and you will use the 0.1s number for the rest of your career.

"Solving Sticky Hover States with @media (hover: hover)" for the same problem written up with the browser-behaviour detail, and MDN on hover plus any-hover for what the four features actually promise.

Emil Kowalski, "Great animations" — the section on interruptibility is the part to read here. A hover animation that can't be reversed mid-flight is a hover animation that fights the cursor, and cursors change their minds constantly.

Everything in this course so far either appeared, disappeared, or moved on its own account. This one is about the third case: an element that was already on screen, is still on screen, and is now somewhere else.

Lesson 0002 sorted CSS properties by how far down the rendering pipeline they push you — layout, then paint, then composite — and the entire argument was to stay at the composite end. A card changing its position in a grid is a layout change by definition. So this looks like the one case where that budget simply cannot be met.

It can. You let layout happen — once, instantly, invisibly — and then you animate the pixels back. That inversion is the whole technique, and it has a name.

First, Last, Invert, Play

The four letters are the four steps, and the lab's four panels are them in order.

First. Before you touch anything, ask every element where it is: getBoundingClientRect(). Store the rects.

Last. Make the change — reorder the DOM, add a class, remove a filter, whatever it is. Then measure again. The browser has already laid the new layout out; the elements are, at this instant, in their final positions. If you did nothing else, this is the jump you saw in step 2.

Invert. For each element, apply a transform that maps its new rect back onto its old one. translate(oldLeft - newLeft, oldTop - newTop). Now the screen looks exactly like it did before the change — but the DOM doesn't. The DOM is in its final state from Last onward. Only the pixels are lying.

Play. Remove the transform with a transition on it. The element travels to where it already is.

Count the layouts: one. It happens at Last, before anything is on screen that the user could see move. Every frame after that is a transform going to zero — the composite tier, the cheap end of 0002's pipeline. The layout change didn't get animated. It got hidden, and a composite-tier animation was played over the top of it.

This also explains something that would otherwise look like a coincidence: FLIP animates whatever caused the layout to change. The lab's shuffle and its filter are completely different operations — one reorders nodes, the other hides five of them — and the FLIP code doesn't know or care which one ran. It measured before and it measured after. That is the whole interface.

The one line that breaks it silently

Step 4 was the important one. Setting the flush to skipped removes exactly this:

void el.offsetWidth;

and the animation stops happening. Not "looks worse" — stops. No error, no warning, no console output. The cards teleport exactly as they did with FLIP switched off entirely.

Here is why. The browser batches style changes. Within one turn of the event loop it will happily collapse transform: translate(-329px, -66px) followed by transform: none into a single computed value — the last one — because that is the only value that would ever be painted. The inverted position never existed as a frame, so there is nothing to transition from.

Reading a layout property forces the browser to resolve styles now, mid-turn, to answer your question honestly. That resolution is what makes the inverted position real. Any layout read works — offsetWidth, offsetHeight, getBoundingClientRect(), getComputedStyle(el).transform. The void is only there to stop a linter complaining that you threw the value away.

Why interrupting it works

Step 5: shuffling mid-flight doesn't snap. The cards pick up from wherever they visually are and re-route. That falls out of one fact that is easy to miss:

getBoundingClientRect() reports the box as painted — transforms included. A card that is 40% of the way through a FLIP measures at 40% of the way, not at the grid cell it is heading for. So First, on the second shuffle, captures the truth on screen rather than the truth in the layout, and the new invert is computed from there.

You get interruptibility for free, and you get it because the technique is built out of measurement rather than out of authored keyframes. There is no timeline to rewind. Compare 0008's springs, where interruptibility had to be designed in by carrying velocity across; here it is a consequence of asking the right question.

Two things the lab does not do, and you should know they are the hard parts:

• It only translates. When a FLIP also changes size you need a scale in the invert, and a scaled box stretches everything inside it — text gets fat, border-radius goes oval. The standard fix is an inverse scale on a child wrapper, which is fiddly and is the reason people reach for a library here.
• Nothing enters or leaves. An element with no First rect has no old position to come from, so a real implementation needs a separate entrance for it — which is 0003 and 0005, bolted onto the side of this.

Both of those are exactly what the browser now offers to do for you.

The browser will do all of this

Same idea, no measuring. You hand document.startViewTransition() a function that changes the DOM. The browser screenshots the page before your function runs, screenshots it again after, and animates between the two.

What the names are for

Without names you get a cross-fade, and that is the browser being honest: it has two pictures and no reason to believe anything in one corresponds to anything in the other.

view-transition-name supplies that reason. Give an element a name in the old state and give a different element the same name in the new state, and the browser treats them as one thing that moved and resized. It lifts each out of the page snapshot into its own layer, measures both rects, and animates between them.

Which is FLIP. Measure, measure, interpolate. The difference is that you didn't write it, and it's running on screenshots rather than on your live elements.

/* in CSS */
.tile.active, .detail-hero { view-transition-name: hero; }

// in JS
document.startViewTransition(() => {
  render(nextState);          // your normal DOM update
});

Two rules make the whole thing behave, and step 4 broke the second one:

1. The name must be on the source element before the transition starts. Set it inside the callback and the old snapshot has nothing by that name, so there's nothing to morph from — you get a transition that runs, reports success, and looks like a cross-fade.
2. A name must be unique in the document at capture time. Six tiles claiming hero is an error. The browser doesn't pick one, or animate the first — it throws the entire transition away, including the parts that were fine, and you get the hard cut. The log in the lab is the real rejection: InvalidStateError.

That second one is the production failure mode, and it is easy to hit for a boring reason: in a list, the obvious name is card, and then two cards are on screen at once. Names have to carry identity — card-42, not card.

Where it runs

Same-document view transitions — document.startViewTransition(), view-transition-name, skipTransition() — are in Chrome and Edge since 111, Safari since 18, and Firefox since 144. MDN's own summary: "Baseline 2025 Newly available. Since October 2025, this feature works across the latest devices and browser versions."

Read that date carefully. It is recent enough that a real audience still contains browsers without it — which is fine, because the fallback is a hard cut and needs no feature detection. The DOM change in the callback happens either way.

Cross-document transitions — the CSS-only @view-transition { navigation: auto; } that animates between two separate HTML pages — are a different story: Chrome 126, Safari 18.2, and not supported in Firefox at all as of this writing. That's the headline feature in most of the demos you'll find, and it's the one you can't lean on yet.

Choosing between them

Now that you've felt both:

The last row is the one that changes how a team works. Once the transition is started, every timing decision — duration, easing, which element moves and which fades — is a CSS rule on ::view-transition-group(), ::view-transition-old(), and ::view-transition-new(). Everything from lessons 0001 and 0002 applies to those pseudo-elements unchanged.

Check yourself

Read this next

Paul Lewis, "FLIP your animations" — the 2015 post that named the technique. Short, and the framing (invert the expensive thing rather than animating it) is the part worth keeping.

CSS-Tricks, "Animating Layouts with the FLIP Technique" — the practical write-up, including the scale-and-inverse-scale case this lesson only pointed at.

MDN, View Transition API and Chrome's same-document guide — MDN for the support tables and the pseudo-element tree, Chrome's for worked examples. Read the pseudo-element diagram before you try to style anything.

GSAP's Flip plugin and Motion's layout animations — both are FLIP with the hard parts done: nested inverse scaling, enter/exit, and shared-element transitions between components. In Motion it is one prop, layout. Now that you've hand-rolled it, that prop should read as a specific promise rather than magic — and 0006's ladder applies: reach for them when you need the scaling case, not before.

Lesson 0011 was about an element that was already on screen and is now somewhere else. This is the case before that: an element that was not on screen at all, and now is. It looks like the easiest animation in the course. It is the one that most often does nothing at all, quietly.

A CSS transition interpolates between two computed values. Two. Append a row to a list and its very first computed style — opacity: 1, no transform — is also its final style. There is no pair. Nothing goes wrong, so nothing is reported: the transition was simply never eligible to start.

Which means every entrance you have ever written had to manufacture that first value. There are three places to put it, they are not interchangeable, and choosing badly costs you something you will not notice until a user changes their mind. The lab runs the same 380ms and the same eight pixels through all three — plus the version with none at all, which is the one to press first.

Nothing ran

The first mode is not a broken demo and it is not a straw man. It is the code everybody writes first, and it is entirely reasonable-looking: there is a transition declaration on the row, the values it names are the values that change, and the row appears. The count under the stage is the only thing that will ever tell you.

getAnimations() is the instrument to remember. It returns every transition and animation currently attached to an element. When an entrance does nothing and you cannot see why, it answers the only question that matters — did the browser create anything at all? — and it distinguishes the two failures that look identical: nothing started (zero) from something started and it is wrong (one, going the wrong way).

Three places to put the first value

@starting-style is worth one sentence of precision because the name suggests something more magical than it is: it is an ordinary rule that is only ever consulted once, on the style update where the element first has a style — when it enters the document, or when it comes out of display: none. After that it may as well not exist. That is why the rows already sitting in the list in step 2 did not move: they had their first style update several presses ago.

Where you put the zero

Look at where opacity: 0 actually lives in each of those. In @starting-style it lives in a rule that becomes unreachable. In a from keyframe it lives inside the animation. In neither case is it the element's resting state.

Compare the pattern you will meet most often in real code:

.row      { opacity: 0; transform: translateY(8px); transition: … }
.row.in   { opacity: 1; transform: none; }

Here the zero is the resting state, and the element is only visible because something added a class. Lesson 0004 called that the cardinal sin of scroll reveals and gave you the fix — hide nothing unless a .js class proves a script ran. That fix is still correct and you should still use it. What is worth noticing now is that the other two mechanisms do not need it: with @starting-style or a from keyframe, an element that never animates for any reason is a visible element that did not animate. The failure mode is boring, which is the highest praise an entrance can get.

The gate: can she change her mind?

Two of those mechanisms will animate a new row and you cannot tell them apart by looking. 0011 ended on the question that separates them, in a different costume: can the user interrupt this? There it decided between FLIP and a view transition. Here it decides between a transition and a keyframe animation, and it is the same question with the same teeth.

Both panels below are the same notification, opening with the same 420ms and the same curve, closing with the same 320ms. One press drives both, because the difference is a thing you feel and a feeling does not survive being remembered.

Why A jumped

A transition has no timeline. It holds a start value, an end value and a curve, and when the end value changes it recomputes the start from what is on screen right now. That is why B's exit began at 0.76: 0.76 was the truth at that moment, and a transition has no other source of truth.

A keyframe animation does have a timeline, and swapping one animation for another starts the new one at its own zero. @keyframes out opens with from { opacity: 1 } and it means it — regardless of whether the entrance had got there. So the panel snaps to fully arrived and then leaves, which reads to a user as the interface briefly ignoring them.

Notice what panel A is not doing wrong. Its keyframes are correct, its curves are the ones this course would pick, and the JS that keeps it mounted for the length of its exit is the same bookkeeping lesson 0005 showed you and the same job AnimatePresence does in Motion. It is careful code. It simply cannot know where the entrance had got to, because a from keyframe is an assertion, not a question.

And at 500ms nothing disagrees, because by then there was no entrance left to interrupt. The whole difference exists only during flight. If you test an entrance by opening it, waiting, and closing it, you will never see this — which is exactly why it ships.

When the "before" is a number you had to measure

The fourth mode of the first lab is the one that looks the most primitive and is the most general. Its start value lives in a class the script adds before insertion and removes a moment later, and between those two moments there is one line doing all the work:

void row.offsetWidth;

Which is 0011's line, in the other direction. There it made an inverted position real enough to transition away from; here it makes a start position real enough to transition away from. Same problem both times: the browser batches style changes within a turn of the event loop and collapses any value that would never be painted, and a forced layout read is how you insist that one of them was real.

So why keep the primitive one? Because a stylesheet can only hold values you can type. FLIP's before is translate(-329px, -66px), computed at runtime from two measurements, and there is no rule you could have written for it. When the start value is data, it has to be set from script, and then it has to be flushed. That is the whole of the fourth row of the table.

Popovers, dialogs, and the one that still catches people

Everything above applies unchanged to <dialog> and the popover API, with one extra term. These elements are promoted to the browser's top layer — a layer above everything on the page, which is how a modal escapes an ancestor's overflow: hidden without anyone managing z-indexes. Promotion and demotion are controlled by the browser, not by your CSS, and demotion is instant by default.

Which produces a specific and confusing bug: the popover fades out correctly, and vanishes anyway on the first frame, because it left the top layer while it was still mid-fade. Four declarations fix it and three of them are already familiar:

[popover] {
  opacity: 0;
  transition:
    opacity 200ms cubic-bezier(0.4, 0, 1, 1),
    display 200ms allow-discrete,   /* keep it in the box model … */
    overlay 200ms allow-discrete;   /* … and in the top layer */
}
[popover]:popover-open { opacity: 1; }

@starting-style {
  [popover]:popover-open { opacity: 0; }
}

The pairing is the thing to hold on to: display keeps the element rendered, overlay keeps it on top, and forgetting the second gives you an exit that is technically running and visually absent. overlay can only be transitioned this way — it is not a property you are allowed to set yourself, only one you are allowed to delay.

Where it runs

@starting-style and transition-behavior: allow-discrete shipped together and are in all three engines: Chrome 117, Safari 17.4–17.5, Firefox 129. The popover API is a little older and a little wider. Transitioning overlay is Chromium only at the time of writing, which is survivable — without it the exit is a hard cut in those browsers, and a hard cut is the un-animated baseline rather than a broken page.

Check MDN's compatibility tables rather than trusting numbers written in a lesson; the point of quoting them is the shape of the degradation, not the versions. In every case here it is the same shape: the element still appears, still disappears, and still works. That is what makes these safe to reach for without a feature query — unlike 0004's scroll-driven animations, where the un-animated fallback would have been an invisible page and the @supports gate was load-bearing.

What you can now do

Write an entrance for something that did not exist a moment ago, and say which of three places you put its start value in and why. When an entrance silently does nothing, reach for getAnimations() before reaching for the prose. And when someone asks whether an entrance should be a transition or an animation, answer with a question about the user rather than about the syntax: can they change their mind while it is running?

Lesson 0012 was about an element that had no previous state, and all three answers did the same thing: manufacture the missing first value on the element. A starting opacity, a starting transform, a first keyframe. This lesson is about the other place a change can live — not on the element at all, but on the window in front of it.

Both get called a reveal. In one, the thing moves and fades into position. In the other, the thing was there the whole time, fully painted, at rest, and the only thing that changes is how much of it you are allowed to see.

One press drives both panes below, at the same duration and the same easing. The right-hand pane is the fade-and-rise this course has recommended since 0001, built properly — it is not the bad option, it is the other one. Watch the headline rather than the card.

Two effects, one word

The left pane never renders the headline at partial opacity and never moves it. At any frame you could stop on, the type is either absent or finished — full weight, full contrast, in its final position. The right pane spends its whole flight rendering type that is dimmer and lower than the type you are meant to read.

Neither of those is wrong, but they say different things. A masked reveal reads as uncovering something that already exists: an editorial header, a hero line, a value that was computed before you asked. A fade-and-rise reads as arriving: a new row, a toast, a result that did not exist a moment ago. When a designer says a reveal feels "too soft" or "too tentative", nine times out of ten they are describing a fade where a mask was wanted, and the fix is not a different easing curve.

The three shapes where the right pane's label changes to opacity only — no equivalent are the real argument. There is no way to move a block of type so that it arrives from its own centre line, or from a hole in the middle of itself. Those pictures exist only if something is clipping.

The shape is what stays

clip-path takes a shape and keeps what is inside it. Everything outside is not drawn — not transparent, not moved, not there. The element's layout box does not change, so nothing around it reflows, and hit-testing follows the visible shape.

clip-path: inset(0 100% 0 0);      /* right edge all the way in */
clip-path: inset(0 0 0 0);         /* every edge at rest: all of it */
clip-path: inset(0 0 0 0 round 14px);   /* the card's own corners */
clip-path: circle(0% at 50% 52%);  /* a radius, and its centre */
/* any straight-edged shape, and percentages may go outside 0-100% */
clip-path: polygon(0 0, 134% 0, 100% 100%, -34% 100%);

The four numbers in inset() are distances inward from top, right, bottom and left — the same order as margin. So a left-to-right wipe is one number moving from 100% to 0, and the direction of the wipe is which edge you chose to animate. Percentages in a polygon may go outside 0–100%, which is how the diagonal gets its overhang: the top-right corner sits at 134% so the tilted edge finishes past the card instead of cutting the corner off.

There is one rule that will cost you an afternoon if you learn it the hard way. A shape only interpolates against its own kind. Inset to inset, circle to circle, polygon to polygon with the same number of vertices. Cross a type boundary — inset to circle, or a four-point polygon to a five-point one — and there is no animation: the browser holds the first shape, swaps to the second at the halfway mark, and holds that. It is not an error and nothing is logged, so it looks exactly like a broken duration.

What it costs, and the question that actually decides it

Lesson 0002 put clip-path in the on credit row: it skips layout, so it will never cause the catastrophic kind of jank, but it is not free the way transform and opacity are — it re-paints, and the bill scales with the area being painted rather than with how complicated the shape is.

That framing is true and it is also not how you make the decision, because "is it expensive" has no answer without a number of elements and a size. The question that decides it is a capability question, and you can answer it before you write anything: could a rectangle have done this? Below are three builds of the same reveal — one clipping with clip-path, two clipping with an overflow: hidden wrapper — and five things the reveal might be asked to do.

The test, in four questions

Ask these in order, and stop at the first yes — a yes means the rectangle cannot do it and the paint is bought honestly.

1. Is the leading edge anything other than horizontal or vertical? Diagonals, curves, irises, anything you would describe as a shape. overflow: hidden clips to a box and there is no declaration that tilts it.
2. Does the window need more than one moving edge? Opening from a centre line is two edges at once. A wrapper is one window with one leading edge; two of them means two wrappers and two counter-transforms, which is more CSS than the shape was.
3. Must the content stay perfectly still and keep a radius that stays put? Either one alone is available to a wrapper. Both together are not: the build that holds the type still is the one whose window travels, and a radius on a travelling window travels with it.
4. Is the element you would have to wrap one you do not control? A wrapper is a new box in the layout — inside a grid, a flex row, or a component whose children someone else owns, adding one is a change to the layout, not just to the animation.

All four no? Then you are looking at a rectangle sliding behind another rectangle, and the two composited transforms are the answer — not because the paint would have been ruinous, but because you would be spending it for a picture you could have had for nothing. That is also the honest answer to the question 0002 left open, is animating clip-path actually safe: yes, at the scale a hero or a header runs at, and the measurement strip above is how you find the point where it stops being true on the hardware you are shipping to.

Reduced motion

0009's test was whether the movement is the message or the decoration. A wipe is an awkward case for it, because a wipe is not really movement — nothing translates — but it is a large area of the screen changing luminance on a schedule, which is exactly what the vestibular half of that audience is asking you to stop doing.

So the accommodation is not "make it shorter". It is to keep the reveal and drop the sweep: under prefers-reduced-motion: reduce, a masked entrance becomes an opacity fade of 80–120ms, or the element is simply present. The shape was carrying an idea about uncovering; a cross-fade gives up that idea, which is the correct trade, and shortening the wipe to 150ms does not — it just makes the sweep faster and harder to look at.

What you can now do

1. Reveal something without moving it, and say out loud why that reads differently from a fade-and-rise rather than calling both "a reveal".
2. Write an inset(), a circle() and a polygon() from the picture you want, including a radius on the window.
3. Recognise the halfway-swap failure on sight, and know it is a values problem rather than a broken animation.
4. Decide between a shape and a wrapper before writing either, with four questions and no benchmark.
5. Measure the point where the shape stops being free, on the machine that matters.

Eleven lessons got you the numbers. You can defend 180ms over 400ms and say why an exit is faster than an entrance. What you can't do yet is stand in a review and say that drawer should come from the edge it lives on, and right now it's fading in place — and end the argument rather than start one.

That's a vocabulary gap, not a technique gap. So this lesson has no new CSS in it at all.

Twelve patterns below. Each one plays, and each one has a switch that breaks the convention it depends on — never a straw man, always something real products ship. Break a few before you read another word.

Three families, three sets of rules

The grey chips under each pattern are the words for what you just watched; the table further down defines every one of them. First, the filter — which isn't decoration. The three families are the first useful cut in the whole subject, because a rule that is obviously right in one family is obviously wrong in the next.

Product UI is everything that appears, dismisses, and responds — modal, drawer, toast, popover. Its rule is get out of the way. These patterns are used forty times a day by someone trying to do something else, so they are judged on consistency and speed, and the highest compliment they can receive is that nobody mentioned them.

Expressive page is the landing-page family — heroes, line reveals, pinned sections, parallax. Its rule is pacing. Here the user is an audience rather than an operator: they are being walked through an argument, and motion is doing the job that paragraph breaks and subheads do in an essay. A 600ms reveal that would be intolerable on a save button is completely normal here, because nobody is waiting on it.

Direct manipulation is anything where the thing is under your finger — drag, swipe, deck, pull. Its rule is one to one, and then let go gracefully. This is the family where duration mostly stops being the unit at all: while you are dragging, the only correct number is your own hand position, and the entire design question is what happens in the half-second after you release. That is why springs exist, and it is the honest answer to why lesson 0008 felt like it was solving a problem you didn't have.

Say it out loud

Three vocabularies, doing three different jobs. The nouns are what the thing is — modal, drawer, toast, popover, hero, pinned section, deck. You have most of those already. The adjectives are how it feels, and they come at the end. The layer in the middle is the one you're missing, and it's the one that makes a review sayable.

Verbs are what the motion does. Every one of these is on screen above; the chips under each pattern tell you which cell to go back to.

Two more you will need before you meet them: morph, where one element becomes another rather than one leaving and one arriving, and shared element, where the same object persists across a change of view. Both are the subject of lesson 0011 under their engineering names.

What breaking it actually broke

Four of the twelve breaks are worth naming precisely, because in each case you already have the underlying principle from the engineering track and this is what it looks like from the other side.

The popover growing from its own middle is a wrong transform-origin, and nothing else — one value, no timing change. Lesson 0007 argued it as anchoring a scale to its source. The design sentence is shorter: the panel and the button stopped being the same gesture.

The hero arriving all at once is stagger removed. Note what it is not: it is not faster. Same duration, same easing, same four elements. It is flatter, because four things arriving together are four things competing and the eye has to pick a winner instead of being led to one.

The row that teleports is the whole of FLIP, in one felt moment. Lesson 0011 sold FLIP as a technique for animating a layout change you didn't author. Here it is as a promise instead: the gap opening is the list saying I know where this is going, and without it you have to re-read four rows to find out what you just did.

The card that dismisses on any movement removes snap-back, which is the single most under-appreciated pattern in this lesson. Snap-back is not an animation, it is a guarantee: you may begin this gesture and change your mind. Take it away and every swipe becomes a commitment, which is why the broken version feels less like a bug and more like a threat.

The adjectives, briefly

The third vocabulary is for diagnosis, and it is the one you already use — just imprecisely. Each of these has a specific cause, and pinning the adjective to the cause is what D012 drills. For now, the shortlist:

• mushy — wrong easing, usually ease-in-out where an ease-out belonged. Nothing has a clear moment of arrival.
• floaty — too long. The motion is still going after the interest has ended.
• laggy — the response didn't answer the hand. Almost always a press or hover that took more than 100ms (0010).
• busy — too many things moving in the same moment. No hierarchy.
• disorienting — something moved without spatial continuity. Things appeared where nothing was, or left in a direction that means nothing.
• unanchored — a scale or reveal that isn't tied to its source. The popover break, exactly.
• janky — dropped frames. The only one on this list that is a performance problem rather than a design decision (0002).
• gratuitous — technically fine, and shouldn't be there. The hardest one to say out loud and the most often correct.

Notice that seven of the eight are design faults with design fixes. "Janky" is the only one that sends you to DevTools, and it is the one that gets blamed most often — usually by someone who means "mushy" and doesn't have the word.

The habit

The rest of this track goes family by family and pattern by pattern. What makes it stick isn't the reading, it's a habit that costs nothing: when something moves, say the noun and the verb. Out loud if you're alone, in the review if you aren't.

"That's a drawer, and it's fading instead of sliding." "That's a deck with peek but no snap." "That's a hero with no stagger." Three seconds each, and the sentence is already a ticket someone can pick up.

You will be wrong sometimes, early. Being wrong with a name is enormously more useful than being right with a feeling, because a name is something another person can disagree with specifically.

Should this fade or slide? is the most common question in a motion review, and it is the wrong one. It has no answer, because it is a question about the animation — and the animation is not the decision.

Here is the version that does have an answer. Where is this thing when you can't see it? A drawer is past the edge of the screen. An account menu is inside the button you clicked. A confirm dialog is nowhere at all — it did not exist a second ago. Answer that, and the motion stops being a preference. It becomes arithmetic between two rectangles.

One small app, four things it can show you, and the only knob is a place.

Nothing there was an animation choice

Open The CSS behind it and switch homes with it open. Every value in that panel is derived. The panel's resting rectangle is fixed — that is what a nav panel is — and the home supplies the other end. Subtract one from the other and you have the transform. There was no point at which anyone chose a direction, a distance, or a fade.

This is why the question is worth changing. Fade or slide is a matter of taste and the loudest person in the room wins it. Where does this live when it's closed is a question about the product, and the answer is checkable: point at the button, point at the edge, point at the nothing.

Three kinds of home

Across the twenty-four combinations you just played, the ones that worked sort into three groups — and the three groups are the vocabulary.

Retrieved. The thing has a home off screen and you are fetching it. Drawers, sheets, sliding nav, toasts. It comes from its edge and it goes back to its edge, and the round trip is the point: it was put away, not destroyed. Everything in this group has a side, and the side is not negotiable — it is wherever the product decided that thing lives.

Grown. The thing lives inside the control that opens it. Account menus, popovers, tooltips, an expanding card. There is no edge involved; the origin is another element on screen — the anchor — and the motion's whole job is to say these two things are one thing. Get the anchor wrong and you have not made it uglier, you have made it a different object.

If you have read the engineering track: this is lesson 0007 from the other side. That lesson argues transform-origin as a property with a default that is wrong most of the time. This one says the same thing as a design claim — the anchor is where the object came from, and it is a fact about the interface rather than a coefficient.

Conjured. The thing has no home. A confirm dialog was not sitting somewhere waiting; it was made for this moment and it will be unmade. Modals, alerts, and command palettes live here.

Conjured is a real answer, not the answer you give when you can't think of one. But it costs something the other two get free. A retrieved element proves it still exists by going somewhere; a grown element proves what it belongs to by staying attached. A conjured element can prove neither, so something else has to carry that weight — which is what the scrim is for. Turn on Confirm dialog in the lab and watch the dimming: the scrim is not decoration and it is not a mood. It is the thing standing in for an origin, telling you the rest of the app is still there and still yours.

The exit is a claim about where it went

So far the round trip has been symmetrical: everything went back to the home it came from. That is a choice, and it is worth seeing broken, because the exit is where most real interfaces quietly stop making sense.

Three drawers below. Identical entrance, three ways out, all at the same time — one press.

The first one is the only one that keeps a promise. It came from the right, it went back to the right, and the screen still contains the information that the filters are over there. Nothing was said out loud; the drawer's own path said it.

The second is the one that ships most often, because a fade is the default and nobody argues with it. Watch it again and notice what it costs: the panel is not away, it is gone. That is fine for something genuinely conjured — a dialog that fades out is being honest about being unmade — and it is a small lie for something that has a home. It is why a drawer you use forty times a day can feel slightly unmoored without anyone being able to say why.

The third is the interesting failure, because it is the only one that is actively disorienting rather than merely mute. It came from the right and left on the left, so it is now on a side it has never been on. Reopen it and it comes from the right again, having apparently travelled back around. Every time a menu overlay does this, it is teaching the user a map of the interface that isn't true.

If you have read the engineering track: lesson 0005 argues that exits should be faster than entrances and use a different curve. That is about pace. This is about direction, and the two are independent — you can get the timing exactly right and still send the thing to the wrong place.

The sentence to say in a review

You now have a question that ends arguments rather than starting them. When someone shows you a panel and asks whether it should fade or slide, the reply is:

Where does this live when it's closed?

Either they can point at something — an edge, a button, or nothing — or they can't. If they can, the motion is settled and you are done. If they can't, you have found a real problem, and it was never a motion problem: nobody has decided what this thing is. That is worth fifteen minutes of the meeting and a fade is not.

And when you are the one being asked, the whole answer fits in a sentence of the same shape. It lives behind the hamburger, so it comes from the left and goes back to the left. It lives inside the avatar, so it grows out of the avatar. It doesn't live anywhere, so it's conjured and the scrim does the work. Nobody can disagree with that without disagreeing about the product, which is the only argument worth having.

Every screen you have ever made states a ranking. The headline is bigger, the primary button is filled, the caption is small and grey. Nobody writes that ranking down — it is just what the size, weight, colour and spacing add up to.

Those are your channels, and you tune them without thinking about it. Motion is one more channel in the same set. Not a garnish applied after the ranking is settled: a ranking instrument, and the loudest one in the drawer.

That claim deserves an experiment rather than an assertion. Four tiles. Each one is promoted by exactly one static channel, and the fourth is promoted by nothing at all. Then the motion — a nine-pixel lift, the kind that passes a review without comment — gets handed to whichever tile you choose.

The winner follows the motion. Not the size, not the colour, not the weight — the motion, every time, including when the moving tile is the one losing every static comparison on the board. Nine pixels beat a typeface set at one-and-two-thirds the size.

The reason is that the static channels compete for attention and motion does not. It interrupts. You can decide not to read a headline; there is no version of looking at a screen where you decide not to notice something move. That is also why a badge that appears at the edge of your vision gets you and a bigger badge already sitting there does not.

Anything that moves outranks everything that doesn't.

If you have read the engineering track: lesson 0003 is about how to build a stagger. This is about what a stagger says. The order you pick there is a ranking whether or not you were choosing one.

So the question in a motion review is not whether the animation is nice. It is what the animation ranked. Here is one card and one knob — which element moves. The timing, the easing, the distance and the class are identical for all eight choices; open The CSS behind it and switch between them to watch that stay true.

Three of those are marked as choices rather than mistakes, and that is not diplomacy. A card that exists to be read should promote the number; a card that exists to send you somewhere should promote the button. Both are defensible, and the useful question is never is this right but is the motion claiming the same thing the layout is claiming. When they disagree, one of them is lying and you get to decide which.

How the wrong thing gets promoted

Almost nobody chooses to make Export CSV the most important element on a revenue card. It happens the way most bad hierarchy happens: the animation was attached to whatever was easiest to attach it to. The last thing built, the thing that was already a component, the thing someone was touching that afternoon. Motion arrives on a screen the way it arrives in a codebase.

The everything setting is the other common accident, and it is worth sitting with. Six elements move, so motion has stopped ranking anything — except the first one. A stagger always promotes whatever goes first, so on that setting the word Revenue is now the lead element on a card about a number. Nobody decided that either; it is the order of the markup, promoted to a design decision.

What motion can't do

Set the lab back to Export CSV, press play, and then just look at the card a second later. It is identical to the card that never moved. The promotion lasted four hundred and twenty milliseconds and then handed everything back to the layout.

Which is the trap. If the wrong element is pulling the eye in the static design, animating the right one buys you less than half a second of correctness and then returns you to the problem. Motion is a hierarchy channel that only exists while it is running — that is exactly what makes it the loudest one, and exactly what makes it useless as a repair. Hierarchy problems are fixed in size, weight, colour and space. Motion can only agree with that fix or contradict it.

If you have read the engineering track: this is the design-side reason lesson 0004 insists a scroll reveal be cheap and small. A reveal promotes whatever crosses the threshold first, so a long page of them is a ranking of the page by scroll position — which is fine, as long as you meant it.

In the review

You now have a sentence better than I don't love that animation, which is a taste claim and cannot be argued with. The replacement is a rank claim, and a rank claim can be agreed with or disagreed with by someone who has never thought about easing:

What did that just promote?

Followed, when the answer is wrong, by the version that fixes something: that animation makes the export link the most important thing on this card, and I don't think it is. Note what is missing from that sentence. No duration, no easing curve, no opinion about whether it should fade or slide. Just the ranking, which is the part the rest of the room can see too.

What you can now do

Look at any animated screen and name the element the motion ranked first. Say whether the layout agrees. If it doesn't, say which one you would change — and know that the answer is almost always the layout, because the layout is the one that is still there afterwards.

A button is the smallest complete piece of interaction design in software, and it is the only one you can hold entirely in your head. Everything a bigger flow has to do — say it is available, say it heard you, say it is working, say it worked — a button has to do too, inside a hundred pixels and about two seconds.

Here is one save button, wired up properly, with a switch for each state. Switching a state off doesn't break the button — the click still saves, every time. It only removes what the button says while that is happening.

Every one of those states is answering a question, and the questions arrive in order. Can I press this, and is it the one I mean? — hover. Where am I? — focus. Did that land? — press. Is it working, or is it stuck? — pending. Did it work? — success. A button with a beautiful hover and no press state has answered the least urgent question on the list and skipped the most urgent one.

Press is the one that gets cut, and it gets cut because its absence is invisible in every medium a design gets reviewed in. It isn't in the mockup. It isn't in the spec. It isn't in the screenshot in the pull request. The only place it shows up is under a finger, and the only symptom is that people click twice.

If you have read the engineering track: lesson 0010 is the mechanics of this — how far to scale, why down and not up, why the release is slower than the press. This is the reason to bother: the press state is not a flourish, it is the receipt.

Nothing is a state, and it is the worst one

Run the lab with pending switched off and watch the nine hundred milliseconds in the middle. The screen is not doing something inadequate; it is doing nothing at all, and it is identical to the screen from before the click. Which means the user cannot distinguish working from the click missed from this app is broken — three very different situations rendered as the same pixels.

The job of a pending state isn't really to entertain someone for a second. It is to make the button inert — unresponsive on purpose — while keeping it legible. Those two have to happen together, and the common mistake is to get inert by reaching for disabled, which greys the label out. Grey means you can't do this. You want I am doing this. Same inertness, opposite sentence.

Which is the honest version. The other option is optimistic: show the result immediately, before the server has agreed, and roll it back if you were wrong. A heart that fills the instant you tap it is optimistic — and it is the right call, because it is nearly always right and the cost of being wrong is a heart quietly emptying again. A payment button is not, because the cost of being wrong is a person who believes they have paid. The rule is not about how long the request takes. It is about what a retraction would cost.

Disabled is usually an error message with the text removed

The seventh state is the one the lab doesn't switch, because it deserves an argument rather than a toggle. A disabled button is doing two things: refusing, and refusing to say why. The reason exists — a required field is empty, the plan doesn't include this, you already used your three — and the design has decided to hold it back until the user guesses.

The alternative is nearly always better and nearly never done: leave the button live, and spend the press on the explanation. They press Publish, nothing publishes, and the empty field it needs gets flagged and focused. That is one extra state and one fewer dead end, and it works on a touchscreen, where the tooltip strategy has never worked at all.

Keep disabled for the case where the reason is already visible on screen and nobody could miss it — the empty cart, the unticked terms box directly above. If you have to write a tooltip to explain the disabled state, the tooltip is the admission that the button should not have been disabled.

The state you are inside

Every state so far is momentary: the button decides what to say and says it. There is one more kind, and it changes the shape of the problem — the state the user is inside, and can leave.

Hold-to-confirm is the smallest example there is. Progress is scrubbed by the finger, at the finger's pace, and it can be abandoned at any point. Three knobs here, and all three are design decisions rather than tuning: how long you make somebody commit for, whether you show them the commitment, and what letting go early means.

With the indicator off, the button is functionally perfect and unusable, which is a cleaner proof than an argument: the progress fill is not decoration on the interaction, it is the interaction. Without it there is no way to know the hold is working, no way to know how much is left, and no reason to keep holding. A gesture with no progress feedback is a gesture nobody completes.

And the release is where the design actually lives. Letting go at 40% has to snap back, visibly and quickly — the user needs to see the thing they escaped from being undone. Keeping the progress feels reasonable in a spec and is quietly horrible in the hand: the button is now armed, and nothing told you. The snap-back also runs shorter than the hold that earned it, on purpose. A return is a dismissal, not a rewind, and it shouldn't charge you again for the time you already spent.

If you have read the engineering track: this is 0008's argument arriving from the design side. Once the user is inside the state, duration stops being the unit you think in — the finger sets the pace, and the only thing you get to time is what happens after they let go.

Two-and-a-half seconds is worth sitting with because it ships. Hold-to-confirm is a good pattern when the action is destructive and frequent — a dialog every time would be worse than the risk. It is a bad pattern when the action is destructive and rare: nobody discovers it, they tap, nothing happens, and they conclude the button is broken. Its real cost is that it has to be learned, and you only get to spend that once.

What you can now do

Review a control by walking its states out loud instead of reacting to its animation. Name the question each one answers, and find the one that isn't answered — it will usually be press, pending, or the reason behind a disabled. The sentence that gets you there is not I think the button needs more polish. It is: what does this button say between the click and the response?

A button is a request: you press it and something else happens. A drag is not a request. The thing is in your hand, and the interface has agreed to pretend that a rectangle of pixels is a physical object you have picked up. Every rule in this lesson comes out of protecting that pretence.

Start with the pretence itself. Two chips in one field. Both move with the pointer, and one of them has a CSS transition left on it. Grab either, whenever you like.

The ring is your actual pointer. On one chip the ring stays inside it; on the other the ring runs out ahead and the chip catches up afterwards. That gap is the whole failure, and it is worth naming precisely: the chip is no longer the thing you are holding. It has become a thing that is following you.

At 220 ms nobody misses it. At 60 ms most people can't name what's wrong and still behave differently — they overshoot, they move slower, they check. That is the part worth taking seriously, because 60 ms is well inside the range that gets called "smooth" by someone reading a spec rather than holding a phone.

This is almost never a decision anyone made. It is what you get when a drag handler is added to a component that already had a hover transition on it, and it is what transition: all guarantees. The fix is one line — the dragged element gets transition: none for as long as it is held — and the bug is invisible in every medium except a real finger on a real screen.

If you have read the engineering track: lesson 0002 is about which properties are cheap enough to animate. This is a different rule and a stricter one — on the thing being held, the answer isn't which property, it's don't.

So where is the design?

At the edges, and there are five of them: one at pickup, two during, and two at the release — because a release has two possible endings and they need different answers. Here is a list you can reorder, with a switch for each. As in the previous lesson, switching one off never breaks it: the order always comes out right. Only what the drag was saying goes missing.

Lift is the entire vocabulary of picked up, and it is borrowed from the physical world without apology: the thing rises toward you, so it casts a bigger shadow and grows very slightly. Two per cent of scale is plenty. Its job is to answer the question the hand asks first — am I holding this yet, or am I about to scroll the page?

Gap and ghost answer two different questions and most implementations only answer one. The gap says this is where it will land. The ghost says this is where it came from, and where it goes back to if you change your mind. Showing both at once costs one row of reserved space and is the more generous choice in any list long enough that the origin can scroll away from you.

If you have read the engineering track: the gap opening is a layout animation of the kind 0011 is about, and it should be built the same way — four rows each changing one transform. Nothing here animates height or margin.

Settle is the accepted ending. The row leaves your hand and travels into the slot it has been showing you, in about two hundred milliseconds, and it lands — no bounce. A bounce here is the most common way a competent drag ends up feeling like a toy, because overshoot implies momentum and there was none: you put it down, you didn't throw it.

Snap-back is the refused ending, and it is the one that gets skipped, on the grounds that people don't often drop things in the wrong place. They do, and the moment they do is the moment they most need an answer. Watch what happens with it switched off: the row is in your hand, you let go, and it is somehow back in the list with nothing joining the two. The first question is not did it move? It is did I just delete something?

If you have read the engineering track: 0008 is worth re-reading against this. A spring is right when the release carries velocity — a flung card, a sheet you shove downward. A row you put into a slot has none, and a spring will invent some.

Nobody can drag with a keyboard

Drag is the least accessible interaction pattern in wide use, and the fix is not an attribute. There is no ARIA that makes a pointer gesture available to someone who doesn't have a pointer. The only fix is a second path to the same outcome, and it is usually about ten lines: focus a row in the lab and press ↑ or ↓.

Worth being honest about who that serves, because "keyboard" undersells it. It serves someone with a tremor, someone using a switch or voice control, someone on a phone on a moving bus, and someone who simply finds a five-slot drag more fiddly than two key presses. A drag with no alternative path is a feature that quietly excludes people who have no way to report why they stopped using it.

The review question: what is the non-drag path?

What you can now do

Review a drag in three passes instead of one. Is the held thing exactly under the hand — no transition, no smoothing, no lag. Are both during-questions answered — where will it land, where did it come from. Do both endings exist — the settle and the snap-back, not just the happy one. Then ask what happens without a pointer. Four questions, none of which require a word about easing.

A deck is a room with one wall visible. That is a strange thing to put on a page, and it only works if the room tells you honestly how big it is. When a deck fails it is almost never because the sliding was badly animated. It is because you could not tell where you were, or you never knew there was anywhere else to go.

Here is one deck with four decisions in it. Three of them are the ones you'd name in a review. The fourth — how many items there are — is the one that actually decides the first, and it is the one nobody revisits after launch.

An indicator makes two promises

The two questions are not the same question, and no indicator answers both well. Dots answer both, brilliantly, up to about seven items — you take in five, and I'm on the second without counting, the way you take in the pips on a die. That is a perceptual limit, not a style preference, and it is why dots feel so right in the design file where the deck has four cards in it.

Past that limit dots do not degrade gracefully; they stop being information. Forty dots tell you there are many and put that non-answer in the exact place your eye goes for where am I. You saw it above: the active dot in a row of forty is not findable at a glance. A counter keeps both promises at any length, but you have to read it, so it never gives you the feeling of proportion. A bar gives you proportion at a glance and never tells you the count, so "one more swipe or nine" stays open.

So the review question is not are dots right here. It is how many items will this hold in a year, and then the indicator follows from the answer. A deck whose content is editorial and curated stays at five and keeps its dots. A deck fed by a query — recently viewed, in your area, more like this — will be at forty within two quarters and needs a counter or a bar from the start.

The peek is the whole affordance

Set the next card to hidden again and look at the deck cold. It fills its box. It has a clean edge on the right. There is nothing about it that says it is a strip rather than a panel — and a person who does not know it scrolls will not scroll it. The deck is fully functional and completely invisible, which is the most expensive kind of broken, because it reports as working.

A peek fixes this with no words: half an inch of the next card, cut off by the edge, is an unambiguous statement that the row continues. It is doing the same job an indicator does but it is doing it in the content, which is why a deck with a good peek can often drop the indicator to a bare counter and lose nothing.

This is why the peek is not a decorative margin choice, and why "make the cards fill the width, it looks tidier" is the single most common way a working deck gets broken in a visual polish pass. If someone asks for that, the thing to say is not I like the peek. It is the peek is the only thing on screen telling anyone this scrolls.

If you have read the engineering track: this is the same argument as the one in 0004 about revealing things on scroll — the cheapest affordance is always the one made of content that is already there, rather than a widget added next to it.

Snap, or drift

Snapping is a claim about what the items are. Snap says: these are pages, they have a correct position, and one flick moves you exactly one. Free scroll says: this is a continuous strip, and stopping halfway between two things is a legitimate place to be.

You felt the mismatch above. With drifts on, a flick leaves the deck at rest with two cards half-cut at both edges, and neither of them is readable — because these cards are pages, and half a page is nothing. Free scroll is right when the items are small enough that several are visible at once and cutting one at the edge costs nothing: a row of thumbnails, a tag strip, an avatar list. It is wrong the instant a single item fills most of the window.

There is a useful test. If the deck has an indicator at all, it must snap — an indicator says you are on item three, and free scroll makes that sentence false about half the time. A deck that drifts should be indicated by its peek and nothing else.

If you have read the engineering track: the release in a snapping deck is a velocity decision, not a position one — a short fast flick should advance a page even though the finger barely moved. 0008 is the argument for why that release wants a spring or a strong ease-out rather than a linear slide.

Autoplay has to argue for itself

Everything above assumes the reader moves the deck. Autoplay is the deck moving itself, and it is worth being precise about why it is contentious, because "autoplay is bad" loses to a stakeholder who wants three messages in one hero slot and has a good reason for wanting it.

The counter names a failure that is otherwise silent. Being interrupted mid-sentence does not feel like a bug while it is happening; it feels like your own failure to read fast enough. That is exactly why autoplay survives usability reviews — the person it fails does not report it, they blame themselves and leave.

Step four is the vicious one. Clicking back to a slide is an explicit statement of intent, and a deck that resumes afterwards overrules it. There is no reading of that interaction where the reader wanted the deck to keep going, which is why stop permanently on first interaction is not a nicety. It is the difference between a control and a fight.

So the position to hold in the review is not a ban. It is a set of conditions, and autoplay is fine when it meets all of them: the slides carry no text that takes longer to read than the interval — images, or three words; it pauses on hover and on keyboard focus; it stops permanently the first time anyone touches it; and it does not start at all for a reader who has asked for reduced motion. A hero of three photographs can meet every one of those. A hero of three paragraphs cannot meet the first, and that is the whole argument, in one sentence you can say out loud.

If you have read the engineering track: the reduced-motion condition is the strongest case of the argument in 0009 — an unrequested, looping, attention- grabbing movement is the precise thing that setting exists to switch off, so an autoplaying deck that ignores it is ignoring a direct request.

Check yourself

What you can now do

Look at any deck and say what its indicator is promising, whether the content will let it keep that promise a year from now, and what on screen tells a first-time visitor there is anything to the right of the edge. Say whether the items are pages or a strip, and hold the snap decision to that answer. And when autoplay comes up, argue it on the four conditions rather than on taste — the content test first, because it is the one that usually settles it.

Next: the same problem at a different scale. A deck moves content past a fixed window on purpose; a scroll-driven page does it as a side effect of the reader going down the page, and the design questions change completely.

D006 asked whether a deck's indicator could keep its promise as the content grew. A scroll system makes a larger promise: move your page, and I will move with you. It has to keep that promise whether the reader crawls, flicks, reverses, stops halfway, or skips the section in one gesture.

In the lab, do not start by making it beautiful. Start by deciding what kind of content it is, then make scroll the wrong kind of clock for it on purpose.

First question: must the middle frame mean something?

A trigger and a scrub can produce the same first frame and the same last frame. They disagree about every frame between. With a trigger, scroll says begin and then gets out of the way. Time finishes the movement even if the reader stops. With a scrub, scroll never gets out of the way: stop the page at 43%, and the animation must live at 43% indefinitely.

That gives you the review question: is 43% a valid picture? For a decorative entrance it usually is not. Half a clipped headline, half an opacity fade, or a person frozen midway through a gesture is merely unfinished. Trigger it. Let it arrive. For an explanation — an exploded object assembling, a route drawing, before becoming after — 43% may be the entire point. Scrub it, because the reader is inspecting the relationship between states rather than waiting for an entrance to end.

This is why trigger for product UI, scrub for storytelling is a useful smell and a bad rule. A hero entrance on an expressive page still wants a trigger. A data relationship inside a product can still deserve a scrub. The content of the middle frame decides, not the family the page belongs to.

If you have read the engineering track: 0004 teaches the mechanism as fire versus track. The design test is the sentence above it: stop at 43% and ask whether the frame communicates something complete. If it does not, the mechanism is already chosen before anyone opens an API.

Distance is duration

A time-based animation asks for milliseconds. A scroll-driven one asks for distance. The reader supplies the speed, so 500 milliseconds is not a thing the design can promise; half a viewport, one viewport, or two viewports per beat is.

A beat is one idea the page asks the reader to notice before it changes the subject. Give three beats half a screen each and a trackpad flick can consume the whole argument as one visual blur. Give a sentence two screens and the page starts charging admission for a thought that would have taken one line in normal flow. Both are pacing failures. One is rushed; the other is indulgent.

One viewport per beat is a useful starting point, not a law. Shorten it when the states are obvious and cumulative. Lengthen it when the middle is the content — an assembly, a comparison, a camera move whose spatial relationship needs time to be inspected. Then run the two adversarial gestures: cross the whole section in one fast flick, and creep backwards through it. Every beat still needs a legible resting point, and reverse order still needs to make sense.

Pinning spends the page on one comparison

Pinning holds a visual still while copy, labels, or states advance around it. It is right when the same object must survive across several beats so the reader can compare what changed. A phone that keeps its position while three features appear on its screen; a map that stays put while three routes are explained; a material that remains visible as its layers are peeled apart. The still object is the common noun in three changing sentences.

Turn the pin off in the lab and the later copy keeps talking about a picture that has already left. That is the honest failure. The reverse failure is more common in polished work: pinning a visual that never changes, then asking the reader to scroll through three screens of captions beside it. Nothing is being compared. The pin has turned ordinary reading into a toll booth.

Use this test: what must remain visually constant so the change is understandable? If you can name it, pin that. If the answer is nothing, let the page flow. Pinning is not a way to make a section important; it is a way to hold the control variable still.

Parallax is an adjective: deep

Parallax means layers move at different rates. The slower layer reads as farther away; the faster one reads as nearer. It is not merely motion in three places. It is a claim that the scene has depth.

That claim can clarify a hero made of foreground type, a product plane, and a background field. It can also make a flat layout feel like its cards have slipped off their grid. The knob in the lab is deliberately restrained: a few pixels are enough to make the planes disagree. If the content has no foreground/background relationship, the correct setting is one plane. Motion is the loudest hierarchy channel; three layers moving at three rates spend it three times.

A horizontal section is the same kind of claim about structure. Vertical scroll can drive a sideways sequence when the content is genuinely ordered left-to-right — a process, a timeline, chapters laid on one rail. Keep the page's vertical progress visible, keep a clear resting state at each chapter, and keep the section short enough that a reader always knows how to leave it. A horizontal translation does not become a deck just because cards move sideways: in a deck the hand moves the strip; here the hand still moves the page and the page maps that travel onto a stage.

If you have read the engineering track: D003's hierarchy argument applies here without being required background. Parallax does not decorate three layers equally; it ranks them by apparent distance, and the fastest plane will usually win your eye before the largest type does.

The native contract

There is a line between using scroll as a timeline and replacing scrolling with your own interpretation of it. Scroll-jacking is crossing that line: changing how far an input moves the page, changing its direction without a visible reason, trapping it inside a scene, or making the viewport ease toward the place the reader already asked to be.

The last one often arrives under the name smooth scrolling. Smooth means the viewport trails the input and catches up later. It can look luxurious in a screen recording because a recording has no hand in it. Under a real trackpad it feels laggy: the visible page is late relative to the gesture that caused it. That word is sensory, so here is the exact definition: laggy means the object you are controlling remains behind the position your hand already requested.

The trailing pane is not broken. It is a faithful version of a widely shipped technique: the input updates a destination, and an eased animation chases it. That is why the comparison matters. The case against scroll-jacking is not that its implementation is crude. It is that the implementation changes ownership. The reader issued a command and the page treated it as a suggestion.

There are defensible exceptions: a bounded story where the mapping itself communicates the idea, an installation meant to be watched rather than navigated, a product demonstration with a clear skip. But a normal page is not an installation. It contains links, reading, search, selection, the browser's back button, and a person who may simply be trying to reach the footer. Native scroll is the baseline because all of those behaviours already agree on it.

Reduced motion means changing the composition

Scroll effects are unusually important to reduce because they can occupy a large area, last for the entire journey down a page, and respond continuously to an interaction the reader cannot avoid. The accommodation is not to run the same camera move faster. Flatten the parallax. Stop scaling and rotating large planes. Let each beat be present in normal flow, or replace a scrubbed transformation with a short triggered cross-fade.

Keep the information. A progress bar can still report position. A pinned comparison can become a vertical stack whose captions sit beside their images. A horizontal chapter can become an ordinary list. Reduced motion is a different composition of the same argument, not a blank page and not a frozen first frame.

If you have read the engineering track: 0009 makes the accessibility decision element by element. For scroll systems, the seam is especially clean: keep status and sequence, remove simulated camera travel and depth. Both labs here keep the motion because it is the evidence being studied, and neither one moves until you ask.

The CSS behind it

The design decisions do not belong to one library. Native CSS can bind an animation to the nearest scroll container; JavaScript and timeline libraries can calculate the same 0–1 progress. The receipt is the same mental model either way:

/* A scrub: position, not elapsed time, owns progress. */
@keyframes assemble {
  from { transform: translateX(-20%); opacity: .2; }
  to   { transform: translateX(0);    opacity: 1; }
}

.piece {
  animation: assemble linear both;
  animation-timeline: view(block);
  animation-range: entry 20% cover 55%;
}

/* A trigger: crossing the line adds a class; time finishes. */
.line { transition: transform 420ms var(--ease-out-strong); }
.line.is-in { transform: translateY(0); }

Notice what is absent from that code: pinning, beat distance, and the reason for parallax. Those are layout and editorial decisions. CSS can make a sticky element and a timeline library can expose a pin option; neither can tell you whether the same visual must survive across three ideas. Tools implement the contract. They do not choose it.

Check yourself

What you can now do

Look at any expressive page and name its beats. For each one, say whether scroll merely starts it or owns every frame, and defend that answer by stopping in the middle. Price the beat in viewport-heights. Name what a pin is holding constant, what depth a parallax layer is claiming, and what tells a reader how to leave a horizontal section. Then test the native contract with one abrupt gesture: if the viewport keeps moving after the hand has stopped, say exactly what was taken away.

D007 made the reader the owner of a scroll timeline. Here the reader still owns attention, but the designer owns the order: what is the first thought, what follows it, and how much waiting is worth asking for? Text arrives well when the motion makes that order easier to feel. It fails when every character becomes a tiny appointment.

Start with the split, not the keyframes. In the lab, keep an eye on the two counters: the hero word can carry a beat per character because it is the picture. A paragraph is a sentence; making it wait for every character turns reading into a queue.

A split is a hierarchy made in time

Lines are usually the right first experiment for body copy. They preserve the sentence's shape while giving the entrance a clear cadence. Words can work for a short headline or a list whose items are genuinely separate. Characters are a special effect: one hero word, a logo-like title, or a deliberate spelling-out moment. Character-splitting ordinary prose is almost always wrong because the eye has to reconstruct words while the animation keeps changing the target.

This is not a ban on letters. It is a question of ownership: what is the reader waiting for? If the answer is “the next idea,” split by line or word. If the answer is “this word forming,” split by character. A 35ms delay can feel like a quick beat; 80ms is countable. The more units you create, the more total time you spend even when each delay looks tiny.

If you have read the engineering track: 0003's stagger lab gives you the arithmetic. D003's hierarchy claim is the design test: the unit that moves first is the unit you have ranked first. No engineering-track lesson is required to use that test.

Mask or fade: uncovering or arriving?

A mask reveal changes the window in front of still type. It says, “this was here; now you can see it.” A fade-up changes the type's state. It says, “this is entering your attention.” Both can be beautiful. They are not interchangeable, and a comparison needs to be simultaneous or your memory will quietly pick a winner for you.

Use a mask when the spatial place is stable and the reveal itself is the story: a line being uncovered, a crop opening, a title emerging from behind a surface. Use fade-up when arrival is the story: a new section, a caption gaining focus, or a sequence where the words should feel newly present. If the type should not move, do not fake its movement just because a split-text preset offers one.

If you have read 0013: that lesson calls this the window- versus-content decision. D008 applies the same distinction to typography, where a few pixels of travel can change whether the reader experiences “uncovering” or “entering.”

Keep the reading intact

Runtime line splitting depends on font metrics and available width. Fonts load, windows resize, and a line that was one unit can become two. A robust implementation re-splits after those changes, preserves the original text for assistive technology, and keeps generated units out of the accessibility tree. If the effect is decorative, the sentence must remain a sentence when motion is removed.

There is also a practical CSS detail: character spans can break words if they are allowed to wrap independently. Keep characters inside word-sized wrappers, or the demo teaches a broken line break instead of kinetic type. The lab does this deliberately so you can resize it without losing the thing being taught.

The CSS behind it

/* Split only as finely as the idea changes. */
.line { overflow: hidden; }
.line > span { display: block; }
.unit { display: inline-block; }

.is-playing .unit {
  animation: arrive 520ms var(--ease-out-strong) both;
  animation-delay: calc(var(--i) * var(--step));
}

@keyframes arrive {
  from { opacity: 0; transform: translateY(14px); }
  to   { opacity: 1; transform: none; }
}

@keyframes uncover {
  from { clip-path: inset(0 0 100% 0); }
  to   { clip-path: inset(0); }
}

Check yourself

Ask yourself: what is the smallest unit of meaning in the real page you want to animate? Bring one headline and one paragraph next time; we can choose their splits before choosing a library.

Gate 1 — Should this animate at all?

Frequency of use decides. The more often a user sees it, the shorter and subtler it must be — and past a threshold, absent.

Gate 2 — What is the purpose?

Every animation needs an answer. These are the legitimate ones:

“It looks cool” is not on this list. If that is the only answer and the user sees it often, cut it.

Gate 3 — Which curve?

Is the element entering or exiting?
├─ yes ─────────────────► ease-out
└─ no
   ├─ moving/morphing on screen? ──► ease-in-out
   ├─ hover or colour change? ─────► ease
   ├─ constant motion (marquee)? ──► linear
   └─ anything else ───────────────► ease-out

The curve library

The CSS keywords are too weak to feel intentional. Use custom curves. Paste this block into any project:

:root {
  /* Entrances, exits, anything responding to the user */
  --ease-out-strong:    cubic-bezier(0.23, 1, 0.32, 1);
  /* On-screen movement from A to B */
  --ease-in-out-strong: cubic-bezier(0.77, 0, 0.175, 1);
  /* Drawers and sheets — the iOS feel, via Ionic */
  --ease-drawer:        cubic-bezier(0.32, 0.72, 0, 1);
}

Keyword equivalents

What the CSS keywords actually are, per MDN. Useful when you want to nudge a keyword rather than replace it:

Reading a cubic-bezier

Four numbers: cubic-bezier(x1, y1, x2, y2) — two control points. X is time, Y is progress. Both curves always run from (0,0) to (1,1); only the handles differ.

• First handle low and left (x1 small, y1 large) → leaps forward immediately. That is ease-out character.
• First handle right along the bottom (x1 large, y1 = 0) → sits still, then rushes. That is ease-in. Avoid.
• Y outside 0–1 → overshoot. y2 > 1 passes the target and comes back: a pop.
• X outside 0–1 → invalid. The browser ignores the whole declaration.

Gate 4 — How long?

Stagger

30–80ms between items. Longer and the list feels like it is loading. Never block interaction while a stagger plays.

Asymmetry

Exit faster than enter. Entering, the user is being shown something; leaving, they have already decided and want it gone. A 300ms enter pairs with a 150–200ms exit.

Translating GSAP to CSS

Production sites — including the Claude for Chrome page — often use GSAP. Its ease names map onto standard curves, so you can read a site's source and reproduce it in CSS. GSAP's power scale is power1=Quad, power2=Cubic, power3=Quart, power4=Quint (GSAP docs); strength rises left to right: Sine < Quad < Cubic < Quart < Quint < Expo.

These are bezier approximations of polynomial curves — close enough that the difference is not perceptible, not mathematically identical. Values follow the Penner set catalogued at easings.net. Note that power4.out and --ease-out-strong are the same curve.

Measured in the wild

Values extracted from claude.com/claude-for-chrome on 2026-07-29 — a Webflow + GSAP build. Note that it obeys every rule above:

The quality rubric

Seven checks from “Great animations”. Run any animation past these:

Fix list

Six things belong in memory. Everything below that line is lookup.

The six

Durations that work

The first row overrules the rest when it applies. Everything below it assumes the system moved first; a press answers a hand that already moved, and 0.1s is the limit for it still feeling like direct manipulation. The two press rows are different animations — the button yielding under the finger, and the checkbox filling in afterwards.

Ceiling: if a single element's animation exceeds ~500ms, it needs a reason. Above ~1s the reader thinks the page is broken, not elegant.

The two stagger equations

Keep total under ~800ms for a hero, ~500ms for a menu or list. More items means a smaller step, not a longer wait — budget the total first, then divide.

Curves worth keeping

Lookup — don't memorise any of this

Scroll reveal, the whole pattern

<script>document.documentElement.classList.add('js');</script>

.js .reveal { opacity: 0; transform: translateY(20px); }
.reveal { transition: opacity 420ms var(--ease-out), transform 420ms var(--ease-out); }
.reveal.is-in { opacity: 1; transform: none; }

const io = new IntersectionObserver((entries) => {
  let batch = 0;
  for (const e of entries) {
    if (!e.isIntersecting) continue;
    e.target.style.transitionDelay = `${batch * 60}ms`;
    e.target.classList.add('is-in');
    batch += 1;
    io.unobserve(e.target);        // reveal once
  }
}, { rootMargin: '0px 0px -15% 0px', threshold: 0 });

The sign rule: negative bottom margin shrinks the root box upward and fires later. Positive grows it past the viewport and fires earlier. -15% is the working default.

Observe the container, not the items, when the group should read as one gesture — otherwise scroll speed decides your stagger for you.

Asymmetric enter/exit in pure CSS

.panel {                        /* resting state = the EXIT transition */
  display: none; opacity: 0; transform: translateY(10px);
  transition: opacity 160ms cubic-bezier(0.4,0,1,1),
              transform 160ms cubic-bezier(0.4,0,1,1),
              display 160ms allow-discrete;
}
.panel.open {                   /* active state = the ENTER transition */
  display: block; opacity: 1; transform: none;
  transition: opacity 340ms cubic-bezier(0.23,1,0.32,1),
              transform 340ms cubic-bezier(0.23,1,0.32,1),
              display 340ms allow-discrete;
}
@starting-style { .panel.open { opacity: 0; transform: translateY(10px); } }

A transition on a rule governs the journey to that rule. That is how you get two durations and two curves without any JavaScript.

The --i stagger

.item { transition-delay: calc(var(--i) * 60ms); }
<div class="item" style="--i: 0">…</div>

With animation-delay instead, you must add animation-fill-mode: backwards or the element flashes its final state first. transition-delay has no such problem.

Scroll-driven CSS (a scrub, not a trigger)

@supports (animation-timeline: view()) {
  .bar {
    animation: grow linear both;
    animation-timeline: view();
    animation-range: entry 10% cover 30%;
  }
}

Ranges: entry = crossing into view, cover = any part visible, exit = leaving. No duration — the range replaced it.

Property cost tiers

Animating to height: auto: wrap in a grid and animate grid-template-rows: 0fr → 1fr.

Hover and press, the whole shape

.btn {
  transition: transform 180ms var(--ease-out),   /* coming back up */
              background-color 140ms ease;
}

@media (hover: hover) {                          /* gate the hover — only the hover */
  .btn:hover { background: var(--accent-700); }
}

.btn:active {                                    /* outside the query: fingers press */
  transform: scale(0.96);
  transition: transform 80ms var(--ease-out);    /* going down */
}

.btn:focus-visible { outline: 2px solid var(--ink); outline-offset: 2px; }

Press depth from element width: edge displacement = (1 − scale) × width ÷ 2. Aim for 2–4px. 96px button → 0.96. 320px card → 0.985. Full-width → don't scale, darken.

Hover intent, no JavaScript: transition-delay: 300ms on the :hover rule, 0ms on the base rule. Waits on the way in, leaves immediately.

Debugging, in order

1. Paint flashing (DevTools → Rendering). Green = repainted. A composited animation produces no green at all. Green during motion means it isn't composited.
2. Layers panel. Flashing green and no layer of its own = confirmed non-composited animation.
3. Performance recording. Purple is Layout, green is Paint. Long frames are the ones over 16.7ms.
4. Click your toggle as fast as you can. If it queues, stutters or sticks, the motion isn't interruptible.

Twenty lessons across two tracks. Read a block; if none of it surprises you, you have that lesson. If a bullet lands as new information, go back to the lesson — the bullet is the conclusion, not the argument.

0001 · Ease-out, or nothing

Skill: choose a duration and a curve, and defend both.

• Animation's job is to preserve cause and effect. The test for any effect: does this reduce the work of understanding what just happened, or add to it?
• The gate — animate only to answer where did that come from, where did it go, did my click register, is this the same thing I was looking at.
• Ease-out for entrances. Fast start, decelerating into place. cubic-bezier(0.23, 1, 0.32, 1) is the workhorse.
• Linear reads mechanical; ease-in on an entrance reads sluggish. Both are recognisable on sight once you've seen them side by side.
• Duration is a property of the thing, not of taste: 120–160ms hover, 180–250ms popover, 280–360ms modal.
• A polished page isn't using a secret library. It's applying a few rules consistently.

0002 · The four-property budget

Skill: pick the property that gets the effect without buying the pipeline.

• 16.7ms per frame, total. The pipeline is style → layout → paint → composite, and a property costs you every stage from where it enters downward.
• transform and opacity enter at composite — effectively free, and run on a different thread, so they survive a fully blocked main thread.
• color, background, box-shadow, filter → paint. width, height, top, margin, padding → layout, recomputed every frame.
• Cost is cost × frequency × count. One accordion opening once is a rounding error. The same animation on 200 cards is what kills the page.
• The one everybody hits is height: auto. Use grid-template-rows: 0fr → 1fr, or scale a wrapper.
• will-change is a hint with a memory cost. Add it before, remove it after — never leave it in a stylesheet permanently.

0003 · Stagger and orchestration

Skill: orchestrate a group entrance and defend its total length.

• Two numbers only: the per-item duration, and the step between items.
• total = duration + (n − 1) × step. Compute it before shipping.
• overlap = step ÷ duration. Keep it ≤ 0.35 or the group reads as a queue instead of one gesture.
• Overlap and total fail independently — a well-overlapped group can still take four seconds.
• Motion captures attention before content does, so arrival order becomes reading order. Stagger is therefore a claim about priority; make it deliberately.
• Per-item stagger breaks past roughly ten items. Stagger by batch or by row instead.
• The pattern: --i on each element, transition-delay: calc(var(--i) * 60ms).

0004 · The scroll reveal

Skill: choose trigger or scrub, and place the fire point.

• Two unrelated techniques share one name. A trigger fires when an element crosses a line and then plays at its own speed. A scrub makes progress a function of scroll position.
• If the element carries meaning, trigger it. Scrub only what is legible at any arbitrary percentage — backgrounds, progress bars, a drifting image.
• Fire point: about 10–20% before the element's top reaches the viewport bottom. rootMargin: '0px 0px -15% 0px'.
• The cardinal sin: content that only JavaScript can unhide. Ship the visible state and let the script opt into hiding it.
• Stagger by batch, not by global index, or item 40 waits two and a half seconds for nothing.
• CSS-only version: animation-timeline: view() — which is a scrub, so it inherits every scrub caveat above.

0005 · Exits

Skill: make a thing leave faster than it arrived, and survive its own removal.

• An entrance spends time building understanding. An exit confirms a decision the reader already made, which needs far less of it.
• Ratio 0.5–0.65. 320ms in, 180ms out.
• The curve flips: ease-in out. An ease-out exit lingers at near-zero opacity, which is the worst possible place to spend time.
• Direction: back toward where it came from, or straight away. Never mirrored for symmetry's own sake.
• The engineering problem — the element must stay in the DOM until the exit finishes. transitionend, or your framework's presence API.
• display and content-visibility are discrete properties: transition-behavior: allow-discrete, plus @starting-style for the entrance.
• Interruption: reverse from the current computed value, never restart from the end state.

0006 · Choosing a tool

Skill: pick the cheapest tool that can do the job, and say why.

• A CSS transition is a rule about two states. A CSS keyframe animation is a recording you can start and stop. WAAPI is the same recording with a playhead you can hold.
• Pick by what you need to hold onto — that's the whole decision.
• Transitions interrupt from the current value for free. Keyframes own the property outright and snap when removed. Only WAAPI gives you pause(), reverse(), currentTime and .finished.
• The five questions, in order, stopping at the first yes: two states? → transition. Loops, 3+ steps, or runs unprompted? → keyframes. Pause, seek, reverse, await? → el.animate(). React, and unmounting or layout-driven? → Motion. Structured sequence or scroll pinning? → GSAP.
• Libraries save you plumbing, not judgment. Every duration, curve and property decision from lessons 0001–0005 is unchanged by the tool.

0007 · Transform-origin

Skill: anchor a scaling element to the thing it came from.

• transform-origin is the fixed point — the one place in the element that doesn't move.
• Put it at the point the element came from. For an anchored element, mirror the pinned edge: a panel below and right of its trigger gets top left.
• Get it wrong and the element drifts by hypot((1−s)·W/2, (1−s)·H/2) — which is why a wrong origin looks like the popover "landed nearby" rather than opened.
• Never scale from 0. Start at 0.92–0.96, or the text is illegible and it reads as a zoom rather than an appearance.
• The origin belongs on the element being transformed, not on its parent.
• It governs rotation too: centre = dial, left = door, bottom = pendulum, top = hanging tag.
• SVG needs transform-box: fill-box before percentages mean anything.
• Leave it at centre deliberately for centred modals and toasts — things that genuinely came from nowhere.

0008 · Springs

Skill: choose between a duration and a physics model, and tune a spring without guessing.

• A tween is a function of time. A spring is a function of state — position and velocity.
• Only a spring carries velocity across a mid-flight change of target. A tween produces a corner, because the new curve's opening slope comes from the curve, not from what the element was doing.
• Three numbers: stiffness (how hard it pulls), damping (friction), mass (inertia).
• ζ = damping ÷ (2 √(stiffness × mass)). Below 1 it bounces; at 1 it's the fastest arrival with no overshoot; above 1 it's slow for no benefit.
• Tuning method: set ζ for bounce, then stiffness for speed.
• Motion's bounce is 1 − ζ, clamped to [0.05, 1] — so it can't express overdamped, and it's linear in ζ rather than in what you see. bounce: 0.25 is a 2.8% overshoot, not 25%.
• Duration is an output. Consequence: the bounciest preset is also the slowest.
• CSS linear() is a baked spring. Overshoot survives; velocity continuity does not.
• Don't spring a stagger (no duration to budget with), an exit, or opacity (it clamps at 1, so you get the tail without the bounce).

0009 · Reduced motion, done properly

Skill: decide, per element, what a reduced-motion user should see instead.

• reduce is a request about distance, not time. Cutting a duration to 0.01ms moves the same 24px; it just deletes the part you could follow.
• Take the travel away and keep the fade. A 300ms cross-fade in place is a perfectly good reduced-motion animation.
• Three buckets. Ambient (parallax, drifting gradients, marquees) → remove. Informational (entrances, exits, toasts, reveals) → cross-fade in place at full duration. Status (spinners, progress, typing indicators) → leave alone; WCAG 2.3.3's essential-motion exception covers it.
• Risk order: large area > parallax > zoom and spin > oscillation > distance > speed. opacity is the safe substitute for all of them — no direction, no displacement, no depth cue.
• The famous global 0.01ms reset is a floor, not a policy: it freezes every spinner on the page via animation-iteration-count: 1. Keep it for third-party CSS; write real rules for your own.
• Structurally, one media query is enough — set a shared --travel to 0px and every component that reads it is covered, including the ones written after you leave.
• JavaScript gets none of this for free. matchMedia('(prefers-reduced-motion: reduce)'), and listen for change — people toggle it mid-session, often because of your page.
• Never ship a reduced path you haven't looked at. DevTools → Rendering → emulate prefers-reduced-motion.

0010 · Hover and press

Skill: time a state change to the hand that caused it, and gate it on the input device.

• Ask who moved first. Motion that answers the user is near-instant; motion the system starts on its own gets a duration. This sits above every number in Reference 02.
• 0.1 second is the limit for feeling you are directly manipulating the thing (Nielsen). Press-down 0–100ms; zero is a legitimate answer.
• Down fast, up slow — 80ms in, ~180ms out. Re-declare the transition inside :active, don't just override the transform. A soft release reads as physical without a spring.
• At 80ms every easing curve looks the same. The one place in the course where the curve doesn't matter.
• Press depth is a displacement, not a ratio: (1 − scale) × width ÷ 2. Keep it in the 2–4px band, so 0.96 on a 96px button and ~0.985 on a 320px card. Full-width things darken instead.
• There is no hover on touch — no pointerleave is ever generated, so a bare :hover latches at the tap and stays until you touch something else.
• Gate hover decoration in @media (hover: hover). Not and (pointer: fine). Never put :active or :focus-visible inside it.
• Nothing that is information or a control may live behind hover. It doesn't exist on a phone and it never appeared for a keyboard.
• Hover intent is an asymmetric transition-delay: ~300ms arriving, 0ms leaving. JavaScript only for the safe-triangle submenu case.
• Keep the press scale under reduce — it's at the safe end of every axis in 0009's risk table. Cut hover travel instead: --lift: 0px.

0011 · Layout animation

Skill: animate a layout change you didn't write, and know when to hand it to the browser.

• FLIP — First, Last, Invert, Play. Measure, change the DOM, measure again, apply a transform that maps Last back onto First, then take it off with a transition.
• Layout runs once, at Last. Everything after is a composite-tier transform — which is how a layout change gets animated inside 0002's budget.
• The DOM is in its final state from Last onward. Only the pixels lie.
• void el.offsetWidth; between Invert and Play is load-bearing. Without it the two writes coalesce, the inverted position never exists as a frame, and nothing animates — silently. The double-requestAnimationFrame is the same fix, one frame later.
• Any layout read works: offsetWidth, offsetHeight, getBoundingClientRect(), getComputedStyle(el).transform.
• FLIP is interruptible for free, because getBoundingClientRect() reports the painted box — transforms included — so First re-measures mid-flight.
• It animates whatever caused the layout change; the code never knows which. Its two weak spots are resizing (a scaled box stretches its children and its border-radius) and elements that enter or leave (no First rect to come from).
• document.startViewTransition(cb) is the browser doing all of it on two screenshots. Unnamed elements cross-fade; a shared view-transition-name across the two states makes the browser morph one into the other.
• The name must be on the source element before the callback runs, and must be unique in the document at capture time. A duplicate is an InvalidStateError and the whole transition is abandoned — so names carry identity: card-42, never card.
• It always captures the entire document. For the duration the page is a pair of screenshots: no scroll, no input, no interruption — only transition.skipTransition().
• Style it with ::view-transition-group(), -old() and -new(); every timing rule from 0001 and 0002 applies to them unchanged.
• Support: same-document is Chrome 111, Safari 18, Firefox 144 — Baseline as of October 2025. Cross-document (@view-transition) is Chrome 126 and Safari 18.2, and not in Firefox.
• The gate: if the user can interrupt it, FLIP it; if it's over before they could, hand it to the browser.

0012 · Things that just appeared

Skill: animate an element that has no previous state, and pick the mechanism from whether it can be interrupted.

• A transition needs two computed values. A just-appended element's first computed style is its final style, so no transition is ever created — and nothing is logged, because not starting is not an error.
• Three places to keep the missing first value: @starting-style, the from block of a @keyframes, and a start class removed after a forced reflow (void el.offsetWidth).
• @starting-style is a declarative void el.offsetWidth. Same fix as 0011's flush, spelled in CSS. It is consulted only on the element's first style update, which is also why it can do nothing for exits.
• The gate — can she change her mind mid-entrance? A transition recomputes its start from the current on-screen value, so an interrupted entrance turns around. A keyframe animation starts a fresh timeline at its own from, so an interrupted entrance snaps to fully-arrived and leaves from there.
• WAAPI is the exception, not a contradiction: el.animate() hands back an Animation with reverse() and playbackRate — interruptible, as long as you kept hold of the object. That is 0006's ladder.
• Where the zero lives decides what happens when the animation doesn't. @starting-style and from fail safe: an element that never animates is a visible element. opacity: 0 in a base rule makes the content conditional on JS running, which is 0004's cardinal sin and needs 0004's .js guard.
• Use the runtime reflow when the “before” is a number you had to measure — a height, a rect, anything CSS can't name. Otherwise prefer the declarative one.
• display needs transition-behavior: allow-discrete. A top-layer element (popover, <dialog>) needs overlay on the same list too, or it drops out of the top layer instantly and the exit runs where nobody can see it. You may delay overlay; you may not set it.
• getAnimations() is the instrument. 0 means nothing started — a missing first value. Non-zero means something started and it's the wrong thing.
• @starting-style and allow-discrete are Chrome 117, Safari 17.4–17.5, Firefox 129. Transitioning overlay is Chromium-only, and degrades to a hard cut — the un-animated baseline, so no @supports gate is needed.

0013 · Reveals with clip-path

Skill: reveal something without moving it, and know before you write it whether the shape is worth a paint.

• Two effects share the name. The window moves — the element is fully painted and at rest the whole time, and only what you may see of it changes. The content moves — the fade-and-rise, dimmer and lower than its final state for the whole flight. A mask reads as uncovering; a fade reads as arriving. A reveal called “too soft” is usually a fade where a mask was wanted, and no curve fixes it.
• clip-path keeps what is inside the shape and does not draw the rest. The layout box is unchanged, so nothing reflows, and hit-testing follows the visible shape.
• inset() takes distances inward from top, right, bottom, left — margin order. round 14px puts a radius on the window itself. Polygon percentages may sit outside 0–100%, which is how a diagonal edge overhangs its box.
• A shape only interpolates against its own kind — inset to inset, circle to circle, polygon to polygon with the same vertex count. Mismatch is a discrete animation: hold, swap at 50%, hold. Nothing is logged, and getAnimations() shows a healthy animation, which is what tells you the values are wrong rather than the mechanism.
• 0002's on credit tier: it skips layout, so never the catastrophic kind of jank, but it re-paints and the bill scales with the area painted rather than with how complicated the shape is.
• The decision is capability, not cost. Could a rectangle have done this? Stop at the first yes: (1) is the leading edge anything but horizontal or vertical; (2) does the window need more than one moving edge; (3) must the content stay perfectly still and the radius stay put; (4) is the element one you can't wrap.
• The three builds of one wipe: clip-path on the element; a clipping wrapper that travels with the content counter-transformed back (what a split-text line mask is); a static clipping wrapper with the content sliding behind it (the default, and correctly so).
• Reduced motion: a wipe is a large area changing luminance on a schedule, not a translate. Replace it with an 80–120ms opacity fade or with nothing. Shortening the sweep to 150ms only makes it faster to look at.

The design track

The engineering track is organised by mechanism. This one is organised by recognisable patterns and the words needed to review them. Its three families are product UI, expressive pages, and direct manipulation.

D001 · The map, and the words for it

Skill: name any effect, say its family, and say what it promises.

• Nouns name the pattern, verbs name what the motion does, and adjectives diagnose how it feels.
• Product UI values consistency and speed; expressive pages value pacing and restraint; direct manipulation values 1:1 tracking and what happens on release.
• A convention is load-bearing when breaking it changes the promise, even if the resting frame still looks correct.
• The review sentence: this is a [noun]; it [verb]s so the reader understands [promise].

D002 · Where things live when they're off screen

Skill: answer “fade or slide?” without discussing fading or sliding.

• Choose the absent element's home; the entrance and exit motion are consequences of that spatial claim.
• An anchored thing returns to its trigger or edge. A centred modal can come from nowhere. A toast belongs just beyond the edge it enters from.
• Fade is not a neutral fallback. It says the thing stopped existing in place.
• Exit direction confirms the same spatial model the entrance established.

D003 · Motion is hierarchy

Skill: say what an animation ranks, not whether you like it.

• Motion is a hierarchy channel beside size, weight, colour and space — and it wins against all of them while it is active.
• Animating an element promotes it, whether or not promotion was intended.
• Animate everything and the channel saturates; source order becomes the leftover ranking.
• Motion cannot repair hierarchy. When it ends, the layout hands the old ranking back.

D004 · The button

Skill: review a control by what it promises, state by state.

• A button has seven designed states: rest, hover, focus, press, pending, success/error, and disabled. A mock usually shows one.
• Missing feedback does not break the action; it breaks the promise that the action heard you.
• Disabled is an error message with the text removed. Prefer a live control that spends the press explaining and focusing what is missing.
• Hold-to-confirm is a state the reader occupies. Show progress, and make release snap back faster than the hold that earned it.

D005 · Things you drag

Skill: review a drag by its pickup and release, not its middle.

• Nothing under the finger gets a transition. While held, only the hand may claim where the object is.
• The five moments are lift, ghost, gap, settle, snap-back.
• Ghost preserves the origin; gap promises the landing. They are different pieces of evidence.
• The keyboard path is part of the interaction, not an accessibility footnote.

D006 · Decks, and what the dots promise

Skill: review a deck by what its indicator promises and whether it can keep it.

• An indicator must answer where am I and how much is left. Dots do both at small counts, counters stay exact, bars preserve proportion.
• Choose for the largest count the deck will ever hold, not the count in the mock.
• A peek is the content-level affordance that says the row continues.
• Indicators imply pages, and pages imply snapping. Free-scroll belongs to continuous strips.
• Autoplay earns its place only when content fits the interval, pauses on hover/focus, stops permanently on interaction, and respects reduced motion.

D007 · Scroll as a timeline

Skill: review a scroll system by who owns each frame, how much distance a beat costs, and whether the page keeps the native scroll contract.

• Trigger when the middle frame is merely unfinished; scrub when every intermediate frame explains something valid.
• Distance is duration. Price each beat in viewport-heights, then ask whether the idea is worth the travel it charges.
• Pin the visual that must remain constant for several changes to be compared. If nothing must remain constant, restore normal flow.
• Parallax is a claim of depth. Different rates are justified only by a real foreground and background relationship.
• A horizontal section maps vertical travel onto a sideways stage; keep vertical progress, resting states, and the exit legible.
• Scroll-jacking rewrites distance, direction, or response. Catch-up can be perfectly fluid and still feel laggy because the viewport trails the position the hand requested.
• Reduced motion flattens depth and restores content to normal flow; it never strands the story in a frozen first frame.

D008 · Text that arrives

Skill: choose split granularity, reveal style, and stagger from the reading unit.

• Split is hierarchy made in time: lines preserve body-copy reading; words suit short headlines; characters suit one hero word.
• Mask reads as uncovering; fade-up reads as arriving. Compare them simultaneously before choosing.
• More units multiply the waiting. A tiny per-unit delay can still make a paragraph feel like a queue.
• Responsive line splitting must re-measure, preserve word wrapping, and keep the original sentence accessible.

What this sheet deliberately leaves out: every argument. Reference 01 holds the judgment calls for easing and timing, Reference 02 holds the numbers and the syntax, and this one holds the shape of the course. If a bullet here reads as an assertion you'd rather not take on faith — good, that's the lesson it came from doing its job.

The other three sheets answer questions: what should I do here, what's the number, which lesson was that in. This one doesn't answer anything. It's the instruments, laid out on a bench, for when you already know what you want to test and don't want to re-read an argument to get at the knob.

Index

01 · Same duration, different curve

Lesson 0001 — Ease-out, or nothing · four curves fired together, one duration

Reach for it when you're about to argue that a curve is wrong. Drop the duration to 100ms first: below roughly 120ms all four curves are indistinguishable, and the argument you're having is really about duration.

02 · Same animation, different property

Lesson 0002 — The four-property budget · the same movement bought two ways, side by side

Reach for it when someone tells you a property is "basically free." Raise the count until the two columns visibly separate, then read the frame time rather than trusting your eyes — the point at which they split is the number worth quoting.

03 · Find the band

Lesson 0003 — Stagger and orchestration · count, step, travel and order, with the total shown

Reach for it when you have a real n and a real budget. Set the count to what you actually ship, then find the step that keeps the overlap ratio comfortable and the total under about 600ms. Push the step up until it stops reading as one gesture — that edge is the thing worth knowing.

04 · Scroll the panel

Lesson 0004 — The scroll reveal · the same reveal, driven by an event and by scroll position

Reach for it when you're deciding whether a reveal should fire or track. Use "Stop halfway" on the scrub column: if the content is unreadable in that frozen state, it can't be a scrub, and no amount of tuning fixes it.

05 · Open them, then close them

Lesson 0005 — Exits · two identical panels, entering and leaving

Reach for it when an exit feels wrong and you can't name why. Nine times out of ten it's an ease-out exit, which spends most of its time crawling near zero opacity — the element is gone as far as you're concerned, and the page is still waiting for it.

06 · Ask all three to do the same thing

Lesson 0006 — Choosing a tool · one effect as a transition, as keyframes, and through WAAPI

Reach for it when a tool choice is live. Read the capability table against your requirement rather than the general one — most of the time you never pause or seek, and the cheapest thing that can do the job wins by default.

07 · Open it from each corner

Lesson 0007 — Transform-origin · one popover, four trigger positions, origin on and off

Reach for it when a menu or popover feels detached from the thing that opened it. Cycle the corners with the origin left at centre, then set it correctly and cycle again. The difference is not subtle once you've seen it, which is the whole reason to look.

08 · Same move, two models of time

Lesson 0008 — Springs · a tween and a spring covering identical distance

Reach for it when you're choosing between a duration and a physics model, or tuning bounce and visualDuration without guessing. Interrupt the move mid-flight — that's the case the spring exists for, and the one a duration can't answer.

09 · One interface, three policies

Lesson 0009 — Reduced motion · the global reset, nothing, and the per-element answer

Reach for it when you need to show someone why the copy-pasted global reset isn't the answer. Switch to it and watch the spinner. You don't have to say anything.

10 · One button, two kinds of hand

Lesson 0010 — Hover and press · mouse and finger against the same button, gated and ungated

Reach for it when you're setting press depth on something that isn't a button — a card, a row, a full-width bar — and want to see the displacement rather than compute it. Also the fastest way to reproduce sticky hover for someone who doesn't believe it happens.

10 · Two buttons, two clocks

Lesson 0010 — Hover and press · two real buttons one number apart, with the sides shuffled

Reach for it when someone wants to argue a press duration, or when you want to check a number against your own hand rather than against a table. Press both, commit to one, then reveal — the shuffle is the point, because a timing you were told about is a timing you agree with for free.

11 · Watch it move, or watch it teleport

Lesson 0011 — Layout animation · the same reorder unaided and through FLIP, with the four steps shown

Reach for it when a FLIP you wrote isn't animating and you're staring at code that looks correct. Set the flush to skipped here first, so you know exactly what that failure looks like — it is indistinguishable from having no FLIP at all, which is why it costs people an afternoon.

11 · One tile, opened three ways

Lesson 0011 — Layout animation · a hard cut, a cross-fade, and a named morph, from one code path

Reach for it when you're deciding how much of a view transition to specify, or when a morph is coming out as a cross-fade and you want to confirm it's a naming problem. Fair warning: this one really does freeze the whole workbench for its duration, which is the point.

12 · Append a row, four ways

Lesson 0012 — Things that just appeared · the same appended row with no first value, with @starting-style, with keyframes, and with a forced reflow

Reach for it when something you just inserted refuses to animate and the console is empty. Start on nothing to see what that failure looks like, then read the count underneath — getAnimations() is the instrument, and 0 means the transition was never created rather than created wrong.

12 · Open it, then change your mind

Lesson 0012 — Things that just appeared · a keyframe entrance and a transition entrance, closed mid-flight by the same press

Reach for it when you are choosing between @keyframes and @starting-style for an entrance, or when a panel snaps to fully-open before it closes and you want to confirm why. Short delays are where the two come apart.

13 · Reveal it, two ways

Lesson 0013 — Reveals with clip-path · the same hero revealed by moving the window and by moving the content, both from one press

Reach for it when a reveal is being described as too soft, too tentative, or not “editorial” enough — usually that is a fade where a mask was wanted. The badges are measured off the headline itself, so they hold at any duration, and the three shapes where the right pane goes to opacity only are the ones a rectangle cannot make at all.

13 · One picture, three builds

Lesson 0013 — Reveals with clip-path · clip-path against a moving window and a static one, under five things a reveal might be asked to do

Reach for it before writing a reveal, to answer the only question that decides the build: could a rectangle have done this? Run the five demands to find out what each build can express, then run the cost strip at 48, 120 and 300 copies to find where the shape stops being free on the machine in front of you.

D01 · Twelve patterns, twelve conventions

Lesson D001 — The map, and the words for it · each pattern beside a switch that breaks the convention it depends on

Reach for it in a review, when you need the word for something on screen: play the pattern you think it is and see whether it matches. The verb chips under each name are the shortlist, and the broken version is there for when the argument is about whether a convention is load- bearing — it is faster to break it than to describe it.

D02 · Pick a home, get a motion

Lesson D002 — Where things live when they're off screen · the transform is derived from the home, never chosen

Reach for it when someone asks whether a thing should fade or slide. Put the real element on the bench, try the two homes being argued about, and read the line under the frame — the argument is usually settled before anyone has said the word easing. The CSS panel is the receipt to paste into the ticket.

D02 · Same entrance, three ways out

Lesson D002 — Where things live when they're off screen · returns home, fades in place, leaves out the far side

Reach for it when an exit is being defended as “just a fade”. The three run at once on purpose: played one after another they all look fine, and the difference only exists side by side.

D03 · Which channel wins

Lesson D003 — Motion is hierarchy · motion against size, weight and colour, one channel per tile

Reach for it when someone calls an animation decorative. Hand the motion to the plain tile and press play: nine pixels beat every static channel on the board, which is the whole reason an animation is never only decorative.

D03 · What does this promote

Lesson D003 — Motion is hierarchy · same timing, same class, eight places to put it

Reach for it in a review, with the real component in mind. Find the option that matches what is being proposed, read the line underneath, and check it against what the card is actually for. The CSS panel is there to show that nothing but the target ever changed.

D04 · A button is seven promises

Lesson D004 — The button · a working save action whose feedback can disappear state by state

Reach for it when a button looks complete in a mock but feels unfinished in a hand. Remove hover, focus, press, pending or success one at a time: the action continues to work, and the verdict names the promise that silently went missing.

D04 · Hold to confirm

Lesson D004 — The button · a state the reader is inside and can leave

Reach for it when a destructive action needs deliberate commitment. Turn the progress feedback off to make a still-functional interaction unusable, then compare snap-back against the plausible-looking mistake of keeping partial progress after release.

D05 · Which one still belongs to your hand?

Lesson D005 — Things you drag · direct tracking and a 120ms transition, simultaneously reachable

Reach for it whenever someone proposes making a drag feel smoother with a transition. The pointer ring shows the requested position, the sides shuffle, and one chip visibly trails its own hand.

D05 · The five moments of a drag

Lesson D005 — Things you drag · pickup, evidence, landing and rejection around a real reorder

Reach for it when the middle of a drag works but the interaction still feels weightless or uncertain. Switch off lift, ghost, gap, settle and snap-back independently; the reorder stays functional while the missing promise becomes visible.

D06 · One deck, four decisions

Lesson D006 — Decks, and what the dots promise · indicator, discoverability and release against a changing item count

Reach for it when a carousel is being reviewed at the count in the mock. Raise the count to forty and make the dots keep their promise; hide the peek to test whether the deck is still discoverable; let a page-shaped card drift to expose the release mismatch.

D06 · Read the slide

Lesson D006 — Decks, and what the dots promise · autoplay against actual reading

Reach for it when autoplay is being argued as a style preference. Read the sentence at three seconds, then let the deck ignore hover or resume after an explicit interaction. The counter makes each otherwise-silent interruption audible.

D07 · One story, four decisions

Lesson D007 — Scroll as a timeline · content, driver, distance, pin and depth in one scrollport

Reach for it before choosing a scroll library. Stop an entrance and an explanation halfway: the first becomes a half-made headline, while the second remains a valid intermediate state. Then price each beat in screens and ask what the pin is actually holding constant.

D07 · One gesture, two contracts

Lesson D007 — Scroll as a timeline · direct scroll beside polished catch-up, with the answer hidden

Reach for it when “smooth scrolling” looks expensive in a recording but feels wrong under a hand. One gesture drives both panes, and the marker shows where the input already asked to be; reveal only after choosing the pane that still feels attached.

D08 · Split the text

Lesson D008 — Text that arrives · granularity, stagger and reveal style against a hero word and a paragraph

Reach for it before adding a split-text plugin. Change the unit and delay together, then read the measured total: the same character split that gives a hero word a pulse can turn body copy into a queue.

D08 · Same words, different promise

Lesson D008 — Text that arrives · mask uncovering beside fade-up arrival

Reach for it when a reveal feels like a preset instead of a decision. Press one button for both panes, stop halfway, and decide whether the type stayed still while a window opened or arrived dimmer and lower.

Scratch

No lesson · an empty playground, kept here so the bench has a bare patch on it

Every lab above is a fixed experiment: it holds one thing still so you can move another. This one holds nothing still. Paste in markup and CSS you're actually working on, or delete what's there and start from an empty rule.

This is the one sheet not worth printing — the labs are the content, and on paper they're empty boxes. It prints as the index and the notes, which is probably not what you wanted. Reference 01 and 02 are the ones that survive a printer.