Transitions, transforms and animations

Introduction

A small movement can tell someone what just happened: a menu slid in from over there, a button responded to your press. Used well, animation makes an interface easier to understand. Used badly, it is slow and irritating and can even make some people feel physically ill.

How it works

Transitions animate between two values when something changes:

.button {
  background: teal;
  transition: background 0.2s ease;
}
.button:hover { background: navy; }

Write the transition on the normal state, as shown, so that it animates both on the way in and on the way out. The four parts are the property, the duration, the easing and an optional delay. Keep interface transitions short, typically between 100 and 300 milliseconds.

Easing describes the speed curve. ease starts fast and slows down, linear is constant, ease-out slows at the end, and it feels natural for things that are entering.

Avoid transition: all: it animates things you did not mean to, and it makes the browser do unnecessary work.

Transforms change how an element is drawn without changing the layout around it, so that neighbours do not move.

Why transform and opacity? A browser builds a frame in stages: calculate layout, paint pixels, then combine layers. Animating width or top repeats the layout work for each frame, which can be slow. transform and opacity can usually be handled in the last stage only, often by the graphics hardware, so they stay smooth. Not everything can be transitioned in the normal way: display jumps straight from one value to another, for example.

Animations run through several named stages by themselves, without needing a change of state:

@keyframes pulse {
  0%, 100% { transform: scale(1); }
  50% { transform: scale(1.1); }
}
.dot { animation: pulse 2s ease-in-out infinite; }

The animation shorthand takes the name, duration, easing, and how many times to repeat. animation-fill-mode: forwards keeps the final state after it ends.

Reduced motion. Large or fast movement can cause dizziness and nausea for people with vestibular conditions, and operating systems have a setting that asks for less. Honouring it is a requirement of accessible design, not a nicety:

@media (prefers-reduced-motion: reduce) {
  * { animation: none !important; transition: none !important; }
}

This is one of the few sensible uses of !important.

Syntax

.card { transition: transform 0.2s ease-out; }
.card:hover { transform: translateY(-4px); }

Example

Move your pointer over the card, or press Tab to reach it.

Line by line

1. The transition is on the normal state of .card.
2. On hover and focus, it moves up and grows slightly.
3. @keyframes pulse describes the stages of the animation.
4. .dot plays those stages for ever.
5. The media query turns all of it off for those who asked for that.

Expected result

The card lifts smoothly when pointed at, and returns smoothly. The teal dot beside it grows and shrinks continuously, unless your device is set to reduce motion.

In the real world

Skeleton screens, loading spinners and page transitions are made with these tools. Performance teams watch closely for animations that cause layout work, since those are what make a phone feel sluggish.

Common mistakes

• Putting the transition on :hover, so that it runs only one way.
• Animating width or top where a transform would work.
• Overusing long animations, which make people wait.
• Ignoring reduced motion.

Best practices

• Keep movements short and purposeful.
• Animate transform and opacity when you can.
• Name the specific properties to transition.
• Test with the reduced motion setting on.

Summary

Transitions animate between states, and transforms move elements without affecting layout. Keyframes describe longer animations. Prefer transform and opacity for smoothness, and always respect prefers-reduced-motion.

Mark lesson complete