Join Rachel Nabors for an in-depth discussion in this video CSS triggers, part of Motion Design with CSS.
(upbeat music) - Before we dive too far into the tools which are fun, it's important that we acknowledge that all browsers have slightly different rendering pipelines. They all have their own ways of doing things. And a lot of Perf people tend to forget that, and only optimize for Chrome, because it's got the nicest (mumbles) tools and it's got the biggest share of the market, but Chrome is not the only browser. And it has a very specific performance space.
And it has a very specific pipeline for rendering things. But it is one that we are very familiar with, and thus, I will use it to describe one browser's kind of development. This is CSS-- - [Female] Sorry, I'm gonna interrupt. Can we just get that question really quick? - Yes, I'm sorry. - [Female] There's-- no, that's okay. Okay, so before you jump into performance stuff, Christine has a question. Is there any way to reverse an animation from animation fill forwards back to the beginning, initiated by user action? - That's a good question.
Let's see. Reverse in animation from fill forwards. I would assume that Christine has already tried using something like changing the animation to reverse in that situation, changing its direction to reverse. But you would need to also give it another set of iterations to complete.
And you would have to trigger it to play. So to that, I'm gonna answer I don't know. I haven't encountered that use case myself, so I don't know how to provide a solution for it. If anyone has any ideas, it'd be awesome to share them with Christine. - [Male] GreenSock. - What did you say? - [Male] GreenSock. - GreenSock. - [Male] GSAP. - All right. That's one option, but GreenSock is not CSS animation.
All right. So this is CSStriggers.com. It used to just be for Chrome. This is maintained by Chrome's members. Pardon, this is maintained by some Chrome folks, so originally it was just for the Blink engine. But now, it displays information about Blink, Gecko, that is, I believe, Firefox, WebKit, Safari, Opera, sorry, Opera is Blink, and Edge HTML. So now we can see how all of these different CSS properties affect their rendering pipelines as well.
So change from default is that initial change, when you first animate something, and then subsequent updates after it started changing. How much does it cost to continue changing it? And I'm going to assume that the blank spots here are for information insufficient. Now as you can see, these do change a little bit from one to the other. This is color coded, so purple bars represent layout. The light green ones represent Paint, and the dark green ones represent composite. What do those mean? So does anyone remember when we used to build websites? We were admonished not to use percentages.
We used to use tables, and you could set them to be 50% wide, and this cell would be 25% wide. And all of the books used to say things like, "Don't use percentages on your images or on your layouts "because browsers take a long time to calculate those. "Use exact widths." So then we started being like, "Okay, exact width." Okay, it's 800 pixels wide, and the image should be this. Browsers are a lot better at doing that, computers are a lot faster, and now we can use percentages like nobody's business. But it still takes browsers time to calculate where everything should be on the page, from its width all the way to how long the text is, where this image appears, etc.
It does all these calculations. That's called the layout process, where it's calculating where things go. The paint process is where individual items are painted, sometimes on the GPU. They are painted, and then composite happens, where those things are pasted into the layout. That might be a pigeon way of putting it, but that's the best way I can describe it. It's a three step process, the where, the what, and then combining them. So we can see which of these different effects are being triggered by which of these different CSS properties.
I get to do this one all on the screen now. So when we see solid bars, that's a very bad sign. For instance, align-items. That changes if words are centered, or if they are right or left aligned. This could change layout in pretty big ways. So not only does it trigger layout, but it also triggers repaints, and it triggers composites. So it's a very intensive thing for any browser to perform.
We get to backface-visibility, we start seeing that in different browsers, it doesn't trigger layouts. It doesn't trigger-- in Firefox, it appears to not trigger Paint either. So once you start seeing these bars graying out, these are things that are better to animate. I don't believe that you can animate background-attachment, by the way. Sometimes that's why they are grayed out. All right, like background-repeat, that's not animatable. So let's see.
Let's go on this little stroll. Borders trigger all kinds of stuff because when you change something's width, you're pushing things around on the page, oh no, I got to go do the layout, it's a really expensive performance problem. Ba, ba, ba. Oh, cursor. Cursor's great. Not that you can animate that. Oh, so many solid bars, what can we-- orphans. Orphans. Oh man. Perspective.
This is a 3D transform property, which we haven't been using at all today. Things associated with 3D transforms tend to be very performant. Oh, here we go. Transform. So transform, as you can see, on Blink, that is to say, on Chrome and the new Opera, transform is very performant in that it does not trigger layouts and it does not trigger repaints. So when you're moving something around using transform, it's not actually repositioning anything else on the page.
So Chrome just kicks it over to the GPU and does all the-- continues onward with its current layout and doesn't bother recalculating anything. But you can see that in the other browsers, that's not the case. So this might not be as performant on other browsers as it is here in Chrome, although it looks like Edge at least doesn't trigger layouts after that initial change. That's nice to know, Edge, thank you. Whew. And opacity should be in here too.
I was a bit surprised by opacity. But it is a little bit more across the board performant than transform. There are our two favorites, as far as animatable properties, these are our two favorites to win, opacity and transform, because they are the least disruptive across the most browsers. You can see here that opacity in Blink, in Firefox, and even in Edge does not trigger layouts. And in Chrome, in Blink, it doesn't trigger repaints either, on subsequent changes.
So it's a handy resource. But once again, you should definitely try to check these against the browsers you're developing for, because sometimes, things don't perform the way you think they would. So our two best friends are opacity and transform, because they trigger the least amount of layouts, the least amount of repaints. So how do we take common animations and think of them in terms of transform and opacity? As a designer, this is really, really, really, really important, because I've seen designers do some really cool things, then try to hand them off to developers, and developer be like, "This does not "look good in the browser at all.
"You can't do all of these things." In fact, I have actually made some things that today don't perform too well. We'll look at some of those too. Once again, I use my own examples, because if I'm gonna embarrass anyone, I should embarrass myself. But first, let's take a look at some of these things that we can convert over. For instance, instead of animating height or width, which trigger a lot of layout, you can use scale to transform the size of something or something's container. Instead of transforming position, like using position absolute, top zero, left zero, and then animating the top and left properties, you can use translate.
Translate is going to position that element in rele-- pardon, in relation to where it existed previously. It's sort of like position relative, except it doesn't move anything else around it. And we can use opacity instead of using z-index or visibility: hidden. Just a really quick opacity change can look like a jump cut, and sometimes you want that.
Note: This course was created by Frontend Masters. It was originally released on 09/15/2016. We're pleased to host this training in our library.
- CSS transitions and animations
- Using animation in product design
- Creating a sprite animation with CSS
- Stateful transitions and supplemental animations
- Using developer tools to manipulate animations
- Jump cuts and in-betweening
- Static vs. dynamic animations
- Designing performant animations