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-10. 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.

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.

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.

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.

Lesson 0013 gave clip-path a careful warning: it skips layout, but it still buys paint. Today we look at the receipt. A performance recording is a timeline of frames and the browser work inside each one.

Start with this deliberately small recording. It uses the same question you will ask in DevTools: what changed, how much changed, and which pipeline stage paid for it.

Three moves through a recording

1. Scan the frame track. Long bars are the places to investigate. Do not average them into an FPS score; one 42ms frame is a visible hitch even if the next ten are short.

2. Follow the pipeline. In the selected frame, look for Style, Layout, Paint and Composite. If Layout appears on every tick, geometry is changing. If Paint dominates, the browser is redrawing pixels. If only Composite remains, the main-thread work is probably not your bottleneck.

3. Name the mechanism before the remedy. “Make it faster” is not a diagnosis. Replace a moving width with a transform when the design allows it; reduce painted area when a reveal is too expensive; remove work that the interaction does not need. Keep the visual promise intact.

Before you press Record

A recording is an experiment, so set up the experiment before interpreting its result. Use the same viewport and zoom you use when judging the design. Close a noisy tab, but do not chase a laboratory-perfect machine: the page still has to feel good on an ordinary one. Turn on the Performance panel's Screenshots lane so you can line the trace up with what was actually visible.

Then decide what gesture you are measuring. A scroll reveal needs the scroll itself, not just the page load. A press state needs the press and release. Start recording, wait a beat, perform the gesture at a normal speed, and stop immediately after the last visible change. The quiet seconds before and after are useful boundaries; they show you which work belongs to the interaction.

What the coloured rows mean

The top overview is a map, not the territory. The frames row tells you when the browser missed its deadline. The main-thread flame chart tells you what occupied that frame. A wide purple block is Layout; a green block is Paint; scripting is usually yellow. The colours are useful shorthand, but the width is the evidence: a five-millisecond Paint event is not a problem merely because it is green.

Look for relationships between rows. A click or scroll marker is your cause. A run of long frames immediately after it is the effect. If a long yellow task sits before the rendering work, JavaScript may be starving the frame. If the yellow work is short but Paint is wide, changing the script will not cure the bill. Select the largest child event, then move one level up and ask which interaction owns it.

Do not mistake a single requestAnimationFrame callback for the animation itself. It is a scheduling hook. The expensive part is the style, layout or paint work it causes afterward. Likewise, a green “composite layers” row is not proof that the whole page is cheap — image decoding, scripting and layer creation can happen elsewhere in the same frame.

Prove the fix

Change one mechanism at a time and record the same gesture again. Keep the viewport, scroll distance and speed as close as you can. Compare the worst frame and the shape of the run, not just the average. A successful transform substitution should remove Layout from the selected frames; it does not need to produce a magical “60 FPS” badge.

1. Save the first recording or a screenshot of the selected frame.
2. State the smallest change that could remove the dominant stage.
3. Make that change, reload, and repeat the gesture three times.
4. Check that the visual promise still holds — the reveal must still uncover, the drag must still track the hand, the press must still acknowledge the click.

If the number improves but the design feels worse, the optimisation failed. Performance is a constraint on the promise, not permission to quietly change the promise.

Go and look at a real page

Open the Image Reveal CSS demo. It is a good specimen because the visual idea is clear: an image is uncovered as you scroll, using a view timeline and clip-path.

1. Open DevTools → Performance. Start a recording, scroll slowly through two or three reveals, then stop.
2. Find one long frame in the overview. Select it and expand the main-thread events until you can name the largest stage.
3. Record the observation in one sentence: “The reveal spends most of this frame in ___ because ___.” Repeat once with a cold reload and once with the cache warm.

This is not a benchmark. Your machine, browser, viewport and image cache all change the numbers. The transferable skill is reading the causal shape of the trace.

When the recording disagrees with the design

A short recording can lie by omission. Repeat the interaction, include the slowest part of the gesture, and check that the element is actually visible. A reduced-motion preference may remove the animation while leaving the layout and paint work you are trying to understand. The useful question is always: what work happened in the frame I can feel?

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.

Go and look Apple — AirPods Pro. Scroll it slowly and stop wherever you like. Almost every frame you land on is a finished picture — the product held at some angle, mid-assembly, one layer lifted. Then flick past a section fast and creep back up through it. Ask the question this section asks: is the middle of that move telling you something, or is it a transition you were meant to miss?

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.

Go and look Stripe, with the same ruler. Count screen-heights per idea on the way down. Almost nothing costs more than one, most cost far less, and the page never asks you to hold still while it finishes a thought. That is a pacing decision, not a shortage of ambition — and it is the number to have in your head before someone proposes a three-screen section.

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.

Go and look Firewatch. The hero is a stack of flat illustrated layers moving at different rates, and it is the clearest depth claim on the open web. Scroll a little and name the planes out loud, nearest to farthest. Then notice how little each one actually travels. The page is a decade old and still legible, which is the argument that deep is an adjective and not a trend.

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.

Go and look Two ends of this, one page each. Bramus’ image-reveal demo is a scroll timeline the browser owns outright — no library at all, just view-timeline and a clip-path. Grab the scrollbar and drag it in jerks: the reveal tracks your hand exactly, because nothing is chasing anything. Dennis Snellenberg’s portfolio is the other end. It is a beautiful site, and it replaces the browser’s scroll with its own — the page loads Locomotive Scroll and GSAP’s ScrollTrigger, and you can feel it. Press End. Drag the scrollbar. Flick hard on a trackpad and let go. Then say which of the two contracts each page is honouring, in those words. All five links checked 2026-09-05. Sites get redesigned; if one has, the exercise is still to name what replaced 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.

Go and look Apple — MacBook Pro. Scroll until a big headline arrives and name its unit: whole block, line, word, or character. Then find any paragraph of ordinary body copy on the same page and name that one. They are not the same answer, and the page is a long argument for why. Do it on two more product pages and the rule stops being something you were told.

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.

The split decides how many things there are. The order decides which of them the reader meets first, and that is a second, separate ranking — the lab's Order knob changes nothing but the schedule. Reading order is the default and usually the honest one: it agrees with the direction the eye was already travelling. Reversing it says the end of the phrase is the point, which is occasionally true and mostly an accident of a preset. Centre-out says the thing is unfolding rather than being read, which is why it flatters a single hero word and fights a sentence. Whichever you pick, you have told the reader what to rank first, so pick it on purpose.

If you have read the engineering track: 0003's stagger lab gives you the arithmetic for the delays. No engineering-track lesson is required for the decision above.

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.

Both panes share every setting, so the only difference between them is the promise. That is the point of running them side by side: play them one after the other and your memory will quietly award the win to whichever you saw second.

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.

Go and look Codrops’ On-Scroll Typography Animations — fifteen numbered effects on one page, most of them louder than anything you would ship. That is what makes it useful. Scroll slowly and ask two questions of each: what is the unit, and was the type always there with something moving in front of it, or did the type change state? Effect 1 and effect 9 answer that second question differently; say which is which out loud before deciding whether you like either.

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.

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.”

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.

Go and look GSAP’s SplitText documentation — not to learn the library, which this course does not use, but because the page is the most honest published account of everything on this list going wrong. Find autoSplit and onSplit and read what they exist for; that is the re-splitting problem, named. Then run the demo at the top and try to select the split headline with your cursor and copy it. Whatever you get in your clipboard is what a screen reader was being offered before someone did the work. All three links checked 2026-09-05. Sites get redesigned; if one has, the exercise is still to name what replaced it.

Reduced motion is the sentence, present

Kinetic type is close to the top of the list of things a reduced-motion reader wants spared. A split turns one calm element into dozens of small moving parts, all of them inside the thing the reader is trying to read, and the reader cannot look away from it because it is the content. A vestibular trigger is bad; a vestibular trigger you have to stare at to get the information is worse.

The accommodation is not a faster version of the same reveal. There is no honest short version of a letter-by-letter formation — at 60ms it is not a gentler effect, it is a flicker. Remove the schedule entirely and let the sentence be present. Both labs on this page do exactly that, and each says so in a comment: the words were always the content, and the split was always decoration on top of them.

What you keep is the information. If the stagger was carrying an order — this heading, then its subhead, then the button — that order still exists in the layout and in the reading direction. It was never the animation's to give. The test is simple and you can apply it to any design: turn the motion off and see whether anything you were relying on has gone. If something has, it was load-bearing motion, and it needed a second home.

If you have read 0009: this is that lesson's stance applied to the case where the moving thing is the text. Nothing there is needed to run the test above.

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 var(--duration) var(--curve) both;
  animation-delay: var(--delay); /* JS spends the stagger per unit. */
}

@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

What you can now do

Look at any headline that moves and name its unit in one word: block, line, word, character. Say whether the reader is being shown an uncovering or an arrival, and point at the thing that tells you — still type behind a moving window, or type that is itself dim and low. Price the split: units times delay, plus one duration, is the wait you are asking for, and you can say that number out loud before anyone builds it. Name the ranking the order implies and check it is the ranking you meant. Then turn the motion off and confirm the sentence is still a sentence and the order is still legible without it. When someone offers you a preset, you now have four questions to ask it, and “character-by-character, because it looks expensive” is not an answer to any of them.

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.

D008 handed you the order in which meaning arrives: you chose what the reader reads first and how long they wait for the rest. Here the clock belongs to somebody else. The network decides how long, and all you own is the story the screen tells in the meantime. That sounds like the smaller job. It is the one people quit over.

Four panes below, one request, one clock. Change the latency and the ranking changes with it — which is the whole reason "use a skeleton, not a spinner" is not a rule.

Two facts decide the treatment

A wait has exactly two properties that matter to a designer: how long it is, and whether you know how long it is. Every choice on that stage follows from those, and neither of them is a taste question you can settle in a design review by preference.

Under roughly a quarter of a second, the correct treatment is nothing at all. You saw why: a spinner that lives for 150ms is not feedback, it is a flicker, and the eye files a flicker under something went wrong with the page rather than something is happening for me. This is the failure that gets shipped most often, because it is invisible in a design file — the mock shows the loading state as a still image, and a still image of a spinner always looks like it is doing its job.

The consequence is a rule worth saying out loud in a review: don't render the loader immediately. Start it after 300 to 500 milliseconds, and most waits never reach it — they resolve first and the reader simply sees the answer, which is what a fast interface feels like. The ones that do reach it were genuinely slow, and now the loader is telling the truth.

From about half a second to a couple of seconds, something has to acknowledge the press, and here the skeleton beats the spinner on a second job as well as the first. A spinner says working. A skeleton says working and here is the shape of what is coming, so when the content lands it fills a frame the reader has already read, instead of arriving as a jump.

Past about five seconds the indeterminate indicator stops working entirely, and it fails in a specific way rather than just getting boring. The spinner at second eight is identical to the spinner at second two — it has no way to distinguish still working from hung, so a reader with a slow connection has no evidence either way and does the rational thing, which is reload and start the whole wait again. A determinate bar is the only thing on that stage still making a claim you can check against the clock.

Which is also the catch. A determinate indicator is a promise about a proportion, and a promise can be broken in public. A bar that races to 90% and sits there is worse than no bar at all, because it made a specific claim and you watched it fail. If you cannot compute the fraction honestly, you do not have a progress bar; you have a spinner wearing a costume.

If you have read the engineering track: the 300–500ms delay before showing a loader is the same shape of argument as the one in 0001 about durations — the threshold is perceptual, not stylistic, and picking the number by feel in a mock is how it gets picked wrong.

A skeleton is a claim about layout

The reason a skeleton earns its place is that it is specific. It is not a polite grey rectangle; it is the layout of the thing you are about to receive, with the content taken out. An avatar-sized circle means an avatar is coming. Three rows of decreasing width mean a name, a line of text, and a timestamp. The reader is given a map, and a map is only useful if it matches the territory.

So the skeleton's failure mode is not ugliness, it is a broken promise about geometry. When the real content arrives at a different size, everything below it jumps — and that jump is worse than the one you would have got from a spinner, because the reader had already started reading the layout. You did not save them the shift; you made them a false map first and then shifted anyway.

Two consequences that come up constantly in review, both of them worth having a sentence ready for. A skeleton for content whose size you genuinely cannot predict — a comment thread, a search result set, anything of unknown length — is a guess presented as a promise, and one generic block that resolves into nine items is not better than a spinner. And a skeleton that resolves to an empty state is the sharpest version of the same fault: you showed the reader the shape of three results and then told them there were none.

If you have read the engineering track: 0011 is the argument for why the jump costs what it costs, and 0012 is the one about elements that appear without being announced. A skeleton is the design-level answer to both at once: it reserves the space and tells you what is going to fill it.

The two loops, and who asked for them

A spinner rotates forever. A shimmer sweeps forever. Both of them are unrequested, looping, attention-taking movement that starts without the reader doing anything — which is the precise description of what somebody is switching off when they turn on reduced motion.

The mistake is to read that as "so remove the feedback". The loop is the problem, not the indicator. Turn on reduced motion in your system settings and look at the lab above again: the spinner stops turning and the caption beside it is doing the work it was always doing, and the skeleton stops shimmering and is still, unmistakably, a skeleton. Nothing was lost that was carrying information.

The progress bar keeps moving, and that is deliberate. Its movement is not decoration applied to a state — it is the state, drawn. Freezing it would be removing information rather than removing an effect, which is a good general test for what survives that setting.

If you have read the engineering track: 0009 makes this argument in full, including why "kill all animation" is the wrong reading of the request.

The best wait is the one you never show

Everything so far has been about designing a wait well. The bigger win is not having one. If you already know what the answer will almost certainly be, you can show it immediately and reconcile with the server afterwards — the row appears the instant the reader clicks, and the network catches up in private.

This is where optimism gets sold on the happy path and the bill arrives later, so the lab below has a switch that makes the request fail.

The left pane's cost is time and nothing else. It was slow and it was honest, and at no point did the screen contain something untrue. The right pane's cost is the third step above: for one action, the interface changed twice. It said yes, and then it took the yes back — and that second change is not an error state you bolt on afterwards, it is the feature you are actually designing when you choose optimism.

Which gives three conditions, and they hold together. Optimism is right when the action almost always succeeds, when the failure is cheap to undo, and when the reader will still be there to be told. Starring a message, adding to a list, toggling a setting: all three hold, and the interaction is transformed. Submitting a payment, sending a message to another person, confirming a booking: the first condition might hold, the second never does, and a rollback on the third one is not a rollback, it is an apology for something the reader has already told someone else about.

The last condition is the one that gets forgotten, and it is a design constraint rather than an engineering one. An optimistic update is only safe while the reader is still looking at the place where you would take it back. If the pattern lets them start the action and immediately move on — hit save, close the panel, go to another page — then the rollback has nowhere to land, and a toast that appears on a screen they have left is not a rollback at all.

One nuance the lab shows and most products skip: the pending row is marked. A dashed edge and a hollow dot say this is here but not confirmed, and it makes the rollback legible when it comes. The cost is that you have put a small piece of visual noise in front of the 99% of readers whose save was going to work, which is a real argument for dropping it. The way to settle that in a review is to ask how bad the rollback is: quiet failure, quiet marker; expensive failure, keep the marker, or don't be optimistic at all.

If you have read D005: this is the same distinction under a finger — the difference between a gesture that is tracking and one that has been committed. A pending row is the list-shaped version of a drag that has not yet been accepted.

Check yourself

What you can now do

Look at any loading state and say what the wait's two facts are — how long, and whether the length is knowable — then say whether the treatment on screen follows from them or from the component library. Catch the flash of loading before it ships, because it will not show up in a mock. Say what a skeleton is promising and whether the arriving content can keep that promise. And when optimism is proposed, take the conversation straight to the failure: how often, how expensive, and where the reader will be standing when you take it back.

Next: the biggest wait most products have is the one between pages — and there the design problem stops being "is something happening" and becomes "where am I now".

D009 was about the wait: something is happening, and the screen has to say so honestly. This is the other half of the same moment. The request came back, the new screen is here, and the reader has a different question now — not is it working but where am I. That question has a deadline of about a third of a second, and if the screen does not answer it, the reader answers it themselves by reading everything again.

Four frames below. Same app, same tap, same 420 milliseconds — four different sentences about what just happened.

Four models, four claims

A cut claims nothing. That is not a failure state — it is the right choice more often than transition-enthusiasts admit, particularly for navigations the reader performs dozens of times an hour. Motion has a cost that gets paid on every repetition, and a cut costs nothing. If you cannot say what the transition is telling the reader, the cut is telling them the same amount, faster.

A cross-fade claims a different thing, in no particular place. It is the mildest possible statement: something changed, be calm about it. It is genuinely useful when two screens have no spatial relationship worth asserting — a dashboard and a settings page do not live next to each other in any sense the reader can hold — and it is the safest default when you are not sure. Its weakness is exactly its virtue. It cannot distinguish going in from coming out, so it can never help the reader retrace their steps.

A push claims direction. The old screen is not gone, it is over there, one step behind you. This is the model that builds a mental map, and it is the reason phone operating systems have leaned on it for fifteen years: after a few minutes with it, the reader knows there is a stack and knows which way is out. The cost is that a push commits you. Once forward means "from the right", every navigation in the product has to have an opinion about which direction it is, and any screen that genuinely has no direction will feel arbitrary when you give it one.

A shared element claims this specific one. Of the four it is the only one that says something about the object rather than about the screens. The reader tapped a row; the thumbnail from that row is now the header of the page they are on; the identity is established without a word of copy. That is a lot of meaning for one moving square, which is why it is the model people over-reach with. It only works when the thing that persists is genuinely the same thing. Fly an arbitrary rectangle across the screen because the geometry happens to work and you have made a claim the reader will test and find false.

If you have read 0011: the shared-element frame above is FLIP, applied across a navigation instead of within a list — measure the start box, measure the end box, and animate the end element from the difference. Nothing in this section needs that lesson; it just names the technique for the reader who has it.

Go and look the HTTP 203 playlist demo — a small video app built to show exactly this. Click a video from the list and watch the thumbnail become the player: that is a shared element, and the identity claim lands before you have read anything. Then notice what did not move — the bar across the top is the same bar, and it never blinks. Now press your browser's back button and watch the thumbnail go home. Do it twice: once watching the object, once watching everything except the object. All three links checked 2026-09-05. Sites get redesigned; if one has, the exercise is still to name what replaced it.

Back is not forward

Here is the failure you will ship if nobody stops you, and it is worth dwelling on because it is almost invisible in review. Forward and back are the same navigation in the code — one screen replaced by another — so they run the same transition, and the transition plays the same way. Set Back behaviour to repeats forward in the lab and press back: the list slides in from the right, exactly as the detail did. The screen has just told the reader they went deeper, at the precise moment they were trying to get out.

The reason this survives review is that it is invisible in every artifact a review uses. A static mock cannot show it. A screenshot of a correct back and a broken back are the same image. Even a recording will pass if the person recording it only went forward. It is caught by one thing: somebody navigating in both directions, on purpose, watching. Put that in your review checklist as a sentence — press back and describe what you were told — because it will not occur to anyone spontaneously.

The fix is a direction of travel, not a second animation. If forward is "in from the right", back is the same motion with the sign flipped, and both fall out of one variable. The same is true of a shared element: forward the object flies to its new home, back it flies to the row it came from. What makes the pair legible is that they are visibly the same motion undone, which is also why you should resist the temptation to give back its own charming treatment. Back's job is to be recognisably the reverse. Charm is forward's job.

Reversibility also decides how much you can spend. A transition the reader will only see once can be expressive. A transition they will see going both ways, thirty times a session, has to survive repetition in both directions — and things that survive repetition are short, quiet, and the same every time.

If you have read 0005: this is that lesson's asymmetry argument at the scale of a whole screen. An exit is allowed to be faster than an entrance; what it is not allowed to be is a second entrance pointing the wrong way.

Go and look Chrome’s paginated view-transitions demo — a real page-to-page navigation, not a single-page imitation of one. Click through two or three pages and then use the browser back button rather than the on-page link. The motion reverses, and it reverses because the page asked which kind of navigation this was before choosing a direction. Then reload in the middle: the reload is treated as a third case and gets neither direction, which is the detail worth stealing.

Orientation is what did not move

Everything so far has been about the parts that move. The next lab is about the parts that refuse to, and this is the half that is consistently underrated: a reader knows they are still in the same app because the bar across the top is the same bar it was a second ago, not because something slid nicely.

The number in that lab is measured off the frame, and it is a blunt instrument on purpose. What it makes obvious is that both panes ran the same fade for the same duration — the difference in how settled the right-hand one feels was not bought with better motion. It was bought by excluding things from the motion.

Persistent chrome does three jobs at once. It answers am I still in the same place without the reader having to check. It gives the moving parts a frame to move inside, which is what stops a transition reading as the whole world being replaced. And it lets small things carry the change: when the tab bar survives, the highlight can travel to the new tab instead of reappearing on it, and that one moving pill does more orientation work than a full-page slide because it is a continuous object rather than a new arrangement.

There is a design decision hiding in that, which is worth making explicitly rather than discovering: what is the smallest region that has to change? Most navigations change less than the implementation changes. If only the content area is genuinely different, animating the whole viewport is not a bolder choice, it is a less accurate one.

If you have read D003: persistent chrome is the hierarchy argument turned inside out. That lesson asked which element should move first; this one asks which should be exempt, and the answer comes from the same ranking.

Arriving cold

Every transition in this lesson assumes the reader came from somewhere. A large share of them did not. They followed a link from a message, they refreshed, they restored a tab from three days ago, they hit a bookmark. There was no previous screen, so there was no transition, and every sentence you carefully wrote was never delivered.

This is the test that keeps transition design honest. Load the destination cold and ask whether it still explains itself: does it say what it is, does it offer a way up that is a real destination rather than "back", and does it survive having no history behind it? If the answer is no, the motion was carrying information — and motion is the worst possible place to keep information, because it is the first thing that disappears. It is absent on cold entry, absent when the reader looks away mid-navigation, absent on a slow device that drops the whole animation, and absent by request for anyone who has turned it off.

The rule that falls out is short: a transition may reinforce a relationship the screen already states. It may not be the only place that relationship exists. A shared element that establishes "this is the kettle you tapped" is doing lovely work on top of a page whose heading says Kettle. It is doing load-bearing work — badly — on a page that expected the animation to introduce it.

Go and look Chrome’s stack-navigator demo — a messages app where the transition asserts depth: screens slide over each other and back out again. Go two levels in, then copy the URL, open it in a new tab and look at what you land on. You get the same screen with none of the sentence, and the question to ask is whether the page still tells you where you are. Then go back one level and watch how the screen underneath was waiting there the whole time rather than being rebuilt.

When motion is off

Turn reduced motion on and all four models in the first lab collapse to a cut. That is the accommodation, and it is also the cleanest possible version of the cold-entry test: everything the transition was telling the reader has just gone. What is left has to answer the question by itself.

Notice what the second lab does under the same setting. It keeps working. Nothing animates, the frames swap instantly, and the right-hand one is still noticeably more settled than the left — because persistence was never motion in the first place. It is a fact about the layout. That is why it survives the setting, the refresh, the deep link and the dropped frame, and it is the strongest argument in this lesson for spending your effort on what stays rather than on what moves.

There is one honest exception worth keeping. A cross-fade is opacity only — no travel, no parallax, nothing for the vestibular system to object to — so it is a reasonable thing to keep when a reader has asked for less motion, where a push is not. If you want a graceful degradation rather than a hard cut, that is the one to reach for.

If you have read 0009: the same stance, one scale up. The distinction that lesson draws between decorative and load-bearing motion is exactly the cold-entry test above, arrived at from the other direction.

The CSS behind it

/* Browsers now do this natively, across a real page navigation. */
@view-transition { navigation: auto; }

/* Name the things that persist or travel. A name must be unique
   per snapshot: two elements with the same name in one frame and
   the transition is skipped entirely. */
.site-header { view-transition-name: header; }
.card--active img { view-transition-name: hero; }

/* Back is not forward. The type is set per navigation, and the
   direction falls out of one variable rather than two animations. */
html:active-view-transition-type(forwards) {
  &::view-transition-old(content) { animation: slide-out-left 300ms both; }
  &::view-transition-new(content) { animation: slide-in-right 300ms both; }
}
html:active-view-transition-type(backwards) {
  &::view-transition-old(content) { animation: slide-out-right 300ms both; }
  &::view-transition-new(content) { animation: slide-in-left 300ms both; }
}

/* The reader asked for less. A cross-fade is opacity only, so it
   is the honest thing to keep when travel is not welcome. */
@media (prefers-reduced-motion: reduce) {
  ::view-transition-group(*) { animation-duration: 1ms; }
  ::view-transition-old(root),
  ::view-transition-new(root) { animation: fade 120ms both; }
}

Check yourself

What you can now do

Look at any two screens in a product and say what the transition between them claims — nothing, a difference, a direction, or an object — and whether that claim is true of the relationship. Say which of the four models the navigation deserves, and be willing to argue for the cut. Check the way back as a separate design, in both labs' sense: press it, describe what you were told, and refuse a back that reads as a second forward. Name the persistent chrome in any design you are shown, and notice when there is none. And run the cold-entry test on every screen a transition introduces, because that is where you find out whether the motion was decorating the information or holding it.

Ask yourself: take the last navigation you designed or built and write its sentence in words — "you went into this specific thing", "you moved sideways within a set", "something different is here now". Then load the destination cold, with no history, and see how much of that sentence is still being said.

Next: every one of these decisions costs something, and they are all competing for the same budget on the same page.

D010 ended on a claim: a transition is a sentence about how two screens are related. Here is what that claim costs. If a transition is a sentence, then a screen with eight animations on it is eight people talking, and the reader can follow one. Motion is the loudest thing a design has, and loudness does not add up — it divides.

Below is a dashboard and one refresh. Two settings: what actually changed, and what you allowed to move about it.

The budget is attention, not milliseconds

The reason to have a budget is not that animation is expensive to run. It is that the reader has one visual system, it is extremely good at detecting movement, and it will look at whatever moves whether or not that was useful. You do not get to choose whether motion takes attention. You only get to choose what it takes it for.

That is why the lab counts three things rather than one. Signal is motion on something that changed. Noise is motion on something that did not. And the third count, the one nobody puts in a review, is the change that happened with no motion at all — the figure that quietly became a different figure while the reader was looking at the other side of the screen.

Set the budget to everything with one figure changing and look at what has happened to the signal. Nothing was removed. The one honest animation is still there, playing exactly as it did before, and it has become useless — because a highlight is not a property of the thing highlighted, it is a property of the difference between that thing and everything else. Seven animations did not dilute the eighth by a bit. They cancelled it.

This is what busy means, and it is worth being precise about it, because it gets used as a synonym for "too much" and it is not one. A screen is busy when it makes more claims than the event deserved. One long, heavy, indulgent animation on the one thing that changed is not busy. Eight two-hundred-millisecond fades on a screen where one number moved is busy, and it is busy at any duration you like.

Which is also why "less is more" is the wrong lesson to take from that lab, and why the second setting exists. Switch the event to the whole page reloaded and put the budget back to one thing: now one panel is animating and four panels changed underneath it in silence. The motion is under-reporting. It points at one figure and implies the others are as they were, and the reader believes it, because that is what a highlight means.

The right amount of motion is the size of the event. That is the whole rule, and it explains both failures with one sentence. Eight animations for a one-figure change is a lie in one direction. One animation for an eight-panel change is a lie in the other. The budget is not a number you set once for the product; it is set fresh by every event, and the only question is whether the motion is telling the reader the truth about how much just happened.

Busy and expensive are different failures

These two words get used interchangeably in reviews and they name opposite problems, which means half of all animation feedback is aimed at the wrong thing. It is worth being able to separate them out loud, because the fix for one does nothing at all for the other.

Busy is a failure of quantity: too many things claiming attention in the same second. You can have a busy screen where every individual animation is short, cheap, tasteful and defensible. The fix is subtraction — decide which one thing is the news and let the rest hold still.

Expensive is a failure of price: one thing costs too much. Too long, too often, or too heavy for the machine it is running on. A single animation can make an entire product feel slow, and no amount of removing other animations will help, because there were not any others. The fix is to make that one cheaper.

So the diagnostic question in a review is: how many things are moving? If the answer is "eight", you have a busy problem and you are looking for things to cut. If the answer is "one", you have an expensive problem and cutting is not available — you are looking at the length, the frequency, and what it is animating.

If you have read 0002: that lesson prices the third kind of expensive — the machine's bill, where animating a layout property costs orders of magnitude more than animating a transform. Everything here is about the reader's bill instead. The two are independent: a design can be perfectly cheap to render and still ruinously busy.

Go and look the GOV.UK accordion — a real, interactive component from a system a government uses to build services everybody has to use. Open and close a few sections, press show all, and notice that the height change is the entire animation budget of the component. Then walk on through ten more from the list beside it and keep counting. The harder half is this: name the three interactions where you noticed the absence and felt worse for it, and the three where you did not notice at all. That ratio is the argument for a budget, made by someone who set theirs near zero. Checked 2026-09-06. Sites get redesigned; if this one has, the exercise is still to count what moves.

Multiply by how often

Here is the arithmetic nobody does. An animation's cost is not its duration. It is its duration times the number of times the reader will see it, and those two numbers are decided in different rooms — the duration while everyone is looking at a hero, the frequency by whoever picks which control it gets applied to, six weeks later.

Both frames run the identical animation. Same length, same easing, same everything — the only difference is how often it happens, and at 600 milliseconds that difference is roughly a hundred to one. This is the repetition tax, and it has three consequences worth taking away separately.

The first is that a duration cannot be judged without its frequency. When someone shows you a 600ms transition in isolation and asks whether it feels good, the honest answer is a question: how many times a day? Six hundred milliseconds is generous and lovely on a page that arrives once. On the panel you open forty times it is eight seconds of your day spent watching a rectangle travel, and you will have started resenting it by Thursday.

The second is that frequency runs the other way too. Watch the left frame at 140ms: the arrival is gone. There was no shortage there — one play, no repetition, nothing to economise on — and the saving bought nothing except a page that appears with a snap. Short is not a virtue. It is the correct answer to a specific question, which is "how often?", and when the answer is "once", generosity is free.

The third is the awkward one for a design system, and it is the reason this lesson sits where it does in the track: a single duration token cannot be right everywhere. The same 300ms that makes a modal feel considered makes a hover state feel broken, and the difference between them is not aesthetic, it is arithmetic. A system needs at least a fast token and a considered one, with the rule for choosing between them written down as a frequency question rather than as a size question.

If you have read 0001: that lesson argues durations from the distance travelled and the weight implied. This is the multiplier on top of it — the same 300ms correctly chosen there gets a completely different verdict once you know it plays two hundred times a day.

Go and look Excalidraw — open it and use it for two minutes: draw a few boxes, select them, move them, open the style panel, undo a dozen times. It is a tool people keep open all day, and almost nothing in it animates. Count the frames you wait for. Then find the one or two places where they did spend — and ask what those places have in common, which is that they are the ones you do once rather than the ones you do all afternoon.

Idle motion is a standing charge

Everything so far has been motion caused by an event: something happened, and the screen said so. Idle motion is the other kind — the pulsing "live" dot, the looping gradient, the shimmering banner, the marquee of logos, the icon that breathes. Nothing happened. It is moving because it was built to move.

Price it the way you priced everything else and it is the most expensive motion on the page, because its frequency is always. It is spending attention in every second the screen is open, including all the seconds when something real is trying to be reported. A pulsing dot next to a status that has been the same for six hours is competing, at full volume, with the alert you actually need the reader to see.

The honest test for idle motion is: what is it telling me that I could not learn by looking? A live indicator that pulses when data is genuinely arriving is reporting something, and the pulse is the report. A live indicator that pulses on a timer is decoration wearing the costume of information, and it is the one to argue about, because it costs the same as the real thing and says nothing.

There is one legitimate use worth protecting: idle motion as a promise that the system is alive. Progress that cannot be measured, a connection that is being held open, a long job whose only honest statement is "still working". That is a real thing to say, and continuous motion is the natural way to say it. The distinction is whether stopping it would be a lie.

If you have read D009: this is the same argument as the indeterminate spinner, one step out. A spinner earns its continuous motion by being tied to a request that is genuinely in flight; the moment it plays on a timer instead, it has become idle motion with a job title.

How to say no

Most animation gets built because nobody had a way to decline it that was not "I don't like it", and taste is the one argument that cannot be answered, so it loses to whoever is more senior. A principled no is a no with a question in it. Here are the four that do the most work, in the order they are worth asking.

What does this tell the reader that the layout does not? If the answer is nothing, the motion is decoration — which is allowed, but it must then be priced as decoration and spent from what is left after the reporting is done. If the answer is something, ask the next question, which is whether that something should have been in the layout to begin with.

How many times a day will this play? Not "is it fast", but "how often". This is the question that turns an argument about taste into an argument about arithmetic, and the arithmetic is checkable. It also converts a lot of noes into "yes, at a third of that length", which is a much easier thing for everyone to agree to.

What else is claiming attention in the same second? An animation is never reviewed against the thing it is competing with, because in the review it is on a slide by itself. Ask what else moves on that screen in the same moment, and count. If the answer is more than two, the design question is no longer about this animation.

What happens to this screen when the motion does not play? Slow device, dropped frames, reduced motion, a reader looking away. If the screen stops making sense, the motion was carrying information and the information has to move somewhere sturdier before the animation can be shipped at all.

Four questions, and none of them is "do you like it". That is the point. Every one can be answered with evidence, which means the conversation ends in a decision rather than in seniority.

When motion is off

Turn reduced motion on and both labs go quiet, and each one says something different about it. The second one gets simpler: that reader's repetition tax is zero, and the panel still opens, still lands where it should, and is still perfectly usable. That is a useful thing to notice — if an interaction only makes sense once the animation plays, the animation was not the problem.

The first lab is the interesting one. With motion off, the figure that changed keeps a static accent flag instead of a movement, and it has to, because otherwise the change is simply not reported to that reader at all. A budget of zero is exactly the condition every screen should be designed to survive, and the way to survive it is to have a second channel — colour, a delta, a count, a position — for anything the motion was doing real work to say.

Which is the same rule as the last lesson's, arriving from a different direction: motion may reinforce what the screen says. It may not be the only place the screen says it. The budget makes that concrete, because a screen designed to a budget has less to lose when the budget goes to zero.

The CSS behind it

/* Two tokens, not one. The rule for choosing between them is a
   frequency question, so write the frequency into the name. */
:root {
  --motion-quick: 140ms;   /* things touched all day: hovers, panels, rows */
  --motion-considered: 420ms; /* things met once: arrivals, first loads */
  --ease-out-strong: cubic-bezier(0.16, 1, 0.3, 1);
}

/* Signal: the element that changed announces itself. One rule,
   applied to whatever actually changed, rather than a rule per
   panel that fires whether or not it has news. */
[data-changed] {
  animation: report var(--motion-considered) var(--ease-out-strong);
}
@keyframes report {
  from { opacity: 0; transform: translateY(0.35rem); }
}

/* Idle motion, gated on the thing being genuinely live rather
   than on the component existing. If stopping it would not be a
   lie, it should not be running. */
.status-dot[data-live="true"] {
  animation: pulse 2s ease-out infinite;
}

/* Budget zero. Note that the flag is not a shorter animation —
   it is a different channel, because the reader still has to be
   told what changed. */
@media (prefers-reduced-motion: reduce) {
  [data-changed] { animation: none; color: var(--accent); }
  .status-dot[data-live="true"] { animation: none; }
}

Check yourself

What you can now do

Count the moving things on any screen you are shown, and use the count to say which failure you are looking at — busy needs subtraction, expensive needs a lower price, and the two get confused in almost every review. Price any animation properly, as its length times how often it plays, and refuse to judge a duration without knowing the frequency. Spot idle motion and ask what would be untrue if it stopped. And decline an animation with a question rather than with taste, which is the only kind of no that survives the room.

Ask yourself: open the product you work on, pick the screen you look at most, and count every distinct thing that can move on it. Then write, next to each one, the event that causes it and how many times a day you personally see it. The ones with no event, or with a frequency in the hundreds, are your budget review — and it will be shorter and more obvious than any opinion you could have had about them.

Next: the drill. Ten designs, one flaw each, and you name the flaw, the fix and the principle before the answer appears.

D011 ended with a way to say no: an animation is worth its cost or it isn't, and the cost is its length times how often it plays. That gets you through a review where the question is should this exist. It does not get you through the far more common one, where the animation should exist, is going to ship, and is subtly wrong — and the only thing between it and production is whether you can say what's wrong before the meeting ends.

They are deliberately not defined yet. You get them by feeling them, one specimen at a time, and the table that separates them is at the bottom of this page where it belongs.

The adjectives, now that you have felt them

Every word below names a different defect and — this is the part that makes them worth learning — a different repair. Reaching for the wrong word does not just describe the problem imprecisely; it sends the other person off to fix the wrong thing.

Saying it in a room

The three-part form is not a script for sounding rigorous. It is a filter that catches your own bad notes before you give them, because a note that cannot produce all three parts is usually a note about your taste.

Try it against the hedges. "It feels a bit off" is a flaw and nothing else — no fix, no principle, so the other person's only move is to guess. "Can we make it faster?" is all fix: it might be right, but with no flaw named you cannot tell whether faster addresses the actual problem, and half the time it doesn't — busy gets faster and stays busy. "Motion should always be purposeful" is all principle, which is the worst of the three, because it is unarguable and applies to everything, so it lands as a verdict on the designer rather than as a note on the work.

It fails in the other direction too. A flaw with no fix is a complaint. A fix with no principle is an instruction, and it will be followed exactly once — the next screen will have the same problem, because nobody learned anything transferable. The principle is the part that makes the note worth the meeting.

The engineering track argues most of these from the mechanism, if you have read it: 0001 for floaty, 0002 for busy, 0010 for mushy and twitchy, 0009 for what gratuitous costs a reader who has asked for less motion.

The one you should not give

"Janky" is on the vocabulary list because you will hear it, not because you should say it. It means dropped frames — a specific, measurable rendering fault — and it is the one word here that a designer cannot verify by looking. Everything else you can settle by watching the thing twice. This one needs a recording, and the difference between an animation that drops frames and one that is merely floaty is invisible to the naked eye and enormous to whoever has to fix it.

So when something feels wrong in a way none of the other eight words fit: say what you saw, hand over the case, and let it be measured. "It stutters on my machine when the sidebar is open" is a better note than "it's janky", because it is a note someone else can reproduce.

Lesson 0014 is the reading-a-recording lesson, for being the person who settles it rather than the person who reports it.

Check yourself

What you have now

Nine words, each attached to a specimen you have actually watched and a repair that follows from it. That is the whole trick. Vocabulary is worth building not for precision's own sake but because "mushy" and "sluggish" send the fix to two different places, and saying the wrong one costs a round trip that a design review does not have time for.

The drill is re-runnable, and it is worth re-running cold in a month. The specimens will not have changed, but the thing being tested is whether the word arrives before the explanation does — and that is the only measure of whether the vocabulary is yours yet.

D012 left you able to look at an animation and say what is wrong with it in one sentence someone can act on. That is the skill a design review runs on, and it has a ceiling: giving the same critique twelve times, in twelve reviews, about twelve components, is not a critique problem. A token is a critique you only have to give once. The rest of this lesson is about what has to be true of that token for it to survive being reused by people who were not in the room.

Below is one small screen with five moving parts and three durations. Turn a duration and watch how much of the screen answers; then switch the naming knob, which changes nothing on the stage and everything about whether the set can be edited a year from now.

What a token actually buys

The fan-out is the part everyone demonstrates. One value moves and five components restyle, and that is real, and it is not the reason to do this. A find-and-replace would also have moved five numbers. What you are buying is that the argument about 240 versus 400 happens once, in one place, instead of in every component review for the next year.

Think about what the alternative actually costs. Without a set, every new panel arrives at a review with its own duration, chosen by whoever built it, and that duration is a fresh question: is it right? Compared to what? The reviewer has to reconstruct, from memory, how fast the other panels are — and memory is a bad instrument for a difference of eighty milliseconds. The conversation is unwinnable in both directions, so it usually ends in "looks fine" and the product gets one more slightly-different number in it.

With a set, the same review is a much smaller question: which token is this, and does the component's job match the token's job? That question has an answer, and the answer does not depend on anyone's memory of a different screen.

If you have read D011: this is where that lesson's two durations were heading. --motion-quick and --motion-considered were named by frequency because frequency was the deciding question, and a set is just that move made general — the name carries the rule you used, so the next person does not have to rediscover it.

The name is the whole thing

Switch the lab to value naming and retune anything. The stage does not change — the numbers are identical, the motion is identical, and nothing about the product is different. The rail is what changes: --duration-120 is now holding 200ms.

A token named for its value is a number with a nickname. It looks like a system, it lives in the same file as a system, and it fails at the one moment a system is supposed to earn its keep, which is when a decision changes. Retune it and the name is a lie that no build, no linter and no review will ever catch. The value is right and the label is wrong, and those two facts can coexist indefinitely because nothing in the toolchain knows the name was ever supposed to mean anything.

You have two ways out and both are worse than not having got here. Rename the token, which means finding every use across the codebase and the design file for the sake of a label — a refactor with no user-visible outcome, which is the first thing cut from any sprint. Or leave it, and accept that from now on the names are decoration and the only way to know what a token does is to look up its value. That second one is what almost always happens, and it is the moment the set quietly stops being a system.

Now the same argument from the other end. The lab asks you where a brand-new tooltip should get its duration. Under role naming, the rail answers it: a tooltip arrives in place, so it takes the arriving duration — and you can pick the right token without knowing what any of the numbers are. Under value naming there is nothing to answer with: the only moves available are to guess, or to copy whatever the nearest component happened to use. That copy is the mechanism by which a token set turns back into a pile of numbers, one plausible decision at a time.

How many tokens

Both failure modes are common and they fail in opposite directions.

A token per component — --drawer-duration, --toast-duration, --modal-duration — is a spreadsheet. It has all the ceremony of a system and none of the leverage, because nothing is ever shared, so no change is ever made in one place. It also cannot be reasoned about: there is no way to ask whether the drawer and the modal should match, because they were never claimed to be the same kind of thing.

One token is the other failure. A single duration is a system that cannot say a modal is heavier than a hover. That difference is not a nicety — it is the hierarchy signal D003 spent a whole lesson on. Collapse it and every layer of the interface arrives at the same speed, which reads as an interface with no layers.

The right number of tokens is the number of genuinely distinct decisions, not the number of components. In practice that lands around three durations, two curves, and — if the system has any expressive surface at all — a small distance scale. Three durations because there are three recognisably different jobs: feedback on something you just touched, something arriving in place, and something covering what was there. Two curves because entering and leaving are the one asymmetry worth encoding.

If you have read 0005: the second curve is that lesson's point, promoted to a token. An exit is allowed to be faster and flatter than an entrance, and a system with a single shared curve makes that impossible to express without a local override — which is drift, arriving by the front door.

/* Three durations, named for the job rather than the number, so the
   name survives being retuned. The comment is not decoration: it is
   the rule that decides which one a new component takes. */
:root {
  --motion-state:   120ms;  /* feedback on the thing you just touched */
  --motion-enter:   240ms;  /* something arriving in place */
  --motion-overlay: 320ms;  /* something covering what was there */

  --ease-enter: cubic-bezier(0.16, 1, 0.3, 1);   /* decelerate in */
  --ease-exit:  cubic-bezier(0.4, 0, 1, 1);      /* accelerate out */
}

/* One place decides what happens for a reader who asked for less. Not
   five components each remembering separately — that is the decision
   most likely to be forgotten in the sixth. */
@media (prefers-reduced-motion: reduce) {
  :root {
    --motion-state: 0.01ms;
    --motion-enter: 0.01ms;
    --motion-overlay: 0.01ms;
  }
}

.toast  { transition: transform var(--motion-enter) var(--ease-enter); }
.drawer { transition: transform var(--motion-overlay) var(--ease-enter); }

That last block is worth saying out loud, because it is the strongest practical argument for having a set at all. The reduced-motion rule belongs in the token set, because it is one decision rather than five. A decision spread across five components is a decision that will be right in four of them. Every audit that finds a component ignoring prefers-reduced-motion finds it in the newest one, built by someone who copied an older component that predated the rule.

Drift, and why it never looks like a problem

Turn the lab's last knob: the modal is hardcoded at 320ms and stops reading the token. Now retune the overlay duration. Four things move and one does not.

What is worth noticing is how unalarming that is. The modal still opens. It still looks fine on its own. Nothing in the build says anything, nobody's test fails, and the component works exactly as well as it did yesterday. Nothing broke, which is the problem: a detached component keeps working perfectly while the system quietly loses the ability to change it.

Drift almost never arrives as a decision to leave the system. It arrives as a deadline: the modal needed to be a little slower for one release, the token was owned by another team, and a local override was the twenty-second version of a two-week conversation. That is a reasonable trade, made under real pressure, and the cost of it is invisible for months — until someone retunes the overlay duration and one dialog in the product is subtly out of step with every other layer, and nobody can say why.

The practical defence is not discipline. It is making the override visible: a lint rule, a comment convention, a list of known exceptions that a human reads once a quarter. What matters is that the exception has a name and an owner, because an exception you can see is a decision and an exception you cannot see is just the current state of the code.

The handoff

The set is half the job. The other half is the artifact you hand over, and this is where most motion work goes wrong — not because designers write bad specs, but because a static file has a shape, and some things do not fit inside that shape at all.

Three animations below, three specs, and three different kinds of silence. The card on the right is generated from the same data that drives the demo, so it cannot quietly disagree with what is on screen — which, worth saying, is the one property a real spec never has.

Three kinds of silence

Start with what does hand over, because it is most of it. Property, distance, duration, easing, direction, stagger, and the reduced-motion rule all survive being written down. A spec that carries those seven is a good spec and most specs do not carry all seven. If you take one practical thing from this lesson, it is that the reduced-motion row belongs on the sheet, spelled out as a design decision, not left as an implementation detail for someone to remember.

The drawer is silent about state. Both panes have the same duration, the same curve, the same distance — everything the handoff contained — and the right one snaps back to fully open before it closes, because it was told where the drawer starts and where it ends and nothing else. Interruption is not a missing detail, it is a missing category: a spec describes two states, and a reader can be in any of the ones between them. You cannot draw "and if she changes her mind at 40%", because there is no 40% in a static file.

The list is silent about data. Every number in that spec is correct. 200ms per row, 60ms apart, signed off against a mock with five rows — and at forty rows the last one arrives two and a half seconds after the first. A stagger is not a duration, it is a duration multiplied by a number the design file never contained. The fix is a cap, stop staggering after row eight, and that cap is a real design decision that gets invented at build time by whoever happens to notice.

The header is worse than silent. Its spec has a Duration field and an Easing field and both are filled in, and both mean nothing. When the clock is the scrollbar there is no duration to specify: the reader sets the speed, can run it backwards, and can park it half done. That is a state no timed animation ever sits in. Park it half way and look at it: that half-condensed header has to be something a person could screenshot, and it is not on the sheet, because the sheet has two frames and this has a continuum.

A wrong number in a spec is more expensive than a blank one, because a blank gets a question and a number gets built. The 300ms in that field will become a 300ms transition layered on top of the scroll, fighting it, and the resulting lag will be reported as a performance bug six weeks later.

What to write down

The useful reframe: a handoff's job is to carry decisions, not measurements. A measurement can be read off a prototype. A decision cannot, and it is the thing that will otherwise be made silently by whoever is holding the ticket.

So the sheet has two halves. The first is the seven fields above, filled in — and filled in with token names, not numbers, wherever a token exists, because --motion-overlay hands over the rule as well as the value while 320ms hands over only the value.

The second half is a short list of sentences, and these are the ones that get left off:

• What happens when it is interrupted. "Closing mid-open reverses from where it is" is one sentence and it is the entire difference between the two panes above.
• What happens at the extremes of the data. One row, forty rows, zero rows. Name the cap.
• What happens for a reader who asked for less motion. Not "respect reduced motion" — say what the interaction does instead.
• What is allowed to be dropped under pressure. If the animation has to go, what is the interface without it? This one is a gift to the engineer.

That last one is the D011 test written into the handoff. If the interface only makes sense once the animation plays, the animation was never the problem — and finding that out during the handoff is enormously cheaper than finding it out from a bug report about a reader who turned motion off.

The parts that only exist in code

Some things are not being withheld from the spec. They genuinely do not exist until something runs, and the honest move is to mark them as such rather than to invent a number.

Springs are the clearest case. A spring has no duration — it has stiffness, damping and a starting velocity, and that velocity comes from the reader's finger. Two people can flick the same card and get two different settle times, both correct. A spec can say "springy, and it should feel like it carries the reader's momentum"; it cannot say 400ms, and a spec that says 400ms has converted a physical system into a timed one, which is a different design.

If you have read 0008: this is why that lesson insisted the spring's parameters are not a curve in disguise. The reason it matters at handoff is that the one field a spec most wants to fill in — duration — is the one field a spring does not have.

Interruption is the second. Reversal, re-triggering, what happens when three toasts arrive at once — all of it is state machinery, and the design decision is which behaviour is correct, not how it is implemented. Write the sentence; leave the implementation alone.

The third is anything counted at runtime: list lengths, grid sizes, how many items are on screen. And the fourth is performance. Whether an animation holds sixty frames on the oldest device you support is not knowable from a design file, and it is the one item on this list where the right answer might be to change the design.

Where the engineer has to invent a decision, that is where the spec should have had a sentence. Which makes the review question at the end of a handoff a simple one: what did you have to decide that I did not tell you?

What you have now

A token set is not a list of durations. It is a set of decisions already made, named so that the next person can apply them without redoing the reasoning — which is why the naming is not cosmetic, and why a name minted from a value is a system with a fuse in it.

And a spec is not a description of an animation. It is the decisions that a running interface cannot infer on its own. Most of those write down cleanly. The four that do not — state, data, driver, and the physical ones — are exactly the four that end up being decided by whoever is building it at eleven at night, which is a fine way to make a decision and a terrible way to make it consistently.

This is the last of the judgment lessons, and the design track's shape is now complete: D001 gave the words, D004 through D010 gave the patterns, D011 gave a way to say no, D012 gave a way to say what is wrong, and this one gives a way to make either of those stick after you have left the room.

D013 ended on a set of named durations — a critique argued once, then reused by people who were not in the room. Open Framer and half that work is already done, by someone you will never meet, in numbers written down nowhere you can open. That is not a flaw. It is the most useful single fact about working in a tool of this shape: a canvas tool does not change what motion is, it changes the unit of the decision. In CSS the unit is a property, a duration and a curve. In Framer it is two states and a trigger, and the animation between them is worked out for you. Same drawer on the screen. A different question asked of you.

Below is the same drawer, authored twice. On the left it is three declarations. On the right it is two states and a trigger — how Framer says it, and how every tool of this shape says it. Open both, move it to a different edge, then press show me.

The unit of the decision

Two dashed rows on the left, five on the right. That asymmetry is the entire difference between the two models, and it is worth being precise about what it is not. It is not that the right-hand side is sloppy: it produced exactly the same motion, and it produced it from a description a designer can say out loud in a review. The tool has not removed decisions, it has moved the line between the ones you make and the ones it makes for you.

Notice which decisions ended up on which side. Moving the panel from the right edge to the bottom is a two-word change in both models, because that decision is genuinely design-level in both. But the duration crossed over. On the left you had to type a number before anything moved at all; on the right the drawer moved without ever asking, and something chose that number. Every animation has a duration, so if you did not choose one, the question is not whether a default exists but whether you have looked at it.

If you have read 0001: that lesson's argument for ease-out is an argument about a value you were typing. Here the same value arrives pre-typed, which is why the argument matters more rather than less — the tool's default is somebody's answer to that lesson, and you inherit it whether or not you ever read it.

The spring is the sharpest version of this. Ask for one on the right and you hand over stiffness, damping and mass, and you never hand over a duration, because a spring does not have one until it stops moving. The number in the panel is the result — the tool integrated the physics and told you how long that took. A spring is described by how it behaves, not by how long it lasts, and any tool that offers you both is offering you a duration you did not choose.

/* The transition model. Every value in this block is one you typed. */
.details {
  transform: translateX(100%);
  transition: transform 240ms cubic-bezier(0.23, 1, 0.32, 1);
}
.details.open { transform: none; }

/* The state model, written out. There is no such CSS — this is the
   shape of what the panel on the right holds, which is worth seeing
   flattened, because it is what a tool has to fill in before it can
   produce the block above. */
Variant "Shut"  → x: 100%
Variant "Open"  → x: 0
Trigger         → Click → Open
Transition      → Ease            (duration: ?, curve: ?, delay: ?)
                                  (on interrupt: ?, when motion is off: ?)

A default is a decision someone else made about your product

There is a version of this lesson that goes looking for things Framer cannot do, and it is a bad lesson, because the list is short, it is mostly wrong, and it expires. Framer can stagger a data-driven list. It can spring. It can scrub an animation against scroll position. Reaching for "the tool can't" is nearly always a sign that you have not yet found the control.

The durable question is the other one. In any tool that infers an animation, the review question is not "can it do this" but "which of these values did anyone actually choose". That question does not expire when the panel is redesigned, it can be answered by looking, and it is the one that catches real problems — because the failure mode of a good default is not that it looks wrong. It is that it looks fine, in five hundred places, none of which anyone ever examined.

Framer's defaults are good. That is precisely what makes them worth naming out loud: a bad default gets fixed the first time someone sees it, and a good one survives every review a product ever has. Write down which defaults you have adopted on purpose, and the ones you have not adopted become visible. This is the same artifact D013 called a token set. The only difference is that here you are naming decisions that already exist rather than inventing them, and that half of the work is easier, not harder.

If you have read 0009: the reduced-motion row in the panel is the one to check first in any new tool, for the reason that lesson gives — it is a correctness question wearing a preference question's clothes, and it is the row most likely to be filled in silently.

What the panel is called this week

Everything below is Framer's current vocabulary, and some of it will have moved by the time you read it. That is fine, and it is why the panel in the lab above is a stand-in for the model rather than a screenshot of the tool. Learn a tool's model rather than its menu, because the model changes on a scale of years and the menu changes on a scale of releases.

Motion in Framer arrives through the Effects panel, and the effects are sorted by trigger, not by feeling. Appear fires once when a layer arrives — when the page loads, or when the layer or its section comes into view. Scroll Transform is not triggered at all: it maps scroll position continuously onto position, scale, rotation or opacity, From one value To another. Scroll Variant flips a layer into a different state past a threshold. Loop repeats. Alongside them, variants plus a click or hover trigger cover everything a component does under a pointer, and Stagger rides on the transition of an Appear effect, which is how a list arrives one row at a time whether the rows are drawn by hand or come out of the CMS.

That sorting is the one structural thing to internalise, and it explains why two effects that look nearly identical on a page live in different places. An effects panel is organised by trigger rather than by feeling, so naming the trigger is how you find the control. The drill below is that, six times.

Where the canvas stops

The last specimen is the seam. A toast that appears when a save fails is not hard motion — it is a panel sliding up from an edge, which is the first thing anyone learns to build. What has no home on the canvas is the because. A canvas can see clicks, hovers, viewport positions and page loads, and a failed request is none of those.

That is the real shape of the boundary, and it is worth stating as a rule, because it predicts the cases you have not met yet. What runs out first in a design tool is triggers, not motion. Anything driven by something the page knows and the canvas does not — a request that failed, a value that crossed a threshold, a message that arrived, a list that reordered itself — needs a hand back to code, no matter how simple the movement is.

In Framer that hand-back is a code override, a small React function you attach to a layer, or a code component, which is a layer you wrote outright. Both give you the full Motion for React API — the library Framer itself is built on. This matters more than it sounds: the vocabulary does not change when you cross into code, only the spelling does. Variants stay variants. Transitions stay ease or spring, with the same three spring numbers. Stagger stays a property of a transition. You are not leaving the model you have been using; you are writing it down.

If you have read 0006: this is that lesson's tool-choice argument arriving from the other direction. There the question was when a library earns its bytes over plain CSS. Here it is when a canvas hands back to a library, and the answer has the same shape — you cross when the thing you need to express is not in the current vocabulary, not when the current vocabulary is merely inconvenient.

Three questions to ask any tool

Framer is one instance of a shape: a canvas that infers animations from states. Rive does it, Play does it, whatever ships next year will do it, and Figma's prototyping panel is a smaller version of the same idea. These three questions work on all of them, and they take about twenty minutes to answer in a tool you have never opened.

One: what is the unit of the decision here? Ask what the smallest thing is that you are asked to specify. If it is a property and a number, you are in the transition model. If it is a pair of states, you are in this one. Find the unit of the decision first, because every other question you have about a tool is downstream of it.

Two: what does it infer, and from what? Build one small thing and then hunt for every value you did not type — duration, curve, delay, what happens when the animation is interrupted halfway, what happens when the reader has motion turned off. Build the smallest possible thing in a new tool and then list what moved that you did not tell it to move. That list is the tool's opinion about your product, and it is twenty minutes to find and it lasts as long as you use the tool.

Three: where does it hand back to code? Every one of these tools has a seam, and the seam is where the triggers run out. Find it early, on purpose, while you are still choosing whether to build something here — a tool's escape hatch tells you more about its ceiling than its feature list does. A tool with a good hatch has a ceiling you can work under. A tool with no hatch has a ceiling you will discover in week three of a project.

The same ideas, in the two vocabularies

Now that you have felt both, here is the translation, and the lesson that argues each one. The right-hand column is the point, and it is the reason this table is at the end rather than the start: a design decision exists whether or not the tool has a control for it.

What you have now

You can open Framer, or something like it, and be useful in it on the first afternoon — not because you know where the controls are, but because you know what the controls are for, which is the part that takes months to acquire by clicking. Every noun in the design track has a home in that panel, and the six specimens above were the drill for finding it.

The one habit worth carrying out of here: the first thing to do in a new tool is find out what it decided for you, not what it lets you decide. The second list is on the marketing page. The first one is the one that ships.

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.

0014 · Reading a Performance recording

Skill: find a long frame, follow its pipeline, and choose a mechanism-led fix.

• A recording is evidence, not a score. Start with a long frame, then inspect the work nested inside it.
• Layout recalculates geometry; Paint fills pixels; Composite assembles painted layers.
• Say what changed, how much changed, and which stage paid before proposing a remedy.
• Repeat recordings across cold/warm cache and the slowest part of the gesture; machine and viewport change the numbers.

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.

D009 · Loading, waiting, and optimism

Skill: pick a waiting treatment from the length of the wait, and defend it.

• Two facts decide the treatment: how long the wait is, and whether the length is knowable. Everything else is taste.
• A determinate indicator is a checkable promise. Don't make one you can't keep.
• A skeleton promises the shape of what's coming, so it lies on an empty state.
• Delay the loader past the common case, or most readers get a flash of loading that reads as a glitch.
• Optimism is a bet on the failure being cheap, reversible, and visible where the reader is still standing.

D010 · Navigation and page transitions

Skill: choose a transition model from the relationship between two screens, and make the way back mean something.

• Four models, four claims: cut says nothing, cross-fade says different, push says direction, shared element says this one.
• Back is not forward. One code path means one animation unless someone insists; press back and describe what you were told.
• Orientation is bought by what doesn't take part. Persistent chrome is layout, not motion, so it survives everything.
• Ask what the smallest region that has to change is. Most navigations change less than the implementation does.
• Cold entry test: load the destination with no history. Anything the transition was the only source of has gone.

D011 · The motion budget

Skill: answer "should this animate?" with a reason, and price an animation by how often it plays.

• The right amount of motion is the size of the event. Eight animations for a one-figure change is a lie in one direction; one animation for an eight-panel change is a lie in the other.
• Count three things, not one: signal is motion on something that changed, noise is motion on something that did not, and the third is the change that happened with no motion at all.
• Busy and expensive are different failures. Busy is more claims than the event deserved, at any duration — it needs subtraction. Expensive is one animation costing more than what it says is worth — it needs a lower price.
• Price an animation as its length times how often it plays. A duration cannot be judged without the frequency, and the arithmetic turns taste into evidence.
• Idle motion has no event behind it, so it is a standing charge: the only justification is naming what would be untrue if it stopped.
• A principled no is a no with a question in it — what does this tell the reader that the layout does not, how many times a day does it play, what else claims attention in the same second, and what happens to the screen when it does not play at all.

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.

D09 · Four waits

Lesson D009 — Loading, waiting, and optimism · nothing, spinner, skeleton and progress on one clock

Reach for it when someone says “use a skeleton, not a spinner”. Set the latency to the number your endpoint actually returns in, and the ranking rearranges itself — which is why the rule isn’t one.

D09 · Save it twice

Lesson D009 — Loading, waiting, and optimism · an optimistic save beside a confirmed one, failing at a rate you set

Reach for it before agreeing to an optimistic update. Turn the failure rate up until the rollback stops being theoretical, and decide whether you would still ship it.

D10 · Four models

Lesson D010 — Navigation and page transitions · cut, cross-fade, push and shared element on one tap

Reach for it when a navigation needs a transition and nobody can say which. Say what each of the four claims, then set back to repeats forward and watch two of them lie.

D10 · What stays put

Lesson D010 — Navigation and page transitions · a full swap beside one that keeps its chrome, same fade both sides

Reach for it when a page change feels unsettled and the instinct is to improve the animation. Both panes run the same fade; the measured share that held still is the whole difference.

D11 · Eight places it could show

Lesson D011 — The motion budget · one dashboard refresh, and the count of what moved for it

Reach for it when a screen is called busy and nobody can say what to cut. Set the event first, then the budget, and read the three counts — the noise is the argument, and the silent changes are the one nobody makes.

D11 · The same duration, twice

Lesson D011 — The motion budget · one panel seen once beside the same panel seen all day

Reach for it when a duration is being defended in the abstract. Both panes run the same length; the frequency is what decides whether it is generous or a tax.

D12 · Ten specimens, one flaw each

Lesson D012 — The critique drill · ten before/afters with the verdict withheld until you commit

Reach for it when you can feel that something is wrong and cannot yet say what. Watch, name the flaw in one word, then reveal — the gap between your word and the given one is the drill.

D13 · One set, five components

Lesson D013 — Motion in a design system · three durations and a curve, dressing five components at once

Reach for it when a token set is being named. Switch to value naming and retune anything: the stage does not change, the names start lying, and nothing anywhere reports it.

D13 · What the spec can say, and what it cannot

Lesson D013 — Motion in a design system · one spec built twice, and the fields that never make it across

Reach for it before a handoff. Run each specimen, then read the sheet beside it for the rows marked code decides — those are the sentences your spec still owes someone.

D14 · The same drawer, said twice

Lesson D014 — Doing all of this in Framer · one drawer as three declarations and as two states, side by side

Reach for it on the first day in an unfamiliar tool. Press show me and read the dashed rows: that list is the tool's opinion about your product, and it is the thing to go and check.

D14 · Which control builds this?

Lesson D014 — Doing all of this in Framer · six specimens, and the Framer control that builds each one

Reach for it when a build starts and nobody has named the trigger yet. Specimens two and three share one scroller on purpose — a mapping and a threshold, told apart by watching.

Ref 06 · The composer

Reference 06 — The Composer · build a sequence a moment at a time and read it back

Reach for it when you have a sequence in your head and no words for it. It is the only lab here with no fixed experiment: you compose, and it names what you built.

0014 · Read a recording

Lesson 0014 — Reading a Performance recording · find the long frame, then name the pipeline stage

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.

This sheet has no argument in it. Pick an object, pick a moment, switch words on and off, and the code and the result keep up. The question it exists to answer is what does that change look like — when you tune a number yourself, when you take the fade out, when you put it back.

How to drive it

1. Button and Drawer are the objects. Switching object is a reset — a button's composition means nothing on a drawer — so it starts each one from its own default.
2. The moments are the row underneath. Each holds its own set of words, and the code panel prints all of them at once — the receipt is for the whole object. The last moment in each row (Return, Close) takes no words: it is the way back, and the only thing it owns is its own duration and curve. That is why a drawer can open in 220ms and close in 120ms, and why the code shows exactly where the second number lives.
3. The checkboxes add and remove words. Two words that fight over the same channel (lift and sink both want translate) can't both be on, and the picker says so instead of letting the second one win silently.
4. The code is editable. The words are the coarse path; clicking a value in panel 2 and typing is the exact one. A value the CSS parser would drop is flagged rather than applied, so nothing fails quietly.
5. Play it, Loop, 0.25×, Hold this. Hold this freezes the upper stage so you can make several edits against one fixed reference instead of only the last one.
6. The scrub runs both stages against the same clock, not each against its own duration — otherwise a 120ms and a 400ms version would look identical at every position of the slider, which is the one difference the comparison exists to show.

What the readout says

Duration, how many properties are being animated, how many of the three moments are in use, and the most expensive tier anything on the page touches — compositor, paint, or layout, in the sense Lesson 0002 uses them. It reports. It has no opinion about what it reports; the numbers are there so a judgment is yours to make and not the page's.

What's in it so far

Two objects. The button, with the words that D004 and 0010 put on a control — lift, sink, grow, shrink, fade, darken, lighten, shadow, tint, ring. The drawer, with the words D002 uses for a surface that lives off screen — slide, fade in, scale up, dim, shadow. A drawer's rest state is off screen, so those words write two rules rather than one: where the panel waits and where it arrives. Its stage has a real switch — click Filters, the scrim, or Apply and the printed CSS runs for real, rather than the scrubbed copy of it.

The object list is meant to keep growing across the design track: the card, the deck, the drag, the scroll section, the hero. The parts list lives in one file (assets/compose-catalogue.js), so adding an object is adding data, not adding a page.

Nothing plays on load, and nothing loops unless you switch loop on. An edit does preview itself, because watching the change is the sheet — but if your system asks for reduced motion, that preview is dropped and only Play, Loop and the scrubber move anything, since pressing one of those is the request. Every comparison is still readable standing still. Nothing you do here is saved — reload to reset it.