Door 21 – View Transitions API | CSS Adventskalender

Door 21 – View Transitions API

Published: at 07:00 AM

Page transitions and UI transitions were once things that only Single-Page frameworks like React, Vue, or Svelte could do well. Classic server-rendered pages had hard page changes – a flicker, a hard cut, barely any visual feedback. The browser loaded the new page, completely deleted the previous DOM, and built the new one. This abrupt change was technically necessary, but from a UX perspective, it was a noticeable break in the user experience.

The View Transitions API fundamentally changes this. It enables seamless transitions between pages, components, and UI states – natively in the browser, without frameworks, without hacks, without history manipulation. The browser takes over the entire orchestration of the transition, automatically creates screenshots of the involved states, and interpolates between them. The result is a smooth, high-quality animation that feels like a native app.

This is a major step toward high-quality, smooth web UX, especially for MPA architectures (Multi-Page Applications), content sites, and hybrid frameworks like Astro, Next.js, or Remix. Websites can now leverage the performance benefits of server rendering without giving up the visual advantages of Single-Page architectures. The API closes a gap that the web has had for years.

Why the View Transitions API is So Important

Until recently, the web was locked into two extremes. On one side were Single-Page Applications with their smooth transitions and elegant transitions, but complex in development, heavy in bundle size, and JavaScript-heavy in execution. On the other side were Multi-Page Applications, which were simple to develop, fast to load, and SEO-friendly, but penalized every page change with a hard visual cut. This binary decision forced developers to give up either performance and simplicity or visual feedback.

The View Transitions API resolves this dilemma in a remarkable way. It brings smooth transitions to classic Multi-Page architectures without giving up the benefits of server-side rendering. The JavaScript overhead is minimal, often even optional. No framework is necessary anymore to realize high-quality page transitions. No complex state management for navigation needs to be implemented. No client-side routing with its pitfalls and edge cases needs to be maintained.

The result is a web that becomes technically leaner while simultaneously becoming visually more elegant. Websites can maintain the speed and simplicity of server rendering while offering the fluidity of modern UI frameworks. This is a fundamental paradigm shift that leads the web into a new era where performance and visual quality are no longer opposites but can go hand in hand.

Core Principle: document.startViewTransition()

The core mechanism of the API is surprisingly simple yet powerful. The central function is document.startViewTransition(), which takes a callback in which DOM manipulations are performed:

document.startViewTransition(() => {
  // DOM updates here
});

What happens in this one line is remarkable. The browser automatically creates a screenshot of the current DOM state before the callback is executed. This screenshot is stored as the “old state.” Then the browser executes the callback, in which the DOM is modified – elements can be added, removed, or modified. Once the callback is complete, the browser creates a second screenshot of the new state – the “new state.” These two states are then automatically interpolated, with the browser creating a smooth animation between them.

The decisive advantage: you don’t have to worry about the technical details of the animation. There are no complicated keyframe definitions, no manual timing functions, no coordination between different elements. The browser takes over the entire orchestration and uses optimized, GPU-accelerated rendering pipelines. The result is a smooth, professional-looking transition with minimal code overhead.

CSS can then be used to style and customize the transitions, but even without additional CSS, the API already works and creates a smooth crossfade between the two states.

A practical example illustrates the elegance of the approach:

document.querySelector('button').addEventListener('click', () => {
  document.startViewTransition(() => {
    document.body.classList.toggle('dark-mode');
  });
});

This code implements a theme toggle between light and dark mode. Without the View Transitions API, the theme would switch immediately – the colors would change abruptly, which feels harsh and unpolished. With the API, however, the old state smoothly fades out while the new state fades in. The entire page animates as a unit, making the change comprehensible and visually pleasant. This is high-quality UX feedback with a single line of additional code.

Styling via CSS

The real magic of the View Transitions API lies in its CSS integration. When a view transition is triggered, the browser automatically creates a hierarchy of special pseudo-elements that represent the different states and layers of the transition. These pseudo-elements can be styled with normal CSS, which allows enormous flexibility in designing the transitions.

The two most important pseudo-elements are ::view-transition-old(root) and ::view-transition-new(root). The first represents the screenshot of the old state, the second that of the new state. Both are rendered simultaneously and the browser crossfades between them by default. The root in the parentheses identifies the transition group – by default, there is a root group that encompasses the entire document, but you can also define your own groups for specific elements.

The default animation is already well-tuned, but for precise control, you can customize the properties:

::view-transition-old(root),
::view-transition-new(root) {
  animation-duration: 250ms;
  animation-timing-function: ease-out;
}

By adjusting animation-duration, you can control the speed of the transition. A value of 250ms is a good middle ground – long enough to consciously perceive the movement, but short enough to feel responsive. The ease-out timing ensures that the movement starts quickly and slows down smoothly, which feels more natural than a linear progression.

But you can also get much more creative. The pseudo-elements can be styled arbitrarily, which enables completely different transition effects. A slide effect where the new page slides in from the right is just as possible as a zoom effect or a complex fade pattern. The entire power of CSS animations is available without having to worry about technical orchestration – the browser handles that automatically.

Page Transitions in an MPA (Multi-Page App)

One of the most remarkable developments of the View Transitions API is its integration into classic Multi-Page architectures. In modern browsers, you can activate page transitions today completely without JavaScript – with a single CSS rule:

@view-transition {
  navigation: auto;
}

This single line of CSS fundamentally changes the browser’s behavior. Once this CSS is loaded, the browser automatically activates view transitions for all navigations within the same origin. That means: when a user clicks on an internal link, the browser automatically creates a screenshot of the current page, loads the new page, creates a screenshot of the new page, and animates between both. The entire process runs completely in the browser without JavaScript being involved.

The browser takes over the complete orchestration. It automatically recognizes when a navigation begins, creates the screenshot of the current state, waits until the new page is fully loaded and rendered, creates the screenshot of the new state, and executes the transition. This automation is enormously valuable because it handles all edge cases and race conditions that you would have to consider in a manual implementation.

The default behavior is already high-quality – a smooth crossfade between pages. But for more control, you can customize the transitions. For example, you can choose different timings for fading out and fading in, which suggests a directed forward movement:

::view-transition-old(root) {
  animation: fade-out 150ms ease-in forwards;
}

::view-transition-new(root) {
  animation: fade-in 300ms ease-out forwards;
}

@keyframes fade-out {
  to { opacity: 0; }
}

@keyframes fade-in {
  from { opacity: 0; }
  to { opacity: 1; }
}

This approach lets the old state fade out quickly (150ms) while the new state fades in more slowly (300ms). This creates the impression that the new page “appears” and comes forward, rather than both pages crossfading simultaneously. Such subtle differences in animation have surprisingly large effects on how the navigation feels. A well-tuned page transition makes the page change not only visually more pleasant but also cognitively more comprehensible – the user intuitively understands that they have moved from one page to the next.

UI Transitions Within the Same Page

The View Transitions API is by no means limited to page changes. Its full value also shows in UI state changes within the same page. Whenever the layout changes, when elements are added or removed, or when the visual structure changes, the API can be used to make the transition smooth.

A classic example is switching between different view modes – such as from a grid view to a list view. Without View Transitions, the switch would happen abruptly: the elements would immediately jump to their new positions, which can be disorienting. With the API, however, the browser automatically animates the movement of each individual element from its old position to the new one.

toggleViewButton.addEventListener('click', () => {
  document.startViewTransition(() => {
    container.classList.toggle('list-view');
  });
});

The code is remarkably simple. The entire layout switch is triggered by toggling a CSS class – list-view. The browser automatically recognizes which elements have moved and interpolates their positions. The result is a smooth animation where each item smoothly slides from its grid position to the list position or vice versa.

The CSS only defines the layout states – the View Transitions API automatically handles the animation:

.container {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  gap: 1rem;
}

.list-view {
  display: flex;
  flex-direction: column;
}

The browser automatically calculates how each element must move from its old position (grid) to its new position (list). This automatic choreography is particularly valuable for complex layouts with many elements. Instead of manually defining and synchronizing each individual transition, you delegate the entire work to the browser, which can do this more efficiently and smoothly than any manual implementation.

Animating Shared Elements (Shared Element Transitions)

One of the most powerful features of the View Transitions API is Shared Element Transitions. This pattern is known from native apps, where an element seamlessly “travels” from one screen to the next – such as an image that grows from a thumbnail gallery to full view, or a card that expands from a list to a detail page. Such transitions were previously extremely complicated to implement on the web and required complex JavaScript choreography with precise timing and position calculations.

The View Transitions API makes this pattern trivially simple. You only need to give both elements – the one on the source page and the one on the target page – the same view-transition-name:

On the list view:

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

On the detail page:

.product-detail-image {
  view-transition-name: product-hero;
}

The browser recognizes from the identical name that these two elements logically belong together. It’s important that each view-transition-name is assigned only once per page – for multiple elements on a list, you would need to use dynamic names (e.g., product-${id}). Instead of fading them in and out independently, it seamlessly animates the element from its position and size on the first page to its position and size on the second page. The element literally “morphs” between the two states.

The effect is remarkable. The user doesn’t see two separate elements – one disappearing and one appearing – but a single element that transforms. This creates visual continuity and makes navigation cognitively more comprehensible. You understand intuitively: “The small image I just clicked is the same image that’s now displayed large.” This visual connection significantly reduces cognitive load and makes complex navigation structures much more understandable.

What’s remarkable is the simplicity of implementation. Two lines of CSS are enough to realize a feature that previously would have required dozens of lines of JavaScript and complex timing coordination. This is premium UX with minimal code overhead – a perfect example of how modern browser APIs make complex patterns accessible.

Typical Use Cases from Real Projects

The View Transitions API unfolds its full value in a variety of concrete use cases that constantly come up in modern web projects. The following scenarios show where the API is particularly valuable and how it measurably improves the user experience.

Image Galleries

Image galleries are among the classic use cases for Shared Element Transitions. A user clicks on a thumbnail in a gallery overview and wants to see the image at full size. Without View Transitions, the thumbnail would disappear and the full view would fade in harshly – the visual connection is lost. With the API, however, the image grows seamlessly from its thumbnail position to full-screen view. The user literally sees how the small image unfolds, which makes the navigation intuitively comprehensible. This continuity is not only visually elegant but also significantly reduces cognitive load. You know exactly where you are and how you got there.

Product Lists and E-Commerce

In e-commerce applications, the transition from a product list to the detail page is one of the most frequent navigation steps. With Shared Element Transitions, the product card can smoothly expand from its position in the list to the detail view. The product image morphs seamlessly from its small format in the list to its large representation on the detail page. Additional information like price, description, and ratings fade in elegantly while the image serves as a visual anchor. This type of transition makes navigation not only more beautiful but also more understandable – the user never loses context and can orient themselves more easily in the product catalog.

One of the biggest advantages of the API is the ability to bring high-quality page transitions to classic Multi-Page architectures without having to use a Single-Page framework. Content management systems, blogs, marketing websites, or documentation pages can now offer smooth page changes without accepting the complexity of React, Vue, or similar frameworks. The server still renders each page completely, which brings SEO advantages and improves initial load time. At the same time, the navigation no longer feels static and harsh but smooth and modern. This is a real game-changer for many projects that previously had to choose between performance and visual quality.

Theme Switcher

Switching between light and dark mode is standard in almost every modern application today. Without View Transitions, the switch happens abruptly – all colors change simultaneously, which feels harsh and unpolished. With the API, however, the old theme state smoothly fades out while the new one fades in. The transition typically lasts 150-200ms, which is long enough to consciously perceive the change but short enough to feel responsive. The effect is subtle but noticeable – the interface feels significantly higher quality. This use case particularly well demonstrates how minimal code overhead leads to maximum UX gain.

UIs with Layout Switch

Many modern interfaces offer different view modes – such as switching between grid and list view, between card and detail view, or between different tab panels. Without View Transitions, the elements jump harshly to their new positions. With the API, however, they glide there smoothly, with the browser automatically choreographing the movement of each individual element. When switching from grid to list, you see how the elements rearrange themselves, which makes the transformation comprehensible. With tabs, context is maintained because you see where the new content comes from and where the old one goes. These visual cues make complex interfaces significantly more understandable.

Content-Heavy Sites

On pages with a lot of content – such as news portals, documentation, or blogs – smooth page transitions significantly improve orientation. Instead of new pages appearing abruptly, there’s a visual flow between pages. This flow enhances the so-called “scent of information” – the intuitive perception that you’re moving through related content. The user loses context less often, knows better where they are in the information architecture, and can orient themselves more easily. This is particularly valuable for complex content structures where navigation is a critical factor for user experience.

Performance & Fallbacks

One of the great strengths of the View Transitions API is its performance characteristics. The API is designed from the ground up to be extremely performant because it’s directly integrated into the browser’s rendering pipeline. The browser internally uses the same highly optimized mechanisms that are also used for CSS animations – compositing-based rendering on the GPU.

This means concretely: the screenshots of the two states are treated as separate layers and kept on the GPU. The interpolation between these layers runs completely GPU-accelerated without the CPU needing to be involved for every frame. The result is smooth 60fps animations, even on mobile devices with weaker processors. The entire orchestration is browser-side optimized – the browser knows the performance characteristics of the hardware and can adjust the animation accordingly.

Another performance advantage is the minimization of reflows and repaints during the transition. Since the browser works with screenshots, the actual DOM doesn’t need to be constantly recalculated during the animation. The transition runs independently of the layout tree, which significantly reduces the load on the main thread.

The fallback mechanism is remarkably elegant. In browsers that don’t yet support the View Transitions API, nothing simply happens. The callback in document.startViewTransition() is still executed, but without animation. The DOM changes as usual, just without the visual transition. There are no errors, no warnings, no visual flickering, or other unwanted side effects. The page functions completely, just without the additional visual elegance.

This is Progressive Enhancement in its purest form. The core functionality – the DOM manipulation – works everywhere. The animation is an additional enhancement that improves the experience but isn’t essential for functionality. You can use the API today without worrying about users with older browsers. They get a working page, just without animations. For users with modern browsers, however, the experience is significantly higher quality – an ideal situation for gradual adoption of new web features.

Limitations and Challenges

Like any new web technology, the View Transitions API also has its limitations and challenges that you should know before using it in production projects.

Browser support has improved significantly in recent months, but there are important differences between the two main variants of the API.

Thanks to the elegant fallback mechanism, however, this is not a showstopper. The callback in document.startViewTransition() is executed even in non-supporting browsers, just without animation. The page functions completely, only the visual refinement is missing. This makes the API a perfect candidate for Progressive Enhancement.

Shared Element Transitions require a well-thought-out structure. The view-transition-name values must be unique, and you must ensure that the elements actually logically belong together. With complex layouts with many nested components, it can quickly become unclear which elements are connected to each other. A clear naming convention and good documentation are essential here. Additionally, Shared Element Transitions only work if both elements, on the source and target pages, exist at the time of the transition. With asynchronously loaded content or dynamically generated elements, you must ensure that the timing is right.

The API is not suitable for extremely dynamic reflows where the entire layout is constantly changing. View Transitions work best when there are clear source and target states. With highly dynamic interfaces that continuously change, such as drag-and-drop operations or real-time collaboration, the API can quickly reach its limits. Here, traditional CSS transitions are often the better choice.

Another important point is the danger of overengineering. The API makes animations so easy that you might be tempted to use them everywhere. But not every state change needs an animation. Too many transitions can make the interface restless and worsen the user experience instead of improving it. Some animations feel “over the top” if you don’t stay sparse. The art lies in using transitions specifically where they provide real added value, such as for large state changes or important navigation steps, and leaving them out for small, frequent interactions.

Despite these limitations, the View Transitions API is an incredibly valuable feature for modern web projects today. The limitations are understandable and manageable and the advantages, such as smooth transitions without framework, minimal code overhead, elegant Progressive Enhancement outweigh in most use cases. With conscious use and good planning, you can use the API to significantly improve the user experience without falling into typical traps.

Example: A Complete Page Fade

To demonstrate the practicality of the API, here’s a complete, production-ready example of an elegant page fade effect. The pattern combines JavaScript for navigation with CSS for styling the transition and shows how minimal code leads to maximum high-quality UX.

For Same-Document Transitions (within the same page), you can use JavaScript. For Cross-Document Transitions (between different pages), the pure CSS solution with @view-transition { navigation: auto; } is more elegant. But for finer control, you can also use JavaScript:

// For Same-Document Transitions
function navigateWithTransition(updateDOM) {
  if (!document.startViewTransition) {
    updateDOM();
    return;
  }
  
  document.startViewTransition(() => updateDOM());
}

// Example: Load dynamic content
loadButton.addEventListener('click', () => {
  navigateWithTransition(() => {
    contentContainer.innerHTML = newContent;
  });
});

This helper function first checks whether the API is available (feature detection). If yes, the transition is used; if no, the DOM change is executed directly. This is the recommended pattern for Progressive Enhancement. The logic is defensively written and works robustly in all browsers.

The CSS then defines the visual behavior of the transition. Both states receive their own animations with different timings:

::view-transition-old(root) {
  animation: fade-out 200ms ease-in forwards;
}

::view-transition-new(root) {
  animation: fade-in 300ms ease-out forwards;
}

@keyframes fade-out {
  to { opacity: 0; }
}

@keyframes fade-in {
  from { opacity: 0; }
  to { opacity: 1; }
}

The result is a complete page fade where the old page fades out quickly (200ms) and the new page fades in smoothly (300ms). The animation lasts 300ms, which is somewhat longer than typical UI transitions, but appropriate for page changes because it signals a larger context switch. The ease timing ensures natural acceleration, and forwards ensures that the animation remains in the end state.

This code is production-ready, extensible, and works robustly across different browsers. In non-supporting browsers, navigation works normally, without transition. In modern browsers, however, you get a high-quality, professional page change with less than 20 lines of code.

Conclusion

The View Transitions API marks a turning point in web development. It solves a problem that the web has had for years: the dichotomy between performant, simple Multi-Page architectures and visually smooth Single-Page Applications. For years, you had to choose. Either you accepted hard page changes and gained simplicity and performance, or you invested in complex SPA frameworks and gained visual elegance at the cost of bundle size, complexity, and maintainability.

The View Transitions API eliminates this dichotomy. It brings high-quality, smooth transitions to classic web architectures without requiring frameworks, without implementing complex state management systems, and without giving up the advantages of server rendering. The browser takes over the entire orchestration of transitions, automatically creates screenshots, interpolates between states, and uses GPU-accelerated rendering pipelines for maximum performance.

The elegance lies in simplicity. With a single line of JavaScript, document.startViewTransition() or even just with CSS, @view-transition { navigation: auto; } you can implement professional page transitions that feel like native apps. Shared Element Transitions, which previously required complex JavaScript choreography, are now possible with two lines of CSS. Theme switchers, layout switches, image galleries all these patterns are dramatically simplified.

At the same time, the API is robust and future-proof. The fallback mechanism is elegant. Old browsers simply execute DOM changes without animation, without errors or visual problems. This is Progressive Enhancement in its purest form. You can use the API today and modern users benefit from a significantly higher-quality experience while users of older browsers get a fully functional page.

The performance characteristics are excellent. Since the API is directly integrated into the browser’s rendering pipeline and uses GPU-accelerated compositing, the transitions are smooth and resource-efficient. There are no noticeable performance losses, even on mobile devices. The entire animation runs outside the main thread, which means it doesn’t affect the page’s interactivity.

For modern web projects, the View Transitions API is one of the most exciting and valuable developments in recent years. It democratizes high-quality UI animations and makes them accessible to every developer, regardless of whether you work with complex frameworks or with classic HTML and CSS. The web is thus not only becoming visually more elegant but also technically simpler. And that’s perhaps the best part: you have to write less code, manage less complexity, and still get a better result. This is the kind of web evolution you want.

☕ Buy me a coffee

If you enjoy my articles and they help you in your work, I would appreciate a "coffee" and a few kind words from you.

Buy me a coffee
Previous Post
Door 22 – CSS Houdini
Next Post
Door 20 – Animation Performance

Comments