A view transition can animate a change between two document states, but navigation still owns URL, history, data loading, focus, and scroll. For a same-document change, the update callback changes the DOM; skipping the animation does not skip that update. A cross-document transition has different opt-in and support rules. Duplicate named elements or interrupted transitions may skip animation, so a correct route cannot rely on the effect. The key design question is what a person needs to read and operate after the new view appears.
View Transition Navigation, Focus, and Fallback
Working case
Reviewer 29 opens case 62 from a list. The card’s title appears to continue into the detail heading. The router loads case 62, changes the URL, and renders the heading even when the browser lacks view-transition support. On completion, focus moves to a useful heading or the page’s main region according to the navigation pattern; back navigation restores list context. Reviewer 29 opens a second case before the first effect ends. The earlier data response is discarded and the newest URL and heading win. The visible animation never delays an error page or permission denial.
Implementation boundary
function shouldAnimateRoute(supported, reducedMotion, routeReady) {
return supported && !reducedMotion && routeReady;
}
console.log(shouldAnimateRoute(true, true, true));
// Output: falseKeep route transitions behind a feature check and a reduced-motion branch. Perform the navigation update in both branches; do not place a required state change in a finished callback. Use stable, unique transition names only for elements that correspond across old and new views. Move focus and announce the new view after DOM update, not after decorative animation. Coordinate scroll restoration with the router and browser history rather than overriding every back action. Handle a rejected or skipped transition as a visual fallback. Test a slow data request and a permission failure.
Cost and boundaries
Snapshotting old and new views consumes memory proportional to captured surfaces; large images and full-page effects can increase paint and composition work. A transition can make loading appear smoother, but it does not reduce fetch or render latency. Compare route completion, input delay, and memory on target devices, especially when a case page has a large image. Avoid making every nested state update a full-page snapshot. Support and behavior vary by browser feature, so maintain a plain route path.
Failure trace
A developer waits for finished to update the URL; when the animation is skipped, history remains on the list while the detail is visible. Another page gives two cards the same transition name, causing the effect to skip or capture the wrong item. Test unsupported browser, duplicate names, reduced-motion mode, rapid two-link navigation, back/forward history, stale fetch response, an authorization error, and a screen reader’s focus position. Confirm the resulting document remains coherent without snapshots.
Verification
- URL and content update without the API.
- Focus and history follow the route, not animation completion.
- A stale request cannot replace the newest destination.
Practice drill
Open a case from the queue to case 62 with the feature available, then disable it and repeat. In both runs, inspect URL, heading, focus, and back behavior. Assign duplicate names deliberately and verify the plain route still works. Delay case 62 while selecting case 47; only case 47 may render. Measure snapshot memory on a page with one large scan and decide whether the effect should be limited to a smaller element.
Decision note
Make route state and focus correct first; animate only the visual continuity that survives fallback.
Common Mistakes
- Committing route state in a finish callback.
- Reusing a transition name on simultaneous elements.
- Assuming a visual snapshot fixes navigation focus.
Connected lessons
Build Project: case board motion and route continuity and review Web Development: motion and regional state decisions quiz; follow Motion and View Change Contracts; CSS Motion State and Interruption; Web Animations Lifecycle and Cancellation; Reduced Motion and Rendering Budget; Navigation, History, and Page Lifecycle; Back-Forward Cache and Restored State.
