Browser CSS Page Transitions API aka Shared Element Transitions

Episode Summary

Executive Summary: The episode explores the browser Page Transitions / shared element transitions proposal, a standard aimed at bringing native-app-style page and element animations to the web with far less JavaScript. Scott and Wes explain why the feature matters, how it could simplify common UI transitions, what APIs and events it may expose, and why they’re excited despite its experimental status in Chrome behind a flag.

Main Topics: Why web page transitions matter: The hosts contrast the web’s current limitations with native apps’ smooth navigation animations, arguing that browser-level support could close the UX gap without custom framework code or third-party animation libraries. Types of transitions the proposal targets: They break down root transitions, shared element-to-route transitions, shared element transitions, and entry/exit animations, showing that the API is intended to support much more than simple fades. Current implementation burden in JavaScript frameworks: The discussion highlights how developers currently rely on frameworks and libraries like Framer Motion, React Spring, React Transition Group, or built-in Svelte tooling to create these effects, often with complex state management and performance tradeoffs. Proposed API surface and events: The episode walks through the proposed document transition workflow, including page show/hide events, document.createTransition, transition.start, and page-transition-tag styling to coordinate old/new DOM states and animations. Browser-level standardization and performance: A major argument is that shifting this capability into the browser standardizes behavior across frameworks and should be more performant than JS-driven transitions because the browser can manage painting and state changes directly. Historical context and prior examples: The hosts mention older demos from Sarah Drasner, pre-Chromium Edge’s proprietary approach using meta tags, and Chris Coyier’s writing, illustrating that this idea has been explored for years before reaching the current proposal stage. Experimental availability and future outlook: They note that the feature is currently available in Chrome/Canary behind a flag, making it useful for experimentation and learning, but not yet ready for production use.

Key Arguments: Browser-native page transitions can provide native-app-like UX on the web without forcing developers to hand-roll animations in JavaScript. The proposal is broader than simple page fades; it aims to support full-route transitions, shared element morphing, and entry/exit effects. Framework-based solutions already exist, but they require extra code, duplicated state handling, and can be less performant than browser-managed transitions. A standardized API would let frameworks and libraries build on a common foundation rather than inventing their own transition systems. The browser can better coordinate old/new DOM states and animation timing than app code, reducing complexity for developers. This feature has been anticipated for years, and its emergence reflects a long-standing need for better navigation animation on the web.

Data Points: Chrome availability: Behind a flag in Chrome and Chrome Canary - Listeners can enable the document transition API via the Chrome flags page to try demos experimentally. Example timing: 6 minutes and 23 seconds - Scott jokingly says Prismic can get you up and running with its API in this amount of time. LogRocket free trial: 14 days - The sponsor offer mentioned for LogRocket. Pre-Chromium Edge transition duration: 0.6 - Referenced from the old Edge proprietary page transitions meta tag example. Tweet date referenced: 2018 - The hosts mention a tweet reply on Sarah Drasner’s demo from 2018. Blog post date referenced: April 27th, 2021 - Chris Coyier’s post on page transitions is cited as an early public reference.

Pivotal Quotes: "the browser page transitions API, something that is really going to hopefully bridge the gap between what we expect out of websites and what we can already get with native apps" — Scott Tolinski: Introduces the core motivation for the episode and the feature’s value proposition. "it's a persistent UI that morphs into a full page content" — Wes Bos: Describing shared element-to-route transitions, using the card-to-detail-page pattern as an example. "Can you imagine doing page transitions in the browser without having JavaScript?" — Wes Bos: Emphasizing the long-term potential of browser-native transitions and the excitement around the proposal.

Implications: If standardized, page transitions could become a core web capability, reducing dependency on animation libraries and making polished navigation easier across frameworks. It may reshape how developers build UX motion on the web.