How would you progressively enhance a multi-page app with the View Transition API?

Question and scenario

The site uses ordinary links between same-origin pages rendered by the server. The goal is a continuous transition where supported, with native navigation everywhere else. A strong answer covers both transition mechanisms, update failures, history navigation, focus, scroll position, and reduced-motion preferences.

What the interviewer is testing

• Can the candidate distinguish same-document updates with document.startViewTransition() from cross-document navigation opted into with @view-transition?
• Do they understand that the API is an enhancement layer rather than a replacement for links, history, or server rendering?
• Can they apply feature detection, failure fallback, and prefers-reduced-motion safely?
• Can they test transition pseudo-elements, focus management, slow devices, and interrupted navigation?

Clarifying questions to ask first

Confirm whether navigation is always same-origin, whether iframes are involved, whether shared-element motion is needed, and whether a client router already exists. Clarify target browsers, duration limits, whether simple fades are sufficient, and what the product should do when users disable motion. Cross-document transitions require both participating documents to opt in and the browser to support the feature; they are not a cross-origin navigation mechanism.

A 30-second answer framework

I would keep native links and server navigation as the baseline, then add transitions progressively. For an in-page update, feature-detect startViewTransition and wrap the DOM update; for a same-origin multi-page navigation, opt both documents into @view-transition. If an update fails, the page must remain usable and the error must be handled by the existing UI. Motion belongs only to transition pseudo-elements, respects reduced-motion preferences, and never owns focus, scroll, or history semantics. I would test unsupported browsers, fallback, back/forward, slow networks, and interrupted navigation.

Step-by-step deep dive

1. Build a non-animated baseline. Links, form submissions, server responses, and error pages must work independently; do not intercept every navigation to imitate an animation.
2. Handle same-document updates. For filtering or local state changes, detect document.startViewTransition. Run the same update function directly when unsupported. If the callback fails, show the existing error state.
3. Handle cross-document navigation. Add @view-transition { navigation: auto; } to same-origin pages so the browser creates the transition during navigation; do not call startViewTransition. Missing opt-in or support falls back to normal navigation.
4. Bound the visual scope. Assign view-transition-name only to elements that have a stable correspondence. Use ::view-transition-old and ::view-transition-new for a short, interruptible fade.
5. Protect accessibility. Disable or shorten motion under @media (prefers-reduced-motion: reduce). After navigation, place focus on the new page's main heading or another deliberate target; screenshots must not carry semantic state.
6. Handle runtime states. Back, forward, refresh, network failure, repeated clicks, and leaving the page need normal outcomes. A transition changes visual timing, not URL, cache, permission, or submission semantics.

High-quality sample answer

I would separate a native-navigation baseline from an optional animation layer. For same-document updates, every browser calls one update function; supporting browsers invoke document.startViewTransition(update), while others call update directly. For server-rendered multi-page navigation, same-origin pages include @view-transition { navigation: auto; }; links stay real and cross-origin support is not assumed.

The animation layer provides visual continuity only. Stable view-transition-name values identify matching elements, a short fade is the default, and reduced-motion preferences disable it. The new document still handles focus, scroll, and errors through its normal response. Tests cover missing support, callback errors, back/forward, repeated clicks, slow CPU, slow network, tab switching, and reduced motion. Primary references are the MDN View Transition API and startViewTransition documentation, plus Chrome for Developers' cross-document guide.

Common mistakes

• Calling startViewTransition for a cross-document navigation; it is for same-document updates, while navigation plus CSS opt-in starts the cross-document case.
• Blocking every link with script, degrading keyboard use, copied links, back navigation, and no-script access.
• Assuming identical support across browsers or iframes without feature detection and native fallback.
• Giving many elements duplicate names or making the animation long enough to cause snapshot conflicts and disorientation.
• Testing only forward clicks and ignoring failed responses, back/forward, reduced motion, and interrupted transitions.

Follow-up questions and responses

What if the same-document update callback fails?

Keep the DOM update and error state as independently executable functions. Catching a ViewTransition exception is for logging and settling visual state; the business error still uses the existing UI, and an animation exception must not block the data update.

How do you prove cross-document transitions did not change navigation semantics?

In supporting and non-supporting browsers, check the URL, history stack, refresh, copied-link entry, keyboard operation, focus target, and server error page. With CSS transitions disabled, the page result should be identical.

When should shared-element motion be avoided?

Use a simple fade or no motion when identity is unstable, lists reorder frequently, content has intense movement, or users need immediate state location. Preserve native behavior when visual gain does not justify focus, performance, and comprehension costs.