{"id":265831,"date":"2018-03-07T06:15:45","date_gmt":"2018-03-07T13:15:45","guid":{"rendered":"http:\/\/css-tricks.com\/?p=265831"},"modified":"2019-03-15T01:40:58","modified_gmt":"2019-03-15T08:40:58","slug":"what-houdini-means-for-animating-transforms","status":"publish","type":"post","link":"https:\/\/css-tricks.com\/what-houdini-means-for-animating-transforms\/","title":{"rendered":"What Houdini Means for Animating Transforms"},"content":{"rendered":"

I’ve been playing with CSS transforms for over five years and one thing that has always bugged me was that I couldn’t animate the components of a transform<\/code> chain individually. This article is going to explain the problem, the old workaround, the new magic Houdini<\/a> solution<\/a> and, finally, will offer you a feast of eye candy through better looking examples than those used to illustrate concepts.<\/p>\n

<\/p>\n

The Problem<\/h3>\n

In order to better understand the issue at hand, let’s consider the example of a box we move horizontally across the screen. This means one div<\/code> as far as the HTML goes:<\/p>\n

<div class=\"box\"><\/div><\/code><\/pre>\n
The CSS is also pretty straightforward. We give this box dimensions, a background<\/code> and position it in the middle horizontally with a margin<\/code>.<\/p>\n
$d: 4em;\r\n\r\n.box {\r\n  margin: .25*$d auto;\r\n  width: $d; height: $d;\r\n  background: #f90;\r\n}<\/code><\/pre>\n
See the Pen<\/a> by thebabydino (@thebabydino<\/a>) on CodePen<\/a>.<\/p>\n
Next, with the help of a translation along the x<\/var> axis, we move it by half a viewport (50vw<\/code>) to the left (in the negative direction of the x<\/var> axis, the positive one being towards the right):<\/p>\n
transform: translate(-50vw);<\/code><\/pre>\n
See the Pen<\/a> by thebabydino (@thebabydino<\/a>) on CodePen<\/a>.<\/p>\n
Now the left half of the box is outside the screen. Decreasing the absolute amount of translation by half its edge length puts it fully within the viewport while decreasing it by anything more, let’s say a full edge length (which is $d<\/code> or 100%<\/code>—remember that %<\/code> values in translate()<\/code> functions are relative to the dimensions of the element being translated<\/a>), makes it not even touch the left edge of the viewport anymore.<\/p>\n
transform: translate(calc(-1*(50vw - 100%)));<\/code><\/pre>\n
See the Pen<\/a> by thebabydino (@thebabydino<\/a>) on CodePen<\/a>.<\/p>\n
This is going to be our initial animation position.<\/p>\n
We then create a set of @keyframes<\/code> to move the box to the symmetrical position with respect to the initial one with no translation and reference them when setting the animation<\/code>:<\/p>\n
$t: 1.5s;\r\n\r\n.box {\r\n  \/* same styles as before *\/\r\n  animation: move $t ease-in-out infinite alternate;\r\n}\r\n\r\n@keyframes move {\r\n  to { transform: translate(calc(50vw - 100%)); }\r\n}<\/code><\/pre>\n
This all works as expected, giving us a box that moves from left to right and back:<\/p>\n
See the Pen<\/a> by thebabydino (@thebabydino<\/a>) on CodePen<\/a>.<\/p>\n
But this is a pretty boring animation, so let’s make it more interesting. Let’s say we want the box to be scaled down to a factor of .1<\/code> when it’s in the middle and have its normal size at the two ends. We could add one more keyframe:<\/p>\n
50% { transform: scale(.1); }<\/code><\/pre>\n
The box now also scales (demo<\/a>), but, since we’ve added an extra keyframe, the timing function is not applied for the whole animation anymore—just for the portions in between keyframes. This makes our translation slow in the middle (at 50%<\/code>) as we now also have a keyframe there. So we need to tweak the timing function, both in the animation<\/code> value and in the @keyframes<\/code>. In our case, since we want to have an ease-in-out<\/code> overall, we can split it into one ease-in<\/code> and one ease-out<\/code>.<\/p>\n
.box {\r\n  animation: move $t ease-in infinite alternate;\r\n}\r\n\r\n@keyframes move {\r\n  50% {\r\n    transform: scale(.1);\r\n    animation-timing-function: ease-out;\r\n  }\r\n  to { transform: translate(calc(50vw - 100%)); }\r\n}<\/code><\/pre>\n
See the Pen<\/a> by thebabydino (@thebabydino<\/a>) on CodePen<\/a>.<\/p>\n
Now all works fine, but what if we wanted different timing functions for the translation and scaling? The timing functions we’ve set mean the animation<\/code> is slower at the beginning, faster in the middle and then slower again at the end. What if we wanted this to apply just to the translation, but not to the scale? What if we wanted the scaling to happen fast at the beginning, when it goes from 1<\/code> towards .1<\/code>, slow in the middle when it’s around .1<\/code> and then fast again at the end when it goes back to 1<\/code>?<\/p>\n
\"SVG
The animation timeline (live<\/a>).<\/figcaption><\/figure>\n
Well, it’s just not possible to set different timing functions for different transform functions in the same chain. We cannot make the translation slow and the scaling fast at the beginning or the other way around in the middle. At least, not while what we animate is the transform<\/code> property and they’re part of the same transform<\/code> chain.<\/p>\n
The Old Workaround<\/h3>\n
There are of course ways of going around this issue. Traditionally, the solution has been to split the transform<\/code> (and consequently, the animation<\/code>) over multiple elements. This gives us the following structure:<\/p>\n
<div class=\"wrap\">\r\n  <div class=\"box\"><\/div>\r\n<\/div><\/code><\/pre>\n
We move the width<\/code> property on the wrapper. Since div<\/code> elements are block elements by default, this will also determine the width<\/code> of its .box<\/code> child without us having to set it explicitly. We keep the height<\/code> on the .box<\/code> however, as the height<\/code> of a child (the .box<\/code> in this case) also determines the height<\/code> of its parent (the wrapper in this case).<\/p>\n
We also move up the margin<\/code>, transform<\/code> and animation<\/code> properties. In addition to this, we switch back to an ease-in-out<\/code> timing function for this animation<\/code>. We also modify the move<\/code> set of @keyframes<\/code> to what it was initially, so that we get rid of the scale()<\/code>.<\/p>\n
.wrap {\r\n  margin: .25*$d calc(50% - #{.5*$d});\r\n  width: $d;\r\n  transform: translate(calc(-1*(50vw - 100%)));\r\n  animation: move $t ease-in-out infinite alternate;\r\n}\r\n\r\n@keyframes move {\r\n  to { transform: translate(calc(50vw - 100%)); }\r\n}<\/code><\/pre>\n
We create another set of @keyframes<\/code> which we use for the actual .box<\/code> element. This is an alternating animation<\/code> of half the duration of the one producing the oscillatory motion.<\/p>\n
.box {\r\n  height: $d;\r\n  background: #f90;\r\n  animation: size .5*$t ease-out infinite alternate;\r\n}\r\n\r\n@keyframes size { to { transform: scale(.1); } }<\/code><\/pre>\n
We now have the result we wanted: <\/p>\n
See the Pen<\/a> by thebabydino (@thebabydino<\/a>) on CodePen<\/a>.<\/p>\n
This is a solid workaround that doesn’t add too much extra code, not to mention the fact that, in this particular case, we don’t really need two elements, we could do with just one and one of its pseudo-elements. But if our transform chain gets longer, we have no choice but to add extra elements. And, in 2018, we can do better than that!<\/p>\n
The Houdini Solution<\/h3>\n
Some of you may already know that CSS variables<\/a> are not animatable (and I guess anyone who didn’t just found out). If we try to use them in an animation<\/code>, they just flip from one value to the other when half the time in between has elapsed.<\/p>\n
Consider the initial example of the oscillating box (no scaling involved). Let’s say we try to animate it using a custom property --x<\/code>:<\/p>\n
.box {\r\n  \/* same styles as before *\/\r\n  transform: translate(var(--x, calc(-1*(50vw - #{$d}))));\r\n  animation: move $t ease-in-out infinite alternate\r\n}\r\n\r\n@keyframes move { to { --x: calc(50vw - #{$d}) } }<\/code><\/pre>\n
Sadly, this just results in a flip at 50%<\/code>, the official reason being that browsers cannot know the type of the custom property (which doesn’t make sense to me, but I guess that doesn’t really matter).<\/p>\n
See the Pen<\/a> by thebabydino (@thebabydino<\/a>) on CodePen<\/a>.<\/p>\n
But we can forget about all of this because now Houdini has entered the picture and we can register such custom properties so that we explicitly give them a type (the syntax<\/code>).<\/p>\n
For more info on this, check out the talk<\/a> and slides<\/a> by Serg Hospodarets<\/a>.<\/p>\n
CSS.registerProperty({\r\n  name: '--x', \r\n  syntax: '<length>',\r\n  initialValue: 0, \r\n  inherits: false\r\n});<\/code><\/pre>\n
inherits<\/code> was optional in the early versions of the spec, but then it became mandatory, so if you find an older Houdini demo that doesn’t work anymore, it may well be because it doesn’t explicitly set inherits<\/code>.<\/p>\n
We’ve set the initialValue<\/code> to 0<\/code>, because we have to set it to something and that something has to be a computationally independent<\/a> value—that is, it cannot depend on anything we can set or change in the CSS and, given the initial and final translation values depend on the box dimensions, which we set in the CSS, calc(-1*(50vw - 100%))<\/code> is not valid here. It doesn’t even work to set --x<\/code> to calc(-1*(50vw - 100%))<\/code>, we need to use calc(-1*(50vw - #{$d}))<\/code> instead.<\/p>\n
$d: 4em;\r\n$t: 1.5s;\r\n\r\n.box {\r\n  margin: .25*$d auto;\r\n  width: $d; height: $d;\r\n  --x: calc(-1*(50vw - #{$d}));\r\n  transform: translate(var(--x));\r\n  background: #f90;\r\n  animation: move $t ease-in-out infinite alternate;\r\n}\r\n\r\n@keyframes move { to { --x: calc(50vw - #{$d}); } }<\/code><\/pre>\n
\"Animated
The simple oscillating box we get using the new method (live demo<\/a>, needs Houdini support).<\/figcaption><\/figure>\n
For now, this only works in Blink browsers behind the Experimental Web Platform features<\/strong> flag. This can be enabled from chrome:\/\/flags<\/code> (or, if you’re using Opera, opera:\/\/flags<\/code>):<\/p>\n
\"Screenshot
The Experimental Web Platform features flag enabled in Chrome.<\/figcaption><\/figure>\n
In all other browsers, we still see the flip at 50%<\/code>.<\/p>\n
Applying this to our oscillating and scaling demo means we introduce two custom properties we register and animate—one is the translation amount along the x<\/var> axis (--x<\/code>) and the other one is the uniform scaling factor (--f<\/code>).<\/p>\n
CSS.registerProperty({ \/* same as before *\/ });\r\n\r\nCSS.registerProperty({\r\n  name: '--f', \r\n  syntax: '<number>',\r\n  initialValue: 1, \r\n  inherits: false\r\n});<\/code><\/pre>\n
The relevant CSS is as follows:<\/p>\n
.box {\r\n  --x: calc(-1*(50vw - #{$d}));\r\n  transform: translate(var(--x)) scale(var(--f));\r\n  animation: move $t ease-in-out infinite alternate, \r\n             size .5*$t ease-out infinite alternate;\r\n}\r\n\r\n@keyframes move { to { --x: calc(50vw - #{$d}); } }\r\n\r\n@keyframes size { to { --f: .1 } }<\/code><\/pre>\n
\"Animated
The oscillating and scaling with the new method (live demo<\/a>, needs Houdini support).<\/figcaption><\/figure>\n
Better Looking Stuff<\/h3>\n
A simple oscillating and scaling square isn’t the most exciting thing though, so let’s see nicer demos!<\/p>\n
\"Screenshots
More interesting examples. Left: rotating wavy grid of cubes. Right: bouncing square.<\/figcaption><\/figure>\n
The 3D version<\/h4>\n
Going from 2D to 3D, the square becomes a cube and, since just one cube isn’t interesting enough, let’s have a whole grid of them!<\/p>\n
We consider the body<\/code> to be our scene. In this scene, we have a 3D assembly of cubes (.a3d<\/code>). These cubes are distributed on a grid of nr<\/code> rows and nc<\/code> columns:<\/p>\n
- var nr = 13, nc = 13;\r\n- var n = nr*nc;\r\n\r\n.a3d\r\n  while n--\r\n    .cube\r\n      - var n6hedron= 6; \/\/ cube always has 6 faces\r\n      while n6hedron--\r\n        .cube__face<\/code><\/pre>\n
The first thing we do is a few basic styles to create a scene with a perspective, put the whole assembly in the middle and put each cube face into its place. We won’t be going into the details of how to build a CSS cube because I’ve already dedicated a very detailed article<\/a> to this topic, so if you need a recap, check that one out!<\/p>\n
The result so far can be seen below – all the cubes stacked up in the middle of the scene:<\/p>\n
\"Screenshot.
All the cubes stacked up in the middle (live demo<\/a>).<\/figcaption><\/figure>\n
For all these cubes, their front half is in front of the plane of the screen and their back half is behind the plane of the screen. In the plane of the screen, we have a square section of our cube. This square is identical to the ones representing the cube faces.<\/p>\n
See the Pen<\/a> by thebabydino (@thebabydino<\/a>) on CodePen<\/a>.<\/p>\n
Next, we set the column (--i<\/code>) and row (--j<\/code>) indices on groups of cubes. Initially, we set both these indices to 0<\/code> for all cubes.<\/p>\n
.cube {\r\n  --i: 0;\r\n  --j: 0;\r\n}<\/code><\/pre>\n
Since we have a number of cubes equal to the number of columns (nc<\/code>) on every row, we then set the row index to 1<\/code> for all cubes after the first nc<\/code> ones. Then, for all cubes after the first 2*nc<\/code> ones, we set the row index to 2<\/code>. And so on, until we’ve covered all nr<\/code> rows:<\/p>\n
style\r\n  | .cube:nth-child(n + #{1*nc + 1}) { --j: 1 }\r\n  | .cube:nth-child(n + #{2*nc + 1}) { --j: 2 }\r\n  \/\/- and so on\r\n  | .cube:nth-child(n + #{(nr - 1)*nc + 1}) { --j: #{nr - 1} }<\/code><\/pre>\n
We can compact this in a loop:<\/p>\n
style\r\n  - for(var i = 1; i < nr; i++) {\r\n    | .cube:nth-child(n + #{i*nc + 1}) { --j: #{i} }\r\n  -}<\/code><\/pre>\n
Afterwards, we move on to setting the column indices. For the columns, we always need to skip a number of cubes equal to nc - 1<\/code> before we encounter another cube with the same index. So, for every cube, the nc<\/code>-th cube after it is going to have the same index and we’re going to have nc<\/code> such groups of cubes.<\/p>\n
(We only need to set the index to the last nc - 1<\/code>, because all cubes have the column index set to 0<\/code> initially, so we can skip the first group containing the cubes for which the column index is 0<\/code> – no need to set --i<\/code> again to the same value it already has.)<\/p>\n
style\r\n  | .cube:nth-child(#{nc}n + 2) { --i: 1 }\r\n  | .cube:nth-child(#{nc}n + 3) { --i: 2 }\r\n  \/\/- and so on\r\n  | .cube:nth-child(#{nc}n + #{nc}) { --i: #{nc - 1} }<\/code><\/pre>\n
This, too, can be compacted in a loop:<\/p>\n
style\r\n  - for(var i = 1; i < nc; i++) {\r\n    | .cube:nth-child(#{nc}n + #{i + 1}) { --i: #{i} }\r\n  -}<\/code><\/pre>\n
Now that we have all the row and column indices set, we can distribute these cubes on a 2D grid in the plane of the screen using a 2D translate()<\/code> transform, according to the illustration below, where each cube is represented by its square section in the plane of the screen and the distances are measured in between transform-origin<\/code> points (which are, by default, at 50% 50% 0<\/code>, so dead in the middle of the square cube sections from the plane of the screen):<\/p>\n
\"SVG0<\/code>) and on the first row (of index 0<\/code>). All items on the second column (of index 1<\/code>) are offset horizontally by and edge length. All items on the third column (of index 2<\/code>) are offset horizontally by two edge lengths. In general, all items on the column of index i<\/code> are offset horizontally by i<\/code> edge lengths. All items on the last column (of index nc - 1<\/code>) are offset horizontally by nc - 1<\/code> edge lengths. All items on the second row (of index 1<\/code>) are offset vertically by and edge length. All items on the third row (of index 2<\/code>) are offset vertically by two edge lengths. In general, all items on the row of index j<\/code> are offset vertically by j<\/code> edge lengths. All items on the last row (of index nr - 1<\/code>) are offset vertically by nr - 1<\/code> edge lengths.”\/>
How to create a basic grid starting from the position of the top left item (live<\/a>).<\/figcaption><\/figure>\n
\/* $l is the cube edge length *\/\r\n.cube {\r\n  \/* same as before *\/\r\n  --x: calc(var(--i)*#{$l});\r\n  --y: calc(var(--j)*#{$l});\r\n  transform: translate(var(--x), var(--y));\r\n}<\/code><\/pre>\n
This gives us a grid, but it’s not in the middle of the screen.<\/p>\n
\"Screenshot.
The grid, having the midpoint of the top left cube in the middle of the screen (live demo<\/a>).<\/figcaption><\/figure>\n
Right now, it’s the central point of the top left cube that’s in the middle of the screen, as highlighted in the demo above. What we want is for the grid to be in the middle, meaning that we need to shift all cubes left and up (in the negative direction of both the x<\/var> and y<\/var> axes) by the horizontal and vertical differences between half the grid dimensions (calc(.5*var(--nc)*#{$l})<\/code> and calc(.5*var(--nr)*#{$l})<\/code>, respectively) and the distances between the top left corner of the grid and the midpoint of the top left cube’s vertical cross-section in the plane of the screen (these distances are each half the cube edge, or .5*$l<\/code>).<\/p>\n
\"\"\/
The difference between the position of the grid midpoint and the top left item midpoint (live<\/a>).<\/figcaption><\/figure>\n
Subtracting these differences from the previous amounts, our code becomes:<\/p>\n
.cube {\r\n  \/* same as before *\/\r\n  --x: calc(var(--i)*#{$l} - (.5*var(--nc)*#{$l} - .5*#{$l}));\r\n  --y: calc(var(--j)*#{$l} - (.5*var(--nr)*#{$l} - .5*#{$l}));\r\n}<\/code><\/pre>\n
Or even better:<\/p>\n
.cube {\r\n  \/* same as before *\/\r\n  --x: calc((var(--i) - .5*(var(--nc) - 1))*#{$l}));\r\n  --y: calc((var(--j) - .5*(var(--nr) - 1))*#{$l}));\r\n}<\/code><\/pre>\n
We also need to make sure we set the --nc<\/code> and --nr<\/code> custom properties:<\/p>\n
- var nr = 13, nc = 13;\r\n- var n = nr*nc;\r\n\r\n\/\/- same as before\r\n.a3d(style=`--nc: ${nc}; --nr: ${nr}`)\r\n  \/\/- same as before<\/code><\/pre>\n
This gives us a grid that’s in the middle of the viewport:<\/p>\n
\"Screenshot.
The grid is now in the middle (live<\/a>).<\/figcaption><\/figure>\n
We’ve also made the cube edge length $l<\/code> smaller so that the grid fits within the viewport.<\/p>\n
Alternatively, we can go for a CSS variable --l<\/code> instead so that we can control the edge length depending on the number of columns and rows. The first step here is setting the maximum of the two to a --nmax<\/code> variable:<\/p>\n
- var nr = 13, nc = 13;\r\n- var n = nr*nc;\r\n\r\n\/\/- same as before\r\n.a3d(style=`--nc: ${nc}; --nr: ${nr}; --max: ${Math.max(nc, nr)}`)\r\n  \/\/- same as before<\/code><\/pre>\n
Then, we set the edge length (--l<\/code>) to something like 80%<\/code> (completely arbitrary value) of the minimum viewport dimension over this maximum (--max<\/code>):<\/p>\n
.cube {\r\n  \/* same as before *\/\r\n  --l: calc(80vmin\/var(--max));\r\n}<\/code><\/pre>\n
Finally, we update the cube and face transforms, the face dimensions and margin<\/code> to use --l<\/code> instead of $l<\/code>:<\/p>\n
.cube {\r\n  \/* same as before *\/\r\n  --l: calc(80vmin\/var(--max));\r\n  --x: calc((var(--i) - .5*(var(--nc) - 1))*var(--l));\r\n  --y: calc((var(--j) - .5*(var(--nr) - 1))*var(--l));\r\n\t\r\n  &__face {\r\n    \/* same as before *\/\r\n    margin: calc(-.5*var(--l));\r\n    width: var(--l); height: var(--l);\r\n    transform: rotate3d(var(--i), var(--j), 0, calc(var(--m, 1)*#{$ba4gon})) \r\n               translatez(calc(.5*var(--l)));\r\n  }\r\n}<\/code><\/pre>\n
Now we have a nice responsive grid!<\/p>\n
\"Animated
The grid is now in the middle and responsive such that it always fits within the viewport (live<\/a>).<\/figcaption><\/figure>\n
But it’s an ugly one, so let’s turn it into a pretty rainbow by making the color<\/code> of each cube depend on its column index (--i<\/code>):<\/p>\n
.cube {\r\n  \/* same as before *\/\r\n  color: hsl(calc(var(--i)*360\/var(--nc)), 65%, 65%);\r\n}<\/code><\/pre>\n
\"Screenshot.
The rainbow grid (live demo<\/a>).<\/figcaption><\/figure>\n
We’ve also made the scene background dark so that we have better contrast with the now lighter cube edges.<\/p>\n
To spice things up even further, we add a row rotation around the y<\/var> axis depending on the row index (--j<\/code>):<\/p>\n
.cube {\r\n  \/* same as before *\/\r\n  transform: rotateY(calc(var(--j)*90deg\/var(--nr))) \r\n             translate(var(--x), var(--y));\r\n}<\/code><\/pre>\n
\"Screenshot.
The twisted grid (live demo<\/a>).<\/figcaption><\/figure>\n
We’ve also decreased the cube edge length --l<\/code> and increased the perspective<\/code> value in order to allow this twisted grid to fit in.<\/p>\n
Now comes the fun part! For every cube, we animate its position back and forth along the z<\/var> axis by half the grid width (we make the translate()<\/code> a translate3d()<\/code> and use an additional custom property --z<\/code> that goes between calc(.5*var(--nc)*var(--l))<\/code> and calc(-.5*var(--nc)*var(--l))<\/code>) and its size (via a uniform scale3d()<\/code> of factor --f<\/code> that goes between 1<\/code> and .1<\/code>). This is pretty much the same thing we did for the square in our original example, except the motion now happens along the z<\/var> axis, not along the x<\/var> axis and the scaling happens in 3D, not just in 2D.<\/p>\n
$t: 1s;\r\n\r\n.cube {\r\n  \/* same as before *\/\r\n  --z: calc(var(--m)*.5*var(--nc)*var(--l));\r\n  transform: rotateY(calc(var(--j)*90deg\/var(--nr))) \r\n             translate3d(var(--x), var(--y), var(--z)) \r\n             scale3d(var(--f), var(--f), var(--f));\r\n  animation: a $t ease-in-out infinite alternate;\r\n  animation-name: move, zoom;\r\n  animation-duration: $t, .5*$t;\r\n}\r\n\r\n@keyframes move { to { --m: -1 } }\r\n\r\n@keyframes zoom { to { --f: .1 } }<\/code><\/pre>\n
This doesn’t do anything until we register the multiplier --m<\/code> and the scaling factor --f<\/code> to give them a type and an initial value:<\/p>\n
CSS.registerProperty({\r\n  name: '--m', \r\n  syntax: '<number>',\r\n  initialValue: 1, \r\n  inherits: false\r\n});\r\n\r\nCSS.registerProperty({\r\n  name: '--f', \r\n  syntax: '<number>',\r\n  initialValue: 1, \r\n  inherits: false\r\n});<\/code><\/pre>\n
\"Animated
The animated grid (live demo<\/a>, needs Houdini support).<\/figcaption><\/figure>\n
At this point, all cubes animate at the same time. To make things more interesting, we add a delay that depends on both the column and row index:<\/p>\n
animation-delay: calc((var(--i) + var(--j))*#{-2*$t}\/(var(--nc) + var(--nr)));<\/code><\/pre>\n
\"Screenshot\"
The waving grid effect (live<\/a>).<\/figcaption><\/figure>\n
The final touch is to add a rotation on the 3D assembly:<\/p>\n
.a3d {\r\n  top: 50%; left: 50%;\r\n  animation: ry 8s linear infinite;\r\n}\r\n\r\n@keyframes ry { to { transform: rotateY(1turn); } }<\/code><\/pre>\n
We also make the faces opaque by giving them a black background and we have the final result:<\/p>\n
\"Animated
The final result (live demo<\/a>, needs Houdini support).<\/figcaption><\/figure>\n
The performance for this is pretty bad, as it can be seen from the GIF recording above, but it’s still interesting to see how far we can push things.<\/p>\n
Hopping Square<\/h4>\n
I came across the original<\/a> in a comment<\/a> to another article and, as soon as I saw the code, I thought it was the perfect candidate for a makeover using some Houdini magic!<\/p>\n
Let’s start by understanding what is happening in the original code.<\/p>\n
In the HTML, we have nine divs.<\/p>\n
\r\n<div class=\"frame\">\r\n  <div class=\"center\">\r\n    <div class=\"down\">\r\n      <div class=\"up\">\r\n        <div class=\"squeeze\">\r\n          <div class=\"rotate-in\">\r\n            <div class=\"rotate-out\">\r\n              <div class=\"square\"><\/div>\r\n            <\/div>\r\n          <\/div>\r\n        <\/div>\r\n      <\/div>\r\n    <\/div>\r\n    <div class=\"shadow\"><\/div>\r\n  <\/div>\r\n<\/div><\/code><\/pre>\n
Now, this animation is a lot more complex than anything I could ever come up with, but, even so, nine elements seems to be overkill. So let’s take a look at the CSS, see what they’re each used for and see how much we can simplify the code in preparation for switching to the Houdini-powered solution.<\/p>\n
Let’s start with the animated elements. The .down<\/code> and .up<\/code> elements each have an animation<\/code> related to moving the square vertically:<\/p>\n
\/* original *\/\r\n.down {\r\n  position: relative;\r\n  animation: down $duration ease-in infinite both;\r\n\r\n  .up {\r\n    animation: up $duration ease-in-out infinite both;\r\n    \/* the rest *\/\r\n  }\r\n}\r\n\r\n@keyframes down {\r\n  0% {\r\n    transform: translateY(-100px);\r\n  }\r\n  20%, 100% {\r\n    transform: translateY(0);\r\n  }\r\n}\r\n\r\n@keyframes up {\r\n  0%, 75% {\r\n    transform: translateY(0);\r\n  }\r\n  100% {\r\n    transform: translateY(-100px);\r\n  }\r\n}<\/code><\/pre>\n
With @keyframes<\/code> and animations on both elements having the same duration, we can pull off a make-one-out-of-two trick.<\/p>\n
In the case of the first set of @keyframes<\/code>, all the action (going from -100px<\/code> to 0<\/code>) happens in the [0%, 20%]<\/code> interval, while, in the case of the second one, all the action (going from 0<\/code> to -100px<\/code>) happens in the [75%, 100%]<\/code> interval. These two intervals don’t intersect. Because of this and because both animations have the same duration we can add up the translation values at each keyframe.<\/p>\n