View Transitions in Practice

The View Transitions API has been one of the most exciting additions to the web platform in recent years. It lets you animate between DOM states — including full page navigations — with CSS-driven transitions that previously required complex JavaScript frameworks. After using it extensively in my portfolio, here’s what I’ve learned about making it work in production.

The Basic Mechanism

At its core, the API captures a screenshot of the old state, updates the DOM to the new state, then cross-fades between them. You can customize this with CSS pseudo-elements (::view-transition-old and ::view-transition-new) to create directional slides, morphing effects, or shared-element transitions.

Astro’s <ClientRouter /> component hooks into this automatically for page navigations. Every link click triggers a view transition instead of a hard navigation. The default is a simple crossfade, which already feels dramatically better than a white flash between pages.

Shared Element Transitions

The real magic happens when you assign the same view-transition-name to elements on different pages. The browser automatically interpolates position, size, and opacity between the old and new element. This creates the illusion of a persistent object moving through your interface.

I used this for the project showcase modal. When you click “Open” on a project, the cover image smoothly scales and repositions from the grid into the modal. The implementation is surprisingly minimal — you set view-transition-name on the source image just before triggering the transition, apply the same name to the modal image, and the browser handles everything else.

The critical detail is timing. You need to set the transition name on the source element before calling document.startViewTransition(), and clean it up after the transition finishes. If you leave transition names permanently assigned, the browser tries to animate between every page load, which creates jarring effects when elements aren’t semantically related.

Pitfalls and Workarounds

Browser support is the obvious limitation. As of early 2026, Chrome and Edge have full support, Safari has partial support, and Firefox is still behind a flag. Always wrap your transition code in a feature check.

Another subtle issue: view transitions capture the visual state as a flat bitmap. This means scrolling positions, video playback states, and form input values are lost during the transition. If your “old” element is scrolled halfway down, the screenshot will show that scroll position frozen, which can look broken during the animation.

I also discovered that position: fixed elements behave unexpectedly during transitions. The navigation bar, for instance, would jump or flicker because the transition captures it as part of the page snapshot. The fix was to exclude it from the transition using view-transition-name: none or by restructuring the DOM so fixed elements sit outside the transitioning root.

Is It Worth It?

Absolutely, with caveats. For content sites and portfolios where you control the experience, view transitions add a layer of polish that makes the site feel like a native app. The implementation cost is low, the progressive enhancement story is clean since browsers without support simply get normal navigation, and the user experience improvement is tangible.

But don’t force it everywhere. Not every page change needs to be animated. Sometimes a clean cut is better than a smooth transition, especially when the content relationship between pages is weak. Use transitions to reinforce spatial relationships and hierarchy, not just because you can.