View Transitions API Gallery — HTML CSS JS Snippet

The shared-element transition — a thumbnail that grows into a detail hero as you navigate — used to require FLIP libraries (Framer Motion's layoutId, GSAP Flip) doing getBoundingClientRect math and transform interpolation by hand. The View Transitions API moved that entire job into the browser: you mutate the DOM inside document.startViewTransition(), tag the elements that should morph with a view-transition-name, and the engine captures before/after snapshots and animates position, size, and border-radius between them. This snippet is a complete, working grid-to-detail gallery built on the native API with a graceful fallback — the demo everyone searches for when they first hear about view transitions.

How the API actually works: snapshot, mutate, animate

Calling document.startViewTransition(callback) does three things. First, the browser screenshots the current page — both the full page and a separate snapshot for every element carrying a view-transition-name. Second, it runs your callback, which synchronously mutates the DOM into the new state (here: hide the grid, unhide the detail view). Third, it builds a pseudo-element tree — ::view-transition-old(name) and ::view-transition-new(name) inside a ::view-transition-group(name) — and animates between the snapshots: unnamed content cross-fades as root, while each named group *morphs*, with the browser interpolating the group's transform and size from the old element's box to the new element's box. The morph you see is not your elements moving; it is the browser animating screenshots of them.

The dynamic-naming trick for grids

The subtlety every real implementation hits: view-transition-name must be *unique in the DOM at snapshot time*. A grid of six thumbnails cannot all be named hero. The solution used here — and in production apps — is dynamic tagging: the name lives in a class (.vt-hero { view-transition-name: hero }) applied to the clicked thumbnail *just before* the transition starts, so the old snapshot captures it; inside the callback the class moves to the detail hero, so the new snapshot captures that instead. One name, two moments, two elements — the browser matches them and morphs. On close, the tagging reverses, and a cleanup timeout strips stray classes after the animation so no future transition ever finds two elements sharing a name (which would cancel the transition with a console error). The title text is tagged the same way with a second name, so the caption morphs alongside the artwork.

Styling the transition from CSS

Because the animation runs on pseudo-elements, you customise it in CSS, not JS: ::view-transition-group(hero) { animation-duration: 0.45s; animation-timing-function: cubic-bezier(0.4,0,0.2,1) } slows the morph enough to read, and ::view-transition-old(root)/::view-transition-new(root) tune the page cross-fade independently. This split is the API's quiet superpower — motion design lives entirely in the stylesheet. The snippet also includes the accessibility requirement most demos skip: a prefers-reduced-motion block that disables all transition animations for users who ask for that.

Progressive enhancement in one function

All API access routes through a five-line withTransition(mutate) helper: if document.startViewTransition exists, wrap the mutation; if not, run the mutation directly and show a support note. The app is fully functional either way — views still switch, clicks still work — which is exactly how this API is meant to be adopted: as pure enhancement. Chrome, Edge, and Safari support same-document view transitions today; the helper means Firefox users simply get instant switches until support lands. The same callback-wrapping pattern scales to SPA routers, and the cross-document variant (@view-transition { navigation: auto }) brings the identical morphs to full page navigations on MPA sites.