Design Principle
Page transitions are not spectacle; they help users understand continuity of the same object across lists, details, filters, and state changes.
Large Theory
Traditional SPA and MPA navigation often removes spatial context abruptly: a list card disappears, a detail page appears, filters rearrange results, or a modal becomes a page. The View Transition API provides browser-level snapshots and animation hooks so visual changes between DOM states or document navigations can be named and choreographed. It does not replace route semantics, focus management, scroll restoration, or accessible fallback. It only expresses an existing state change with more continuity.
Small Points
- Identify the continuity object first: list card to detail hero, thumbnail to large image, tab content change, or filter-result reflow. Do not animate every element randomly.
- Each
view-transition-namemust be stable and unique; dynamic list items need protection from duplicate names and unmount races. - URL, history, back/forward, scroll restoration, and detail return context must still work normally.
- Focus cannot remain in the old DOM; after the transition, move focus to the new page heading, detail main region, or a reasonable interactive object.
- Under
prefers-reduced-motion, use a short crossfade or no transition. Do not use large movement, rotation, or zoom for ordinary navigation. - Check browser support and progressive enhancement; when the API is missing, the page should update immediately.
Design Judgment
A transition is useful when it clarifies that the card users clicked became this detail, or that filtered results reorganized. It becomes friction when users merely wait for a pretty animation before they can continue.
Implementation Notes
Write a transition brief for each route: source element, destination element, state update, URL/history, focus target, scroll behavior, reduced-motion, browser support, and fallback. In Next/React, wrap the real state or navigation update rather than delaying data loading. In CSS, name only continuity elements, keep durations around 150-300ms, and prefer small-scope transitions on complex pages.
Counterexamples/Risks
Crossfading every navigation and reducing orientation, duplicate view-transition-name values causing wrong matches, back navigation losing filters and scroll, focus becoming invisible during transitions, zoom still running under reduced-motion, and playing an empty-shell animation before data arrives.
Case Study
MDN explains that the View Transition API can animate transitions between SPA DOM states and MPA document navigations. web.dev recorded in October 2025 that same-document view transitions became Baseline Newly available and part of the Interop 2025 focus area. The reusable lesson is that this is a progressive-enhancement continuity tool for real navigation state, not a replacement for information architecture.
Source Links
MDN View Transition API: https://developer.mozilla.org/en-US/docs/Web/API/View_Transition_API MDN Using the View Transition API: https://developer.mozilla.org/en-US/docs/Web/API/View_Transition_API/Using web.dev Same-document view transitions Baseline: https://web.dev/blog/same-document-view-transitions-are-now-baseline-newly-available Chrome View Transitions: https://developer.chrome.com/docs/web-platform/view-transitions
Agent Directive
Before implementing View Transition, define the continuity object, URL/history, focus, scroll, and reduced-motion strategy; do not treat route transitions as default site-wide decoration.