Using View Transitions as progressive enhancement

The View Transitions API can connect visual states without a full animation framework, but in early 2024 support remains uneven and the underlying update must work when the API is absent or motion is reduced.

Start with an ordinary state change

Implement navigation, filtering or layout updates using normal links, history and DOM changes first. The transition wrapper should decorate a successful operation, not own data loading, error handling or focus movement.

Name only stable participants

Assign view-transition-name to elements with a meaningful relationship across states. Names must be unique in the rendered document; repeated card components need controlled identifiers and a fallback when an item is added or removed.

Respect motion preferences

Reduce or remove spatial animation under prefers-reduced-motion and keep duration short enough that frequent actions do not feel delayed. Do not animate focus outlines, validation errors or content whose movement hides the result of an action.

Control asynchronous work

Resolve the state needed for the next render before committing the transition, display a non-animated pending state for slow requests and retain errors outside the transition callback. A frozen old view is not a loading indicator.

Test interruption and absence

Exercise rapid repeated actions, browser back, failed fetches and a browser with no API support. Confirm that document title, history, scroll position and keyboard focus remain correct independently of the visual effect.