Animating the Impossible

How best do we achieve smooth UI animations when dealing with DOM changes, responsive layouts, dynamic content and user interaction? Well… we start off by flipping our whole approach upside down. In this session we’ll lift the magicians curtain, take a look at some “impossible” animation challenges, and learn how to approach them using a rather exciting animation technique.

Transcription

[playful music]

[audience applause]

Cassie Evans: Hi. Yeah, so we’ve had so many talks, and they’ve all been just of the toppest quality. That’s not a sentence starting well. But I think the undisputed star of the show so far is definitely Toby.

[audience cheers]

Cassie: Right?

[audience applause]

Cassie: I don’t know how we’re meant to follow Toby, all the speakers. It’s just ridiculous. What a legend.

This is the slide where I awkwardly introduce myself. But lucky for me, Sophie already did that in the opening talk, so this is me and this is my website, which you’ve already seen. And you get to see it again. Aren’t you lucky?

I also got into making stuff for the Web back in the Neo Pets and Myspace days, so I’m kind of determined to keep hold of that sense of creativity and joyfulness despite all the evil social giants trying to drain all the fun out of everything. [Laughter]

That’s the fun, little one.

Luckily for me, it’s quite easy for me to help make the Web more a joyful and more creative place because I’m lucky enough to work for GSAP. Actually, when I last spoke at Beyond Tellerrand in Berlin, I was speaking about GSAP but I didn’t actually work there yet, so this is really exciting to be back again as officially a GSAP person.

I get to teach and help make the tools that enable people to make all sorts of really fun, glorious, joyful, creative stuff on the Internet. It just makes me endlessly happy to be able to exist in this little corner of the Web because it’s kind of been around since the Flash days, and it feels like this kind of last bastion of just silly creativity (outside of all the corporate bootstrap websites). Tailwind websites nowadays. I don’t know. Shh... [Laughter]

I, myself have a soft spot for tinkering around with SVG, so stuff like this little SVG animation, this little wobbly jellyfish guy that I made with SVG filters, this swooshy thing that’s incredibly bad for performance but is undeniably really fun, and sometimes I even get paid to do SVG animation on real websites as well, which is great.

This is Vitaly’s Smart Interface Design Patterns website. The codebase for this was amazing. It was just filled with noodles and munchings.

Yeah, so this is kind of my jam. I really like taking really performant, nice, static sites that are all accessible and lovely already and then just sprinkling on little bits of animation on top of it.

Yeah. Today I’m going to be talking about UI animation instead of SVG. I’ve just shown you all of these fun things, and then I’m like, “Yeah, we’re not covering any of that stuff.” [Laughter]

But I did my last talk on SVG animation, and while animated noodles are really fun, it’s not what most of us are dealing with in our Trello boards every day. I think the things that most front-end developers are going to be coming up against are UI animations, so I’m kind of stepping outside of my box a little bit to do some UI in this talk.

Speaking of boxes, I talked to Marc yesterday or the day before about what Beyond Tellerrand actually meant. For all the English speakers that maybe didn’t know that, it translates roughly as “Look beyond the edge of your plate,” which is a little bit like “think outside of the box,” but I kind of like it more, like food-related is better. [Laughter]

[audience laughter]

Cassie: We’re going to be doing a little bit of beyond the plate.

I really like this saying by the author Arthur C. Clarke. “The only way of discovering the limits of the possible is to venture a little way past them into the impossible.”

That’s what we’re going to get up to today. We’re going to be exploring the world of UI animation. But we’re also going to be looking at the impossible bits, so venturing out past the possible into the realm of impossible animation challenges.

I’m going to be honest with you. The word “impossible” is doing quite a lot of work here. If it was really a talk with filled with impossible animations, it would be over and I would be like, “Cool. Thank you very much for having me.”

It would be quite a short talk. So, by “impossible,” I actually mean animating some really tricky UI stuff involving responsive layouts, DOM restructuring, and different position properties without causing layout reflows. But that title sucks.

[audience laughter]

Cassie: [Laughter] So, we’ve gone with “Animating the Impossible.”

What makes an impossible animation? If we look at how animation works, and we look at traditional animation techniques, a little bit like dina’s amazing opening slides for the conference, or hand-drawn animation by people like the Disney animators, in order to animate between different states, you have to draw individual frames or position individual frames painstakingly. It takes a really long amount of time.

How you space them out will determine how the animation looks. If you’ve got a lot of frames bunched together, it will be faster than if you’ve got them spread out.

This is referred to as inbetweening. It’s basically the stuff that’s in between different points in an animation.

Now, when we animate with code, it’s kind of the same deal but the computer does the hard work for us. We refer to this as tweening in the computer world. Whether we’re using CSS transitions or an animation library like GSAP, we only really need to define the start and the endpoint, and then technology just kind of handles all the rest for us, which is great.

We can specify different easing curves and stuff to have different feelings to the movement. We can do a little bit more work so that we get something that’s a bit more like a bouncy ball, a little bit more realistic.

This is where we start getting into impossibilities. When we’re animating CSS properties, some properties are animatable, which is a bit of a weird word to say. Some properties are animatable and some aren’t.

This is a list on the MDN Web docs of animatable CSS properties. Basically, a CSS property is able to be animated if its value can be made to change over a given amount of time. That basically means that you’ve got to have midway points which have valid syntax. The values over the whole duration of the animation need to be valid for the whole time that the animation is playing.

This is a really common one, right? We’ve got a little height transition. That works because we’ve got 20 pixels.

I’m going to go back...

We’ve got 20 pixels and 260 pixels. All of the pixel values in between are valid.

But when we use a keyword like auto, it doesn’t work. I think this is a really frustrating one that a lot of people bump into.

By frustrating, like, I went and found the issue of the CSS working group that goes back to 2016. [Laughter] You have to keep clicking more, more, more, and everyone is going, “We really need this.” But there’s no transitionary states in between a keyword and a pixel value.

Similarly, you can’t fade between two different background images. A background image, that’s a really common one that we get on the GSAP forums a lot.

People that are new to animation will come along and go, “I want to fade between these two different background images and it’s not working.” It’s because a background image is a binary thing, like a div or an element only have a background image or not have a background image. There’s no background image that’s like, “We want a little bit of this background image and then a little bit of this other background image.” You can’t interpolate between them.

I guess you could do what Michelle was talking about with laying elements over the top of each other with fancy grid tricks. Then you could fade one of them. But you can’t actually animate the background image property itself.

A large part of what we do at GSAP is finding where these impossible animation things are and then working out ways to plug the gaps and make those things possible. If you’re animating stuff in GSAP land, you can say, “Animate to height auto,” and we kind of figure it out for you.

It’s kind of magic, but it’s also not really magic. We’re just grabbing the scroll height. Then we’re animating between two pixel values that you can actually interpolate between that have valid, in-between states.

Yeah, that’s a little magic trick under our belt. My font didn’t load. That’s really sad. We’re just going to pretend that this is a magical font right now.

But anyway, that’s a little magic trick under our belt. But UI animation gets a little bit more tangly.

The Web is a really complicated place to animate, and Miriam Suzanne said it best. “The Web is an infinite and unknowable canvas.”

We don’t usually have consistent units and easy values to interpolate between. As Michelle was talking about, there are tons of different units now. We’ve got pixels and ems and rems and viewport units and container units.

We’ve got all sorts of different devices. We’ve got big screens and little screens, and those stupid new phones that fold in the middle for some reason. [Laughter] Why?

Then we’ve got all sorts of different positioning styles, and elements can be fixed or they can be relative or they can be sticky. They can be children of Flex containers or children of Grid containers. They can be floated or clear fixed (whatever that is) or inline or blocked. It’s a whole thing.

Because of all of this, UI animation can be a massive pain in the bum. It can be really fiddly and really frustrating to get right. Often, designers will mock up stuff in Figma or with their Figma animations.

They’ll have these big ideas. Then you get something handed over to you and the developer just goes, “No, we can’t do that,” and it just gets shut down immediately. I think this is a huge shame because animation can be a really integral part of understanding an interface and guiding a user around.

Why is it so important? It is a good question, and I’ll tell you in a bit.

I’m going to stop talking for a little while, and we’re going to watch a little video together... if the sound works.

[video played]

Richard: Hi, I’m Richard. This is Sarah. And we’re going to perform the amazing color-changing card trick with this blue-backed deck of cards.

Now, the idea is very simple. I’m just going to spread the cards in front of Sarah and ask her to push any card towards the camera.

Sarah: Right. Okay. Let’s see. I’m going to go for this card here.

Richard: Okay. Now, Sarah could have selected any card at all from the deck, but she selected the card which is now face down on the table. What I’m going to ask her to do is show us which card she selected.

Sarah: All right, so the card that I chose was in fact this three of diamonds.

Richard: The three of diamonds. Okay. Excellent choice. That card goes back into the deck. Now I’m just going to spread the cards face up on the table, do a little click of the fingers, and you’ll see that Sarah’s card here has now got a blue back. Not particularly surprising. What’s slightly more surprising is all of the other cards have got red backs. And that is the amazing color-changing card trick.

[piano music]

[video ended]

Cassie: [Laughter] I love that one so much. Anyone who hasn’t seen that video before, who spotted changes? Who didn’t spot changes?

Aye! Look at that!

[audience laughter]

Cassie: We’re all terrible at noticing things. We really are.

Has anyone seen the other, the classic one with the gorillas? Yeah, I almost put that one in, but I think too many people have seen it.

I should have got Marc to run behind in a gorilla suit while I was doing my talk. [Laughter]

Richard Wiseman is really great. I just am obsessed with him. He is a magician and also a psychologist. Surprisingly, he has written some books on the psychology behind magic, and also the psychology behind why we believe in the paranormal, which I find really fascinating as well.

When I was researching this talk, I was reading some research by the UX research group, Nielsen Norman. There was a whole bit on visual awareness. I was like, “Ah, there’s a whole bit. This exact same bit was in Richard Wiseman’s book.”

It was really interesting that there was this crossover between UX research and the psychology behind magic. Basically, we’re all a lot less observant than we’d like to think we are.

In the backs of our eyes, we’ve got these two types of cells that process movement. We’ve got light-sensitive cones, and then we’ve got motion-sensitive rods. In our peripheral vision, we have more of these rods. In our central vision, we have more of these light-sensitive, color-sensitive cones.

Our peripheral vision basically is kind of catching things left and right, and going, “Hey, over here. There’s something for you to look at. Over here, there’s something for you to look at.” Then our central vision captures all of the details.

Way more of the central vision signals get passed up to our brain, and way more neurons analyze the stuff from our central vision. Our peripheral vision gets filled in by our brains. We just kind of make a best guess at what’s going on.

There was a stat. I’ve forgotten exactly what the stat was, but there are more car accidents the closer you get to your home because your brain is so used to what it looks like, the roads around your house, that your brain is like, “Oh, I’ve got this. This road has been empty for the last ten days. I’m sure it’s empty now,” and it just fills in gaps for you, which is kind of terrifying.

But yeah, we see a lot less than we think, and this is called inattentional blindness. We’re all unaware of how blind we are in these spots. Magicians use this to take advantage and do sneaky things when we think we’re looking but our attention is actually elsewhere.

But this brain quirk, it can lead to frustration with website interfaces because we don’t really want to be doing sneaky stuff with UI. We want people to know what’s going on. If something unexpected gets added or updated outside of the user’s main focus area, it can often be missed.

I think we’ve all kind of experienced that when you’re filling in a form and you get to the bottom and you click submit, and it doesn’t work. You’re like, “Submit. Submit. Submit.” Then you scroll up, and there’s a little error state somewhere that you didn’t catch.

We can take advantage of the motion-sensitive cones to give little animated triggers and little visual feedback to people, like this animation. It shows that the plant has been moved into the basket. It’s like, “it’s over here when you want to pay for it.”

I’m a big fan of guiding animations like this, especially after having to help my mom do online shopping during COVID repeatedly. I think the little guiding animations could really help.

Let’s break down transitions a bit. I like to think of UI transitions as fitting into one of these three categories. We’ve got exits, entrances, and then persistent transitions. That’s something leaving the DOM, and then that’s something being added to the DOM. Then persistent is when you’ve got something moving from one place to another.

We’re on a whole magic vibe, so we can do vanishing, appearing, and levitating, which is a bit fun.

Enough slides and lecturing. Look at some code.

We’re going to make this card move from one hand to the other and disappear. This is the best thing about animation is we all do magic tricks regularly on the Web. We’re always making things disappear, so we’ve got opacity zero.

Nice, so it moves over to the other side of the screen and then disappears. But that’s a very light disappear because it’s still accessible for screen readers.

We’ve got a little snippet in GSAP, which is basically doing visibility hidden and opacity. Then we’ve got callbacks, so you can get rid of something after the animation has finished completing.

If we look in the DOM... boop... it’s actually disappeared. So, that’s making something disappear.

We’ll make something appear now. We’ve got the cards over there. Then we want to make it appear in the right hand, so we’re going to set opacity to zero and then animate to the right hand.

I’m going to type really slowly. Should I be pretending to type?

I’m not as brave as Michelle. I did it once and proved to myself that I could do it. Then I was like, “Never again.” [Laughter] There’s nothing worse than a typo in front of everyone.

Past Cassie is typing really slowly and is going to make this card appear at some point. Ta-da!

But this isn’t any good because it’s not actually over there in the DOM. The card is actually over on the left-hand side and all we’ve done is we’ve moved it over with transforms. It’s not in the right place in the DOM, and that’s not going to work for screen readers, it messes up order, and it’s not going to work if you resize the page.

We can use different units to make that a little bit better. But yeah, it’s still not in the right place.

How else could we do this? This is where I see a lot of people (when you’ve got absolutely positioned elements) going, “Oh, well, if you just animate the left property.”

But it’s a bad plan because we don’t just have to worry about animatable values on the Web. We’ve also got to worry about which values we’re animating and how they’re impacting performance.

Let’s look at how browsers work. After all your HTML and CSS and stuff gets processed, the browser goes through three steps to get all of the lovely pixels on the screen.

We’ve got layout first. It’s where the browser calculates all the positions of the elements. Then you don’t see this bit happening. This is just the browser thinking about things.

Then the pixels get painted onto layers. Finally, those layers get popped on top of each other to create the website.

Animation-wise, you’ll probably often hear people saying, “Oh, you should always animate transforms, but that’s why because transforms can be animated in this last step, this composite step. It’s very cheap and efficient for the browser to move these layers around.

If we were to animate a layout property like top or left, the browser has to reflow the page and then go through all of the steps again. You first layout and then paint and then composite. When you’re animating something, that’s happening over and over and over and over again during the whole course of the animation, so that’s why you end up with chucking animations.

If we animate stuff like background color, we’re hitting the paint step, so we don’t trigger layout, and that’s better. But if we use transforms and opacity, we’re just hitting composite and we get buttery smooth animations.

I’m still so sad that my font didn’t load. [Laughter]

How do we animate something into its correct position in the DOM without using layout properties? The trick here is to animate from transformed positions. We’ve put it into the end position, and then we’re using a from tween to animate from the starting point.

Ta-ta-da! Then it’s in its actual position.

Now, this is just a teeny tiny detail, and I’m sure a lot of you are sitting here going, “Duh. That’s really obvious, Cassie.” But this is the setup for our big magic trick. It’s a good little bit to know.

Here we’ve got a card that’s positioned relative. It’s hanging out in a Flex container. We want to make it full-screen position fixed.

This is the issue I was talking about earlier where there’s no transitionary states in between fixed and relative. You’ll see a lot of people new to animation trying to add a transition on something like this.

It’s trying so hard. Look at it. It’s really giving it its best go. But you’ll see that we’re not actually controlling the animation because it’s been pulled out of the flow of the document and then bopped back in again. We just end up with this jumping animation, and we can’t control where the transform-origin is animating from.

How do we animate impossible challenges like this? We’ve got an animation technique at our fingertips that’s a little bit like browser sleight-of-hand. This basically boils down to when the animation starts. We have to make it look like the element hasn’t moved at all when it’s actually already in its final resting place, which is a very common trick for magicians. It’s a little bit of an illusion.

This animation technique is called Flip. Flip is an animation technique that’s been around for years now.

Paul Lewis from Google was the first to coin the phrase. David Khorshed and Sarah Drasner have done lots of talks and written lots of articles about it. But I still see loads of people popping into the GSAP forums with animation challenges that could be really easily solved with Flip, so I think it’s a good one to go over.

There’s a handy mnemonic that stands for first, last, invert, and play.

Let’s take a look at how this works. First up, we have to get the first initial starting position, so we’re using getBoundingClientRect here to just grab the position of the cards relative to the viewport. We get an object back, and we can look at the top and the left and the width and the height values.

Then we move the element to its new position in the DOM. This is happening in the layout stage, so we don’t actually see it happening. This is just browser calculations.

We tell the browser to take measurements, find out where this new position is, and then we work out how far the elements moved. In between layout and paint is where this kind of magic illusion trick happens.

We leave the element in its final position. Once we know what the difference between those values are, we invert it back to its previous position using transforms.

To the user who has just clicked on the element, it looks like nothing has happened yet even though the element is in a completely new position. Then the play of it is we just remove the transforms, and then the element animates from the transformed values smoothly into its resting place.

All of code time, I fell that you’ve got spoiled and you haven’t had too many rules of code at this conference. This is what a simple Flip animation looks like in vanilla JavaScript.

We’ve got our first bit there. Then switch it up is just doing some DOM changes, so whatever DOM changes you needed to do. Grabbing the last position, and then working out the difference between the first and last position or delta values. Then applying those delta values to a transform.

Then you can use CSS to animate between those positions. We just animate the removal of the offsets.

That’s a simple Flip transition. There are a lot of weird little browser quirks and situations where it’s a little bit more complicated, like if you have nested transforms, certain Flex or Grid layouts.

At GSAP, we made a Flip plugin that kind of does this magic trick for you. This is the Flip code, so you grab the first state, Flip.getState, do your DOM changes, and then animate from the state.

Yeah, let’s look at it in action. Ta-da! Animating between a relative positioned element in a Flex container and a fixed position element. Then we’ve added some nonsense things as well, so you can make it spin if you want to.

I don’t think anyone ever uses spin. I can’t imagine a situation where you’ve got a masonry grid and you just want to wiz everything around, but I don’t know. Personal websites, if you wanted to do it, you could.

Yeah. I think that’s it. It’s just repeating. Great.

That’s hard, but it’s not super impossible, so we’re going to make it even more impossible. Let’s step it up a little bit.

Reparenting: In this demo, we’ve got one div and then we’ve got a left hand and a right hand. We’re going to move the card from one div into the other div.

Here’s some stuff. There’s this little reparenting card function, which is appending the element into the right hand. Is it right hand to you? Left hand... right hand. Yeah.

If we play that... Ta-da! Even though it’s actually moving to a completely new place in the DOM, I think that’s pretty mind-blowing, personally, the first time I saw that in action. I was like, “I can’t believe it.”

If we pause it quickly, and take a little look, you can see the trick actually happening. When we click on it... doo-ta-doo... whoop...

It’s still on the left-hand side. But if we look, you can see that the card is actually on the right-hand side, but it’s got a bunch of transforms applied to it to look like it hasn’t actually moved.

I just think that’s so cool. I feel like that’s lifting up the magician’s curtain (when I first looked at it in dev tools). To be honest, I’d heard an explanation of Flip so many times and it just didn’t really click until I tried to do it and then looked in dev tools and saw it move but not move. I was like, “Ah! Look at that! It’s so clever!”

Yeah, this is where I was going with this one. I’d forgot for a second.

Reparenting, that’s how a lot of people working in more vanilla codebases do things. But frameworks love to just render entirely new DOMs. They love it.

It’s their favorite thing to not give you consistent states to actually animate between. They’re like, “No, we’re just going to take that completely away and give you a new thing.”

How do we do that because, Flip animations, you’ve got to have two different states to animate between? We’ve got a data Flip ID. You can add an ID, which is just basically a way to say, “Remember this element. This element has got a relationship to this other element.”

We’ve got to put in targets as well because one card is being taken out of the DOM and then another one is being added to the DOM. When the flip transition starts, the card wasn’t there for the initial get state. The incoming card wasn’t, so we’ve got the targets, and we’ve got the Flip ID. We can animate between two different states, even if one has been taken out of the DOM and one has been added into the DOM, which I feel is pretty magical and pretty impossible to me.

Hurray! Okay. [Laughter]

Let’s do even more impossible!

In the last one, we had adding, and we had deleting, but they were sharing state. What do we actually do if we want to add and delete things, not have an element that’s kind of there for the start and the end?

This is always really annoying, animation challenge because if you remove something from the DOM--

I’m just going to start this again because I’m rambling.

If you remove something from the DOM, it’s really hard to animate it out because that’s another binary state. Something is either there or it isn’t.

You can see that when we add a card, it impacts all of the other ones. It kind of messes up all the flips. When we let go of it, it just jumps out of the DOM, and the others are trying to animate into place, but it’s not quite working.

We’ve got callbacks that we can add into a Flip animation. I think that’s where I’m going here. Yes! [Laughter]

We’ve got a callback on enter, so we grab all of the cards, and then we can say, “If there’s a card in this array that wasn’t there at the beginning where we grabbed the state, we want you to parse it through to this on-enter function, and then you can handle that however you want.”

I’m really slow at typing.

Go!

Hurray! You can do entrance animations separately from your Flip transitions, but they also get included in the same set.

Then we can do the same with on-leave as well, so when we’ve got an animation that’s exiting, so something that was there for the beginning bit of grabbing the state but wasn’t there at the end bit. We can handle that differently as well.

This is really handy because--

Ooh, I didn’t mention... yeah, so the on-leave, Flip detects that something is leaving if it’s got a display none or visibility hidden or opacity zero added to it during the course of the Flip transition. If you’ve got an interaction that changes something to visibility hidden, Flip is like, “Oh, that’s leaving. We’ll pass it through to this animation function for you.” Then in there, on complete, when the animation is finished, you can actually remove it physically out of the DOM, which is always the best way to do things because it doesn’t get in the way for screen readers.

Yeah, that’s basically the concept of Flip and kind of how we can implement it using a Flip plugin.

Also, I said that the whole purpose of Flip is to avoid layout reflows as well. But it’s also worth noting that it depends. It always depends, doesn’t it? That’s such a developer thing.

Sometimes you have to break the rules, so sometimes animating scale doesn’t really work if you’ve got border-radius. Border radius does not scale well. If you’ve got text nested inside elements and you scale it, the text all goes squishy. In these sort of situations, it’s often best to animate height instead, but make sure you test on low-end devices.

We’ve also got nested true on these, so you could see that they were all kind of wildly flailing everywhere at the beginning of this transition. That’s because we’ve got an outer element that’s being flipped. Then we’ve got inner elements that are also being flipped. We’ve got nested true that you can add so that that works.

If you were like, “Oh, I wonder how that works? I would quite like to implement that with vanilla JavaScript,” of course, it’s called a flip-flop. [Laughter]

Technically, you have to do first, last, invert, and play on the parent. Then you do the same thing again for the children. You do first, last, calculate the offset from the parent, and then, yeah, that’s how that works. David Khorshed has written an article about that as well.

Yeah, that’s the Flip technique, which is, in my opinion, the most magical Web animation technique that we have. And you’ve seen a lot of little animations with cards. Here’s a good example of it actually working in real life.

I think people often think that the flip technique is just for masonry grids or moving big elements around. But I use it all the time just in little decorative timeline animations, so I did this animation on the ESLint site.

You can see this little cursor comes down from the top and then clicks on that little dropdown. But the text was CMS-able, so they could put whatever text they wanted in there. Also, you don’t know where that box is going to pop up because the text is all going to squish down on different screen sizes.

There was no way for me to know how far it was between those two points, so I used the Flip technique. I’ve got position absolute, a little cursor on the box, and then I’ve got another position absolute cursor up in the top right corner. Then just animated between them with two different eases, so it gives a curved motion.

Yeah, you can use it on little things like that. Ryan Mulligan made this little example, which I really love. I mostly just love that little bouncy icon in the bottom corner. It’s really sweet.

For big, decorative websites, sure, there might be a lot of use cases. But the Flip technique is really, really helpful when it comes to complicated UI, often UI that’s user-operated. If you’ve got elements that they need to drag around on interfaces to control a bit of software or something like that, or to control a complicated logic flow, it’s really bad to just yoink things out of the DOM and pop them in new places because people can’t really follow what’s happening. If they’re already focusing really hard on something that’s complex, giving little animation nudges is really, really helpful.

[Laughter] Sorry. My fonts. That’s really bad. [Laughter]

They were such nice fonts as well. They were perfect.

Yeah, there are also super exciting, native-flipping things coming. Flipping things... Well, arrived, kind of, almost.

They’ve landed in Chrome. Nobody screenshot this. Jake Archibald will kill me. [Laughter] They’ve currently landed in Chrome, and they’re being worked on as a draft spec, so they’re kind of open for feedback on this.

This is a rework of the reparenting demo using the view transitions API. This isn’t taking it out of the DOM and putting it back in again. This is just moving it around.

But, yeah, under the hood it’s using the same trick. It’s just abstracted away a little bit more. This is what it looks like in JavaScript. We’ve got a fallback for browsers that don’t support the API, which is everything apart from Chrome at the moment.

Then there’s a transition. Just start a view transition and then reparent card. That’s it.

Then over in the CSS, we’ve given the card a view transition name. The view transition API makes a pseudo-element tree out of any elements that you tell it to grab. It’s like the root of the page, like the whole page screenshot, and then it screenshots any other elements that you’ve got with a view transition name. Then we can use CSS to do a transition.

They’re also going to make... They’re working on making the pseudo elements available to JavaScript, which is apparently a massive job as well. But that’ll be really helpful for people that are making very complex animations to be able to actually grab these pseudo-elements. It’s going to work eventually between full-page transitions as well, so very exciting things coming.

Yeah. I’m just going to leave you with one last little message. I hope that you’ve found understanding, learning about the Flip technique useful, and I hope that you find little places to use it in your UI in the future.

But remember to use your animation powers responsibly, especially big, swipy layout shifts. They can be very nauseating for people with vestibular disorders.

I do animation for a living, and I got an inner ear infection a while back. I just couldn’t. I couldn’t look at most of the websites that I had to look at for work. So, it’s very important.

If the animation is an integral part of explaining the UI, then provide a subtle animation opacity fallback. If it’s just decorative, like the noodles that I showed you that I made, you can just disable that.

That’s it.

Go and make your websites more magical. Thank you very much for having me.

[audience applause]