The transition Shorthand and Multiple Properties
A single-property transition is easy: transition: opacity 200ms ease. Real components change several properties at once — a button's colour, shadow and position; a card's scale, border and opacity — and each usually wants its own timing. The shorthand supports that with comma-separated lists, but the list semantics produce a family of bugs: transitions that vanish in the hover state, the wrong curve applied to the wrong property, transition: all animating a layout change nobody asked for. This page explains how multi-property transitions are actually parsed and combined, and gives patterns that stay correct as a component grows. It belongs to CSS Transition Fundamentals in the CSS-Only Micro-Interactions & Animations guide.
Why multi-property transitions go wrong
The transition shorthand is a list. Each comma-separated item describes one transition: a property, a duration, a timing function, a delay and a behaviour. Behind the shorthand sit five longhands, each also a list — transition-property, transition-duration, transition-timing-function, transition-delay, transition-behavior — and the browser pairs their entries by position.
Two consequences follow. Declaring the shorthand anywhere replaces all five lists at once, so a later rule that declares a single transition silently drops the others. And declaring longhands separately means their lists must line up by index, or durations and curves end up attached to the wrong properties.
The complete implementation
The card below transitions four properties with individual timing. Tokens keep the durations consistent, and the hover rule changes only values, never the transition list.
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Multi-property transitions</title>
<style>
:root {
--fast: 150ms;
--base: 250ms;
--ease-out: cubic-bezier(0.22, 1, 0.36, 1);
}
body { font: 15px/1.5 system-ui, sans-serif; margin: 2rem; }
.card {
display: block;
max-width: 18rem;
padding: 1.25rem;
border: 1px solid #cbd5e1;
border-radius: 12px;
background: #ffffff;
color: inherit;
text-decoration: none;
box-shadow: 0 1px 2px rgb(15 23 42 / 0.08);
/* One list, one place. Each property gets timing that suits it:
colour changes quickly, movement and shadow a little slower. */
transition:
border-color var(--fast) ease,
background-color var(--fast) ease,
translate var(--base) var(--ease-out),
box-shadow var(--base) var(--ease-out);
}
/* The hover and focus states change VALUES only. Because they do not
redeclare transition, the base list applies in both directions. */
.card:hover,
.card:focus-visible {
border-color: #6366f1;
background-color: #f8fafc;
translate: 0 -3px;
box-shadow: 0 12px 28px rgb(15 23 42 / 0.14);
}
.card:focus-visible { outline: 2px solid #4338ca; outline-offset: 3px; }
@media (prefers-reduced-motion: reduce) {
/* Change a longhand only: keep the list, drop movement time. */
.card { transition-duration: var(--fast), var(--fast), 1ms, 1ms; }
.card:hover, .card:focus-visible { translate: none; }
}
</style>
</head>
<body>
<a class="card" href="/guides/grid/">
<h3>Grid guide</h3>
<p>Tracks, areas and subgrid in one place.</p>
</a>
</body>
</html>
The reduced-motion rule demonstrates the safe way to adjust a multi-property transition: override a single longhand with a list of the same length. transition-duration gets four entries matching the four properties, so colour transitions keep their duration while movement and shadow become effectively instant. Redeclaring the shorthand there would have required repeating every property, and forgetting one would silently drop it.
The key technique: declare the list once, vary values elsewhere
The most common multi-property bug comes from redeclaring the shorthand in a state rule. A base rule transitions colour and shadow; a hover rule adds transition: translate 200ms to animate a lift. In the hover state, the list now contains only translate, so colour and shadow changes entering hover snap instantly — and, because the entered state's list applies, they snap when leaving too if the base is re-entered with a different list.
The rule that prevents it: declare the full transition list once, on the base state, and vary only property values in state rules. When a state genuinely needs different timing — the asymmetric entry and exit patterns in Entry vs Exit Easing — redeclare the whole list in that state, never a partial one.
Choosing timing per property
Once each property has its own entry, the question becomes what timing each deserves. A few rules of thumb produce transitions that feel coherent rather than merely simultaneous.
Colour and opacity change fastest. They carry state — "this is hovered", "this is selected" — and the user should perceive the new state almost immediately. 100 to 150 milliseconds with a simple ease is usually right.
Movement and scale take a little longer. Spatial changes need time for the eye to follow, and a strong ease-out makes them feel responsive at the start and soft at the end. 200 to 300 milliseconds suits small lifts and nudges.
Shadows follow movement. A shadow represents elevation, so it should grow in step with the lift that implies it. Give it the same duration and curve as the translate, or the card appears to rise before its shadow catches up.
Borders and outlines can lead. A border change slightly before movement makes the state feel crisp. In practice giving borders the fast colour timing achieves this without needing delays.
Anything that changes layout should not animate. If a state change alters padding, width or font-size, leave those properties out of the list so they switch instantly, and achieve the visual effect with transforms instead. The cost of animating layout is covered in Optimizing CSS Animations for 60fps.
Keeping these timings in tokens, as the example does with --fast and --base, means the whole interface shares one vocabulary of speeds, and a single change adjusts every component consistently. It also makes design review concrete: instead of debating individual millisecond values, reviewers check that each property uses the token that matches its role.
Why not transition: all?
transition: all 250ms is tempting because it cannot forget a property. It fails in the other direction: it animates properties you did not intend.
- Layout properties. A later class that changes
paddingorwidthanimates it, re-running layout every frame and shifting neighbours. - Theme switches. Toggling a theme animates every colour on every element with
all, which is both slow and visually messy, as discussed in Smooth Theme Switching Transitions. - Unrelated state. Focus rings, validation colours and visibility changes all inherit the same timing, including ones that should be instant.
- Future changes. Anyone adding a property to a state rule later gets an animation they did not ask for, and may not notice until it causes a problem.
An explicit list documents intent and keeps the motion scoped. Reviewers can read exactly which properties animate and at what speed, and a search for a property name finds every place it is transitioned, which all makes impossible. When a component genuinely has many animated properties, that is often a sign that some of them could be consolidated — several colour properties driven by one custom property, or several transform functions replaced by the individual translate, scale and rotate properties, each with its own list entry. The small cost of naming properties is repaid the first time someone changes a component's padding in a media query and nothing animates.
Browser support
The transition shorthand with comma-separated lists and all its longhands is supported in every current browser, dating from Chrome 26, Edge 12, Firefox 16 and Safari 9. Custom properties inside transition values, the standalone translate property (Chrome and Edge 104+, Firefox 72+, Safari 14.1+) and transition-behavior (Chrome and Edge 117+, Firefox 129+, Safari 17.4+) extend it without changing the list semantics described here.
FAQ
Why should I avoid transition: all?
It animates every property that changes, including ones you did not intend, such as layout properties changed by a later class or theme, and it makes every future style change on the element animate. That costs performance and produces surprising motion. List the properties you mean.
How do I give each property its own duration?
Use a comma-separated list in the transition shorthand, one item per property: transition: opacity 150ms ease, transform 300ms ease-out. Each item has its own property, duration, timing function and delay.
Why did my hover rule remove the other transitions?
Redeclaring the transition shorthand in a later rule replaces the whole list. If the hover rule declares transition: transform 200ms, any opacity or colour transitions from the base rule are gone in the hover state. Redeclare the full list, or change only a longhand such as transition-duration.
What happens if the longhand lists have different lengths?transition-property decides how many transitions there are. Shorter lists for the other longhands are repeated from the start to match it, and longer lists are truncated. Mismatched lists are a common source of the wrong timing being applied to a property.
Related
- CSS Transition Fundamentals — the parent guide.
- Interrupted and Reversing Transitions — what the list does mid-flight.
- Transition Delay Choreography — using the delay column deliberately.
- Building Responsive Cards With Container Queries — the cards these transitions decorate.
Related articles
More pages in the same section.