The Shared Element Transition API is FLIPping Cool

I’ve been eyeing up the The Shared Element Transition API 👀 because it looks tremendously cool. With it, you can animate individual elements across different pages even when the browser does an entirely fresh page load. Sweet. I suppose I should say “MPA” (Multi-Page App), but ughgkh it feels weird to give such a fancy acronym to just “the normal way websites work”.

With just a little reading and playing, I’m a fan because:

• The JavaScript API is fairly simple and straightforward.
• You can control the animations in CSS or JavaScript.
• This is the ticket to really nice page transitions which is something “native” mobile apps do especially well and are fairly hard to do on the web, especially without buying into a framework.

There is a ton to know about this API that is beyond me, but I did have a looksie at one specific thing that caught my eye: the page doesn’t actually have to change to use this API. I’m following in Miriam Suzanne’s footsteps here as she did the same in the article Every Transition is a Page Transition? It’s just some extra bonus points for this API. She explains:

Shared-element transitions are designed to work with standard web navigation across multiple page loads, as well as page transitions in ‘single-page’ apps (often called SPAs). While many SPAs have similar features built-in, a web platform approach requires less code, and will result in better, more consistent performance. In either case, the stated goal is to help with transitions from one ‘page’ to the next – but SPAs (by definition) recreate the effect of a page-load without ever leaving the page. We might update the URL and replace the entire contents of the page, but from a browser perspective there is no change from one document to another.

Since SPA transitions are supported, and SPA navigation happens entirely in-page, a ‘page’ in this case is just any given state of the document. We can capture the state of things at one moment, define that as the starting page, make any changes we want, and define the results as our ending page – then animate between them.

Look how simple the core API is:

const transition = document.createDocumentTransition();
transition.start(() => {

  // Update the DOM 

  // Change classes or attributes which then new CSS applies!
  // Move/animate stuff with JavaScript!
  // Add/remove/edit whatever in the DOM!
  // Whatever! 

});Code language: JavaScript (javascript)

And, low and behold, things in the DOM will animate to their new position. Or do a fade-out / fade-in thing by default if it’s not just a position/size change.

That “animate to their new position” thing is ✨ magic ✨. That’s what FLIP animations are! Except now we don’t need to do all that logic ourselves of saving information about the current state of the DOM and animating the difference. The browser can do all that for us.

The Greensock library has a FLIP plugin. Here’s me playing with that to animate a very simple image gallery thing:

Conceptually, its:

• Save the current state of things
• Make DOM changes
• FLIP (animate)

That’s basically the same thing essentially as the shared elements transition API!

So here’s me than attempting to get the new API to work for the exact same use case:

It works?! Amazing.

Here’s a video if you don’t use Chrome or can’t be bothered to turn on a flag: