The View Transitions API

The plain-language idea

Say a UI updates — a card expands into a detail view, a list item gets removed, a page navigates. Making that change feel smooth instead of an abrupt jump-cut has traditionally meant a manual FLIP technique in JavaScript: measure the element's First position, let the DOM update to its Last position, compute the Invert transform needed to make it visually snap back to where it started, then Play a transition removing that transform — all calculated by hand, on every relevant element, on every update.

The View Transitions API does this at the browser level instead. Calling document.startViewTransition(callback) tells the browser: take a screenshot of the current page state, run the callback (which does the actual DOM update), take a screenshot of the new state, then automatically cross-fade (or, for elements tagged with a view-transition-name, morph) between the two captured states. The browser handles the capture-and-animate mechanics; you just trigger the update inside the callback and optionally name the elements you want tracked individually instead of cross-faded as a flat rectangle.

There are two forms of this: a same-document version (transitioning between two states of one page, well-supported conceptually as a JS-driven API) and a newer cross-document version (transitioning smoothly across a full page navigation, opted into via CSS with @view-transition { navigation: auto; }). The cross-document form is the newer and shakier of the two.

See it in a real thing: a card expanding into a detail view

function openDetail(card) {
  if (!document.startViewTransition) {
    // No support: just do the update, no transition
    renderDetailView(card);
    return;
  }

  document.startViewTransition(() => {
    renderDetailView(card);
  });
}

.card-thumbnail {
  view-transition-name: card-hero;
}

Before state: the browser captures a screenshot of the small thumbnail as it currently sits on the page.

BackNext

Tagging the thumbnail with a unique view-transition-name tells the browser "track this specific element across the update, not just the page as a whole" — so instead of the whole page cross-fading as one flat block, the browser morphs that one element smoothly from its thumbnail size/position to wherever the equivalent element lands in the detail view, while the rest of the page cross-fades normally around it.

What people usually miss

Watch out

• The transition is driven by two screenshots, not a live element animation. The browser captures the before/after states as images and animates between those captures — this is why elements not given a view-transition-name are cross-faded as a flat rectangle, not smoothly repositioned; the browser doesn't know they're "the same thing" without that name telling it so.
• view-transition-name values must be unique on the page at any given moment. Reusing the same name on two simultaneously-rendered elements is treated as an error by the browser and can silently break the transition for that pair.
• The DOM update has to happen inside the callback passed to startViewTransition, not before or after it. The API needs to control exactly when the "before" screenshot is taken and when the update runs, so it can time the "after" screenshot correctly.
• Cross-document view transitions (across a real page navigation) are meaningfully newer and shakier than the same-document, JS-triggered version. Treat the two as separate features with separate support timelines, not one feature with uniform support.
• This is still an emerging feature, not a safe default. Feature-detect with if (document.startViewTransition) and always have the plain, un-animated update path work correctly on its own — the transition should be a visual enhancement layered on top of a change that already works without it.

Why this matters in interviews

"How would you animate a UI element smoothly across a state change without hand-calculating transform math?" tests whether a candidate knows the browser now offers this natively, and whether they reach for feature detection by default rather than assuming universal support for an emerging API.