CSS Transitions

Making a State Change Happen Gradually Instead of Instantly

Without a transition, any CSS property change — a hover state flipping a background color, a class toggle changing an element's opacity — happens instantly, in a single frame. A CSS transition tells the browser to interpolate smoothly between the old value and the new value over a specified duration, instead of snapping directly to the end state.

.button {
  background: #4285f4;
}

.button:hover {
  background: #2f5fc4;   /* snaps immediately on hover, no animation at all */
}

.button {
  background: #4285f4;
  transition-property: background;
  transition-duration: 200ms;
}

.button:hover {
  background: #2f5fc4;   /* now fades smoothly over 200ms instead of snapping */
}

transition-property names which CSS property (or properties) should animate when they change. transition-duration sets how long that animation takes. Both are declared on the element's base state, not on the :hover (or other) state that triggers the change — the transition is a standing instruction that applies whenever the property's value changes for any reason, not just specifically on hover.

Transitioning multiple properties at once

transition-property accepts a comma-separated list, or the keyword all, to watch every animatable property on the element at once.

/* Explicit — animates exactly these two properties */
.card {
  transition-property: transform, box-shadow;
  transition-duration: 200ms;
}

/* all — animates every property that changes, whatever it is */
.card {
  transition-property: all;
  transition-duration: 200ms;
}

Easing — Controlling How the Animation Feels, Not Just How Long It Takes

transition-duration controls how long an animation takes; it says nothing about the rate it moves at during that time. transition-timing-function controls that rate — whether the motion starts slow and speeds up, starts fast and eases out, or moves at a perfectly constant speed throughout. This single property is responsible for a huge amount of how "polished" or "cheap" an interface feels, independent of everything else about it.

.el { transition-timing-function: linear; }       /* constant speed, no easing at all */
.el { transition-timing-function: ease; }          /* the default — slow start, fast middle, slow end */
.el { transition-timing-function: ease-in; }        /* slow start, then accelerates — never eases out */
.el { transition-timing-function: ease-out; }       /* starts fast, decelerates into the end state */
.el { transition-timing-function: ease-in-out; }    /* slow start AND slow end, faster in the middle */

linear almost always feels mechanical and slightly wrong for UI motion — real physical objects do not start and stop moving instantaneously, they accelerate and decelerate. ease-out is generally the most natural choice for anything entering or appearing on screen (it arrives with some initial speed and settles gently), while ease-in suits things leaving the screen (they build up speed as they exit).

cubic-bezier() — full manual control over the curve

Every keyword above is actually shorthand for a specific cubic-bezier() curve under the hood. Writing cubic-bezier() directly gives full control over the exact shape of the easing curve, defined by two control points.

.button {
  transition-timing-function: cubic-bezier(0.34, 1.56, 0.64, 1);
  /* A curve that slightly overshoots past 100% before settling back —
     produces a subtle bounce-like snap, popular in modern UI micro-interactions. */
}

steps() — discrete, non-smooth motion

A less common but genuinely useful timing function, steps(n) divides the transition into n discrete jumps instead of a continuous curve — used for effects like a sprite-sheet animation or a deliberately mechanical, "ticking" motion rather than a smooth glide.

.loading-dots {
  transition: background-position 800ms steps(4);
  /* Jumps through 4 distinct positions rather than sliding smoothly between them */
}

Delaying the Start, and Writing All Four Properties at Once

transition-delay adds a pause before the transition begins, after the property change has already happened. It is used less often than duration or timing-function, but has real, specific uses — most commonly staggering multiple elements so they do not all animate in perfect, slightly artificial-looking unison.

.list-item {
  opacity: 0;
  transition: opacity 300ms ease-out;
}

.list-item.is-visible {
  opacity: 1;
}

.list-item:nth-child(1) { transition-delay: 0ms; }
.list-item:nth-child(2) { transition-delay: 60ms; }
.list-item:nth-child(3) { transition-delay: 120ms; }
.list-item:nth-child(4) { transition-delay: 180ms; }
/* Each item fades in slightly after the one before it — a common
   "cascading reveal" pattern for lists and cards entering the viewport. */

The transition shorthand

In real, everyday CSS, all four longhand properties are almost always combined into the single transition shorthand, in a fixed order: property, duration, timing-function, delay.

/* Longhand — four separate declarations */
.card {
  transition-property: transform, box-shadow;
  transition-duration: 200ms;
  transition-timing-function: ease-out;
  transition-delay: 0ms;
}

/* Shorthand — one line, same result */
.card {
  transition: transform 200ms ease-out, box-shadow 200ms ease-out;
}

Notice the shorthand needs the full property duration timing-function group repeated per property when they need different durations or curves — there is no way to "share" a single duration across a comma-separated shorthand list where each property genuinely needs its own timing. If every property shares the same duration and timing function, listing them together under transition-property is cleaner, as shown in Part 01.

.dropdown {
  transition: opacity 150ms ease-out, transform 250ms cubic-bezier(0.34, 1.56, 0.64, 1);
  /* Opacity fades quickly and linearly-ish; the transform gets a longer,
     slightly bouncy curve — two independently tuned animations on one element. */
}

Layout, Paint, and Composite — The Three Stages a Property Change Can Trigger

Not every animatable CSS property costs the same amount of work for the browser to update on every single frame of a transition. To understand why, it helps to know the three broad stages a browser goes through whenever something on the page visually changes.

1. LAYOUT (also called "reflow")
   Recalculates the geometry — size and position — of the changed element
   AND potentially every element affected by that change (siblings, parents,
   anything whose position depends on it).

2. PAINT
   Fills in the actual pixels — colors, shadows, borders, text — for
   every element whose visual appearance changed, onto one or more layers.

3. COMPOSITE
   Combines all the already-painted layers together on the GPU and
   displays the final result on screen.

A property change can trigger all three stages, just paint and composite, or — the cheapest case — composite alone. The fewer stages a change requires, the less work the browser (and critically, the main thread, which is also busy running your JavaScript) has to redo on every single frame of an animation, typically 60 times per second for a smooth 60fps transition.

Properties that trigger layout — the expensive path

width, height
top, left, right, bottom   (when positioned)
margin, padding
font-size
border-width

Changing any of these forces the browser to recompute the geometry of the changed element and potentially cascade that recalculation to surrounding elements too — a sibling that sits below an element growing in height has to be re-measured and repositioned on every single frame, not just once.

Properties that skip layout AND paint — the cheap path

transform   (translate, scale, rotate, skew)
opacity

transform and opacity are the two properties modern browsers can animate using only the composite stage, entirely on the GPU, without touching layout or paint at all. The browser paints the element's pixels onto its own layer once, and every subsequent animation frame is purely a GPU operation — repositioning, scaling, or fading an already-painted layer — which is dramatically cheaper than repainting or re-laying-out the page on every frame.

A Concrete Comparison — Sliding a Card on Hover

The difference between the expensive and cheap paths is easiest to see by building the exact same visual effect twice — a card that lifts slightly and shifts upward when hovered — once using layout-triggering properties, and once using only transform.

.card {
  position: relative;
  top: 0;
  transition: top 200ms ease-out, box-shadow 200ms ease-out;
}

.card:hover {
  top: -6px;
  box-shadow: 0 12px 24px rgba(0, 0, 0, 0.15);
}
/* Every single frame of this 200ms transition forces a layout
   recalculation, because "top" is a positioned offset that affects
   the element's geometry — the browser has to re-measure and
   potentially reposition surrounding content on every frame. */

.card {
  transform: translateY(0);
  transition: transform 200ms ease-out, box-shadow 200ms ease-out;
}

.card:hover {
  transform: translateY(-6px);
  box-shadow: 0 12px 24px rgba(0, 0, 0, 0.15);
}
/* translateY moves the element on the GPU compositor layer alone —
   no layout recalculation on any frame. Visually pixel-identical
   to the "top" version above. */

Both produce the exact same on-screen motion — a 6px upward shift with a growing shadow. The difference is entirely in what the browser has to redo, 60 times a second, to render it. On a single card on a simple page, this difference may be invisible to the eye. On a real production page with dozens of animating cards, list items, or a heavy, complex DOM around the animating element, the layout-triggering version measurably drops frames and starts to visibly stutter, while the transform version keeps running smoothly, because it never leaves the GPU compositor at all.

How to check this yourself, in DevTools

Chrome DevTools' Performance panel, or the dedicated "Rendering" tab's "Paint flashing" and "Layer borders" overlays, make this difference directly visible — layout-triggered animations show up as repeated purple "Layout" blocks in a recorded performance trace, and repainted regions flash green under Paint Flashing on every frame. A transform-only animation shows almost none of either, confirming it is staying entirely on the compositor.

Transitions Are Not Only for :hover

Everything covered so far has used :hover as the trigger, since it is the simplest way to demonstrate a transition — but a transition fires from any change to the watched property's computed value, including one driven entirely by JavaScript toggling a class.

.modal {
  opacity: 0;
  transform: translateY(12px) scale(0.98);
  transition: opacity 200ms ease-out, transform 200ms ease-out;
  pointer-events: none;
}

.modal.is-open {
  opacity: 1;
  transform: translateY(0) scale(1);
  pointer-events: auto;
}

const modal = document.querySelector('.modal')
const openButton = document.querySelector('#open-modal')

openButton.addEventListener('click', () => {
  modal.classList.add('is-open')
})

The CSS has no idea a button was clicked — it only knows opacity and transform changed value, and animates that change exactly the way it would for a hover state. This separation — JavaScript only ever toggles a class or a data attribute, and CSS owns every detail of how that state change actually looks — is the standard, maintainable pattern for JavaScript-driven UI animation, keeping animation timing and easing entirely inside CSS rather than duplicated into JavaScript.

The transitionend event

JavaScript can listen for the exact moment a CSS transition finishes, which matters when something needs to happen only after the animation completes — removing an element from the DOM after it has fully faded out, for example, rather than yanking it away mid-animation.

const toast = document.querySelector('.toast')

function dismissToast() {
  toast.classList.add('is-leaving')   // triggers the CSS transition

  toast.addEventListener('transitionend', () => {
    toast.remove()   // only runs once the fade-out has actually finished
  }, { once: true })
}

A Janky Product Grid at a Chicago E-Commerce Company

.product-card {
  width: 240px;
  transition: width 180ms ease-out, height 180ms ease-out;
}

.product-card:hover {
  width: 252px;
  height: calc(100% + 12px);
  z-index: 2;
}

.product-card {
  transition: transform 180ms ease-out, box-shadow 180ms ease-out;
}

.product-card:hover {
  transform: scale(1.05);
  box-shadow: 0 12px 24px rgba(0, 0, 0, 0.15);
  z-index: 2;
}
/* scale() achieves the same "grows slightly" effect purely on the
   compositor — no width/height change, so no layout recalculation,
   and no effect on any sibling card's position at all. */

Four Misconceptions About CSS Transitions

5 Interview Questions — With Complete Answers

Transition Mistakes Engineers Make Constantly

Rendering Bugs CSS Transitions Produce — And Exactly Why