22 CSS Transitions

A transition interpolates between a start state and an end state when something changes — a hover, a focus, a checked box, a flipped attribute. It has no timeline of its own, it is reversible by definition, and it is declared with transition-property, transition-duration, transition-timing-function, transition-delay, and transition-behavior. An animation runs a @keyframes timeline that exists independently of state: it can loop, it can hold, and it can pass through as many intermediate frames as you write. The practical decision is usually made by two questions. Does the motion need to loop or pass through more than two states? If yes, you need a keyframe animation, because a transition can only ever describe two endpoints. Does the motion need to reverse cleanly when the user changes their mind halfway through? If yes, you want a transition, because transitions reverse smoothly from whatever the current computed value is, while an interrupted keyframe animation restarts or jumps unless you do extra work. This collection covers transitions; keyframe timelines are covered separately.

Because an unregistered custom property is just a string as far as the engine is concerned, and strings are not interpolable. When you write --angle: 0deg and transition to --angle: 90deg, CSS has no idea that value is an angle rather than arbitrary text, so it applies the change discretely and your transition silently does nothing. Registering the property with @property and a typed syntax descriptor fixes it: once the engine knows --angle is an <angle>, it can compute the values in between. The same mechanism is what makes gradients transitionable. background-image is a discrete property, so a gradient cannot be transitioned directly no matter what duration you set. The workaround is to register the gradient's angle and colour stops as typed custom properties and transition those instead, letting the gradient recompute each frame from the interpolated values. Demo 15 shows the silent no-op beside the working registered version, and demo 06 applies the same idea to gradients.

Historically you could not, and that is why so many fade-out implementations look broken. The moment display: none applies, the element is gone from the box tree, so any opacity transition you declared never gets a chance to run and the element vanishes instantly. The old workaround was to transition visibility alongside opacity with a matching delay, which fades correctly but leaves the element occupying layout and hanging around in the accessibility tree. The modern fix is transition-behavior: allow-discrete, which tells the engine to flip a discrete property at the end of the transition rather than the start. Combined with listing display in your transition property list, the element stays rendered for the duration of the fade and only then leaves the box tree. Pair it with @starting-style if you also want a matching entry transition, since an element being added to the DOM has no previous state to interpolate from. Demo 08 ships the toast that fades correctly next to the one that snaps, and demo 21 covers which properties are discrete and when the flip happens.

Yes, with a caveat about support. Setting interpolate-size: allow-keywords on the root opts the page into interpolating intrinsic size keywords, after which transition: height works against height: auto exactly as you would expect. It is available in Chrome and Firefox from version 129 and has not shipped in Safari yet, so it needs a fallback rather than being used bare. The fallback that works everywhere is the grid technique: wrap the content in a grid whose grid-template-rows transitions from 0fr to 1fr, with the inner element set to min-height: 0 and overflow: hidden. It measures the content correctly at any height and needs no JavaScript. What you should avoid is the max-height hack, where you transition to some arbitrary large value and hope the content is shorter. It clips whenever the content exceeds your guess, and because the transition runs the full distance to that guessed value rather than to the real height, the easing visibly finishes early and the panel appears to stall. Demo 10 shows all three side by side.

It causes three real problems that are easy to miss in development and obvious in production. First, it transitions properties you never intended, including ones changed by a parent or by a state you did not think about, which is where those mysterious half-second layout slides during page load come from. Second, it forces every property to share one duration and one easing curve, so you cannot have a fast colour change alongside a slower transform. Third, it asks the engine to watch every animatable property on that element rather than the two you care about. The fix is simply to list what you mean: transition: transform 240ms ease, opacity 240ms ease. The one place all is defensible is a throwaway prototype where nothing else is changing. Demo 19 builds a component where all produces a visible glitch and the explicit list does not, so you can see the failure rather than take it on faith.

transform and opacity are the cheap ones, because the browser can hand them to the compositor and animate them without recalculating layout or repainting. Anything that changes geometry — width, height, top, left, margin, padding, border-width — triggers layout on every frame, which is why a hover that nudges an element with top can stutter while the same motion via translate stays smooth. Colour properties sit in between: they repaint but do not reflow, which is fine for a handful of elements and expensive across dozens. backdrop-filter is the most expensive commonly-used transition, because it forces a re-composite of everything behind the element on every frame; where you can, transition the opacity of a pre-blurred layer instead. Border width is a special case worth calling out because the fix is so easy — an inset box-shadow ring or an outline with outline-offset both give you a growing border without affecting layout at all. Demos 03, 07 and 17 cover these trade-offs with both sides labelled.

Not with a blanket kill switch. The rule you see everywhere — a universal selector setting transition: none !important under the reduced-motion query — is a blunt instrument that causes two problems. It removes transitions that actively help, like a gentle opacity fade that softens an abrupt content swap, and because it can cut a transition off partway it sometimes strands an element in a half-applied state that no rule then corrects. Reduced motion means reduced vestibular triggers, not the absence of all change. The strategy that holds up is to keep opacity and colour transitions, remove the ones that move things through space — transform, translate, scale — and shorten durations rather than eliminating them, so the interface still acknowledges a state change without sliding across the viewport. Demo 22 puts a component under all three treatments so the difference between the blanket rule and a considered one is visible rather than theoretical.

Three collections sit adjacent and each owns a distinct thing. This one covers the transition property itself — the mechanics of interpolating between two states, the timing functions, the newer primitives like allow-discrete, @starting-style and interpolate-size, and the state machinery that triggers them. css-keyframe-animations owns @keyframes timelines: looping motion, multi-stage choreography, anything that runs independently of state. css-hover-effects owns hover as a design surface — what a button, card or link should look and feel like when pointed at, where the transition is the delivery mechanism rather than the subject. If you are asking which easing curve to use or why your custom property will not interpolate, you are in the right place. If you are asking what a good card hover looks like, the hover collection is the better starting point.

Every demo is framework-agnostic HTML and CSS scoped under a unique .trn-NN root, so nothing leaks into a host page, and 19 of the 22 need no JavaScript at all. The three that do use vanilla ES2024 in under twenty lines each: opening a native dialog, calling document.startViewTransition, and flipping a data attribute. Two things need attention when you port them. Modern features are gated behind @supports with a working fallback declared first, so keep the fallback declaration if you lift the rules into a component library — deleting it is how a demo that degraded gracefully starts failing outright on an older engine. And if your framework scopes styles automatically, check that it has not rewritten the view-transition-name values in demo 12 or the @property registrations in demos 06 and 15, since both are global by specification and a scoping transform can quietly break them. In Astro the pure-CSS demos render as static HTML with no island at all. Tailwind users can lift the rules into @layer components on v3, or declare the same tokens in @theme on v4.