Skip to content
tezvyn:

View Transitions API: Animate Between DOM States

Source: developer.mozilla.orgHardHow cards are made

View Transitions API: Animate Between DOM States

The View Transitions API lets the browser handle complex animations between page states. It simplifies transitions in Single-Page Apps and, for the first time, enables them for Multi-Page Apps. The main footgun is forgetting it's a progressive enhancement.

Why it exists

Animating changes between application views has always been difficult. It required significant JavaScript and CSS to manage the old and new content, prevent user interaction bugs, and handle accessibility issues like focus loss. For traditional multi-page websites, smooth cross-page transitions were simply impossible.

The mental model

Think of the View Transitions API as telling the browser: "I'm about to change the DOM; please figure out how to animate it smoothly." The browser takes a snapshot of the page's current state, lets you make your DOM changes, takes a snapshot of the new state, and then animates between the two. It handles all the tricky parts of layering and timing.

How it works

For a Single-Page App (SPA), you wrap your DOM-updating code in a document.startViewTransition() call. The browser captures the 'before' state, executes your code to update the DOM, captures the 'after' state, and then generates a tree of pseudo-elements to perform a default cross-fade animation. You can customize this animation using standard CSS properties on these pseudo-elements. For Multi-Page Apps (MPAs), the process is similar but triggered automatically during navigation, if opted in.

When to use it

Use this API to create meaningful transitions that guide the user and reduce perceived latency. It's perfect for animating an element from a list view as it morphs into a detail view, smoothly switching between tabs, or creating seamless navigations between pages in an MPA. This helps users stay in context as the UI changes.

When not to use it

Avoid using view transitions for purely decorative animations that don't clarify a state change, as they can be distracting. Most importantly, do not build application logic that depends on the transition completing. It is a progressive enhancement; your application must function perfectly in browsers that don't support it, where the state change will simply happen instantly.

One canonical example

In an SPA, to animate a content swap, you simply wrap the update function: document.startViewTransition(() => { contentElement.innerHTML = newContent; });. The browser handles the fade between the old and new content. To animate a specific element between two pages (a 'shared element' transition), you give it the same unique view-transition-name CSS property in both the start and end states.

Interview question

When integrating the View Transitions API, what is a crucial architectural principle to uphold?

  • a.It is only applicable for animating state changes within a Single-Page Application (SPA).
  • b.The application must remain fully functional even if the API is not supported by the browser.Correct
  • c.The API should be used exclusively for purely decorative animations to add visual flair.
  • d.All application logic must be tightly coupled with the transition's lifecycle.
Why?

The card emphasizes that the View Transitions API is a progressive enhancement, meaning the application must function perfectly without it. Therefore, application logic should not depend on the transition's completion. Option D is incorrect because the card warns against building application logic that depends on the transition completing.

Just read this? Test yourself on what you have been reading.

Read the original → developer.mozilla.org

You just looked this up. Could you explain it out loud?

That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.

The iPhone app is on the way

We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.

Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.

Get it on Google PlayiPhone app coming soon

We are hiring for this. Open roles that interview on css — each one lists the topics its interview covers.

See open roles