DEV Community: Jhey Tompkins

Circular Text with CSS?

Jhey Tompkins — Thu, 23 Mar 2023 16:36:13 +0000

Have you ever wanted to lay out some text in a circle but it felt like a lot of prodding in the dark? How might you do it today? Could you do it with CSS alone in an accurate way? Let's take a look at a new way 👀

How you might solve this today

You've definitely got options. Before we go down the CSS route, you could use images. The least maintainable route could be creating an image each time you need to change the text. Make sure to use the alt attribute to describe the text that's shown.

The SVG generated in Figma, creates a path for each letter individually based on their position.

Or you could use an inline SVG. SVG has a textPath element. For the most part, it's pretty good. You give it some text and a path to lay that text on.



<svg
  viewBox="0 0 100 100"
  xmlns="http://www.w3.org/2000/svg"
>
  <path
    id="circlePath"
    d="
      M 10, 50
      a 40,40 0 1,1 80,0
      40,40 0 1,1 -80,0
    "
  />
  <text>
    <textPath href="#circlePath">
      Your text here!
    </textPath>
  </text>
</svg>

This route does pose a couple of hurdles. First, you need a path. You can't pass reference to a circle. That means converting a circle to a path.



<path
  d="
    M (CENTER_X - RADIUS),CENTER_Y
    a RADIUS,RADIUS 0 1,1 (2 * RADIUS),0
    RADIUS,RADIUS 0 1,1 (-2 * RADIUS),0
  "
/>

Next, you need to choose whether you use the textLength attribute of textPath. This can spread the text around the path. The value of this will be the circumference.



<textPath
  href="#circularPath"
  textLength={Math.floor(Math.PI * 2 * RADIUS)}
>
  Your text here!
</textPath>

Put everything together and you'll get something like this.

In this demo, you can change the text and see how the use of textLength plays a part. You can also change the radius and font size. A neat part of using SVG is that we have something scalable. Another cool feature is that the text will follow the path direction. That makes it easy to flip whether the text is inside or outside of the path. You can do that by changing the sweep flag of an arc between 1 and 0.

So SVG can do the job, right? Well, kinda. But, if you try punching in some longer text, that radius will need adjusting. And, at this point, you're prodding in the dark.

For the most part, working in code, we're somewhat wired to assume some degree of accuracy. That is, minus some rounding and other JavaScript quirks. So for me, punching numbers in until it "looks right", sometimes doesn't sit quite well with me.

Could you be more accurate with CSS? A rudimentary approach could go like this:

Split text into span elements for each character.
Set an inline custom property for the character index.
Set an inline custom property on the parent for total characters.
Using CSS calc, transform each span by rotating and then translating it using its index.
If this will be visible to screenreaders, hide all the characters with aria-hidden. Then create a visually hidden span with the full text inside it.

Here's how the HTML might look:



<span
  class="text-ring"
  style="--total: 15;"
>
  <span aria-hidden="true">
    <span style="--index: 0">Y</span>
    <span style="--index: 1">o</span>
    <span style="--index: 2">u</span>
    <!-- Obfuscated markup -->
  </span>
  <span class="sr-only">
    Your text here!
  </span>
</span>

And the CSS could go a little like this:



.text-ring {
  position: relative;
}
.text-ring [style*=--index] {
  font-size: calc(var(--font-size, 2) * 1rem);
  position: absolute;
  top: 50%;
  left: 50%;
  transform:
    translate(-50%, -50%)
    rotate(calc(360deg / var(--total) * var(--index)))
    translateY(calc(var(--radius, 5) * -1ch));
}

How do you calculate that radius though? We're still prodding in the dark. Try adjusting things until they "look right" in this demo.

Enter trigonometric functions

Try not to fear the word "trigonometric". I know, I know. When I hear it, I start thinking of "Differential equations", "Mechanics", and so on. But, some Math and leaning into font behavior is going to get us a solution.

You may have noticed the demos above use a monospace font. The benefit of doing so is that you know every character will be the same width. Think about the circle in a different way. It's actually lots of triangles around a point. A monospace font means every "side" of our circle is the same width. If you have the width of a side and the inner angle, you can calculate the hypoteneuse. That hypoteneuse is our radius!



const TOTAL_CHARACTERS = 15
const INNER_ANGLE = 360 / 15
const LENGTH_OF_SIDE = 1 // 1ch
const RADIUS = LENGTH_OF_SIDE /
  Math.sin(INNER_ANGLE / (180 / Math.PI))

A neat trick here is to define the side width using the "ch" unit. That's equal to the width of a "0" in our font. And because a monospace font is being used, that'll be the width of every character. That means we'll get a radius in "ch" units. But, changing the font-size will behave in a way that scales the text ring. Neat!

That snippet of JavaScript above gets us the radius and now we can set that in our CSS. The bonus is that if you're doing static markup generation, you can pass all the details in as inline styles. Here it is in a React component. You might server-side render this or use it in something like Astro (What this site uses).



const TextRing = (text) => {
  const CHARS = text.split('')
  const INNER_ANGLE = 360 / CHARS.length
  return (
    <span
      className="text-ring"
      style={{
        '--total': CHARS.length,
        '--radius': 1 / Math.sin(INNER_ANGLE / (180 / Math.PI))
      }}
    >
      {CHARS.map((char, index) => (
        <span style={{'--index': index }}>
          {char}
        </span>
      ))}
    </span>
  )
}

For the most part, this will do the trick. But, what if you don't like the feel of dictating your layout styles in JavaScript? Well, CSS might be able to help with that very soon.

Random fact. Not meeting the grade in advanced Mathematics in school put me on the programming path. But, that's a story for another day.

Introducing CSS trigonometry

Trigonometric functions are coming to CSS. This will give you access to functions such as sin, cos, and tan within CSS. They're already available in Firefox and Safari. They shipped in Chromium 111. Be sure to check out the "CSS Values and Units Module Level 4" spec. The introduction of these functions in CSS opens up some exciting opportunities. For example, you could use them in layouts or the timing of loading animations.

What does this mean for our circular text? CSS can now do the radius calculation. You no longer need to couple the layout styling to some JavaScript. The --radius is now calculated using sin in our CSS.



.text-ring {
  --character-width: 1; /* In "ch" units */
  --inner-angle: calc((360 / var(--total)) * 1deg);
  --radius: calc(
    (
      var(--character-width, 1) /
      sin(var(--inner-angle))
    ) * -1ch
  );
}
.text-ring [style*=--index] {
  transform:
    translate(-50%, -50%)
    rotate(calc(var(--inner-angle) * var(--index)))
    translateY(var(--radius, -5ch));
}

Plug that into our demo and we get the right radius.

If you're not in a supporting browser, you should see a warning message. You can detect CSS trigonometric function support in CSS with:



@supports (top: calc(sin(1) * 1px)) {
  /* Insert styles */
}

Or in JavaScript with:



const canTrig = CSS.supports('(top: calc(sin(1) * 1px))')

For the finishing touches, let's make our text ring spin:



@media (prefers-reduced-motion: no-preference) {
  .text-ring {
    animation: spin 6s infinite linear;
  }
  @keyframes spin {
    to {
      rotate: -360deg;
    }
  }
}

And that'll do it. Putting it all together, we can make a demo like this one.

In this demo, CSS trigonometric functions get used if supported. If not, we fall back to setting the --radius with JavaScript. For now, you could copy the HTML and CSS you need until CSS trigonometric functions get full support. The next step is getting sibling-count and sibling-index in CSS. There's a proposal for it in the CSSWG repo. Then we wouldn't need the inline custom properties anymore.

That's it! It's wild to think how the web platform is evolving. All these new features and tools that are knocking down hurdles we've faced for some time.

Until next time, stay awesome!

ʕ •ᴥ•ʔ

How to Make a Pure CSS 3D Package Toggle

Jhey Tompkins — Thu, 17 Feb 2022 01:21:31 +0000

You know how you can get cardboard boxes that come totally flat? You fold ‘em up and tape ‘em to make them into a useful box. Then when it’s time to recycle them, you cut them back apart to flatten them. Recently, someone reached out to me about essentially this concept as a 3D animation and I thought it would make an interesting tutorial to do it entirely in CSS, so here we are!

How might that animation look? How could we create that packing timeline? Could the sizing be flexible? Let’s make a pure CSS package toggle.

Here’s what we’re working towards. Tap to pack and unpack the cardboard box.

Where to start?

Where do you even start with something like this? It’s best to plan ahead. We know we’re going to have a template for our package. And that will need folding up in three dimensions. If working with 3D in CSS is new to you, I recommend this article to get you started.

If you’re familiar with 3D CSS, it might be tempting to construct a cuboid and go from there. But, that’s going to pose some problems. We need to consider how a package goes from 2D to 3D.

Let’s start by creating a template. We need to plan ahead with our markup and think about how we want our packing animation to work. Let’s start with some HTML.

<div class="scene">
  <div class="package__wrapper">
    <div class="package">
      <div class="package __side package__ side--main">
        <div class="package __flap package__ flap--top"></div>
        <div class="package __flap package__ flap--bottom"></div>
        <div class="package __side package__ side--tabbed">
          <div class="package __flap package__ flap--top"></div>
          <div class="package __flap package__ flap--bottom"></div>
        </div>
        <div class="package __side package__ side--extra">
          <div class="package __flap package__ flap--top"></div>
          <div class="package __flap package__ flap--bottom"></div>
          <div class="package __side package__ side--flipped">
            <div class="package __flap package__ flap--top"></div>
            <div class="package __flap package__ flap--bottom"></div>
          </div>
        </div>
      </div>
    </div>
  </div>
</div>

Mixins are a good idea

There’s quite a bit happening there. It’s a lot of divs. I often like to use Pug for generating markup so I can split things up into reusable blocks. For example, every side will have two flaps. We can create a Pug mixin for the sides and use attributes to apply a modifier class name to make all that markup a lot easier to write.

mixin flaps()
  .package __flap.package__ flap--top
  .package __flap.package__ flap--bottom

mixin side()
  .package__side(class=`package__side--${attributes.class || 'side'}`)
    +flaps()
    if block
      block

.scene
  .package__wrapper
    .package
      +side()(class="main")
        +side()(class="tabbed")
        +side()(class="extra")
          +side()(class="flipped")

We’re using two mixins. One creates the flaps for each side of the box. The other creates the sides of the box. Notice in the side mixin we are making use of block. That is where children of mixin usage get rendered which is particularly useful, as we need to nest some of the sides to make our lives easier later.

Our generated markup:

<div class="scene">
  <div class="package__wrapper">
    <div class="package">
      <div class="package __side package__ side--main">
        <div class="package __flap package__ flap--top"></div>
        <div class="package __flap package__ flap--bottom"></div>
        <div class="package __side package__ side--tabbed">
          <div class="package __flap package__ flap--top"></div>
          <div class="package __flap package__ flap--bottom"></div>
        </div>
        <div class="package __side package__ side--extra">
          <div class="package __flap package__ flap--top"></div>
          <div class="package __flap package__ flap--bottom"></div>
          <div class="package __side package__ side--flipped">
            <div class="package __flap package__ flap--top"></div>
            <div class="package __flap package__ flap--bottom"></div>
          </div>
        </div>
      </div>
    </div>
  </div>
</div>

Nesting the sides

Nesting the sides makes it easier to fold up our package. Much like each side has two flaps. The children of a side can inherit the sides’ transform and then apply their own. If we started with a cuboid, it would be hard to leverage this.

Check out this demo that flips between nested and non-nested elements to see the difference in action.

Each box has a transform-origin set to the bottom right corner with 100% 100%. Checking the “Transform” toggle rotates each box 90deg. But, see how the behavior of that transform changes if we nest the elements.

We’re flipping between the two versions of markup but not changing anything else.

Nested:

<div class="boxes boxes--nested">
  <div class="box">
    <div class="box">
      <div class="box">
        <div class="box"></div>
      </div>
    </div>
  </div>
</div>

Not nested:

<div class="boxes">
  <div class="box"></div>
  <div class="box"></div>
  <div class="box"></div>
  <div class="box"></div>
</div>

Transforming all the things

After applying some styles to our HTML, we have our package template.

The styles specify the different colors and position the sides to the package. Each side gets a position that’s relative to the “main” side. (You’ll see why all that nesting is useful in a moment.)

There are some things to be aware of. Much like working with cuboids, we are using --height, --width, and --depth variables for sizing. This will make it easier to change our package sizing down the line.

.package {
  height: calc(var(--height, 20) * 1vmin);
  width: calc(var(--width, 20) * 1vmin);
}

Why define sizing like this? We are using a unit-less default sizing of 20, an idea I picked up from Lea Verou’s 2016 CSS ConfAsia talk (starting at 52:44). Using custom properties as “data” instead of “values,” we are free to do what we want with them using calc(). Additionally, JavaScript doesn’t have to care about value units and we can change to pixels, a percentage, etc., without having to make changes elsewhere. You could refactor this into a coefficient in the --root, but it could also quickly become overkill.

The flaps for each side also need a size ever so smaller than the sides they are a part of. This is so we can see a slight gap as we would in real life. Also, the flaps on two sides need to sit a little lower. This is so that when we fold them up, we don’t get z-index fighting between them.

.package__flap {
  width: 99.5%;
  height: 49.5%;
  background: var(--flap-bg, var(--face-4));
  position: absolute;
  left: 50%;
  transform: translate(-50%, 0);
}
.package__flap--top {
  transform-origin: 50% 100%;
  bottom: 100%;
}
.package__flap--bottom {
  top: 100%;
  transform-origin: 50% 0%;
}
.package __side--extra > .package__ flap--bottom,
.package __side--tabbed > .package__ flap--bottom {
  top: 99%;
}
.package __side--extra > .package__ flap--top,
.package __side--tabbed > .package__ flap--top {
  bottom: 99%;
}

We’re also starting to consider the transform-origin for the individual pieces. A top flap will rotate from its bottom edge and a bottom flap will rotate from its top edge.

We can use a pseudo-element for the tab on that right side. We are using clip-path to get that desired shape.

.package__side--tabbed:after {
  content: '';
  position: absolute;
  left: 99.5%;
  height: 100%;
  width: 10%;
  background: var(--face-3);
  -webkit-clip-path: polygon(0 0%, 100% 20%, 100% 80%, 0 100%);
  clip-path: polygon(0 0%, 100% 20%, 100% 80%, 0 100%);
  transform-origin: 0% 50%;
}

Let’s start working with our template on a 3D plane. We can start by rotating the .scene on the X and Y axis.

.scene {
  transform: rotateX(-24deg) rotateY(-32deg) rotateX(90deg);
}

Folding up

We’re ready to start folding up our template! Our template will fold up based on a custom property, --packaged. If the value is 1, then we can fold up the template. For example, let’s fold some of the sides and the pseudo-element tab.

.package__side--tabbed,
.package__side--tabbed:after {
  transform: rotateY(calc(var(--packaged, 0) * -90deg));
}
.package__side--extra {
  transform: rotateY(calc(var(--packaged, 0) * 90deg));
}

Or, we could write a rule for all sides that aren’t the “main” one.

.package__side:not(.package__side--main),
.package__side:not(.package__side--main):after {
  transform: rotateY(calc((var(--packaged, 0) * var(--rotation, 90)) * 1deg));
}
.package__side--tabbed { --rotation: -90; }

And that would cover all the sides.

Remember when I said the nested sides allow us to inherit a parent’s transform? If we update our demo so we can change the value of --packaged, we can see how the value affects the transforms. Try sliding the --packaged value between 1 and 0 and you’ll see exactly what I mean.

Now that we have a way to toggle the folding state of our template, we can start working on some motion. Our previous demo flips between the two states. We can make use of transition for that. The quickest way? Add a transition to the transform of every child in the .scene.

.scene *,
.scene *::after {
  transition: transform calc(var(--speed, 0.2) * 1s);
}

Multi-step transitions!

But we don’t fold the template all up in one go — in real life, there’s a sequence to it where we’d fold up one side and its flap first then move on to the next, and so on. Scoped custom properties are perfect for this.

.scene *,
.scene *::after {
  transition: transform calc(var(--speed, 0.2) * 1s) calc((var(--step, 1) * var(--delay, 0.2)) * 1s);
}

Here we are saying that, for each transition, use a transition-delay of --step multiplied by --delay. The --delay value won’t change but each element can define which “step” it is in the sequence. And then we can be explicit about the order in which things happen.

.package__side--extra {
  --step: 1;
}
.package__side--tabbed {
  --step: 2;
}
.package__side--flipped,
.package__side--tabbed::after {
  --step: 3;
}

Consider the following demo for a better idea of how this works. Change the slider values to update the order in which things happen. Can you change which car wins?

That same technique is key for what we are going to for. We could even introduce an --initial-delay that adds a slight pause to everything for even more realism.

.race__light--animated,
.race__light--animated:after,
.car {
  animation-delay: calc((var(--step, 0) * var(--delay-step, 0)) * 1s);
}

If we look back at our package, we can take this further and apply a “step” to all the elements that are going to transform. It’s quite verbose but it does the job. Alternatively, you could inline these values in the markup.

.package __side--extra > .package__ flap--bottom {
  --step: 4;
}
.package __side--tabbed > .package__ flap--bottom {
  --step: 5;
}
.package __side--main > .package__ flap--bottom {
  --step: 6;
}
.package __side--flipped > .package__ flap--bottom {
  --step: 7;
}
.package __side--extra > .package__ flap--top {
  --step: 8;
}
.package __side--tabbed > .package__ flap--top {
  --step: 9;
}
.package __side--main > .package__ flap--top {
  --step: 10;
}
.package __side--flipped > .package__ flap--top {
  --step: 11;
}

But, it doesn’t feel very realistic.

Maybe we oughta flip the box, too

If I were folding up the box in real life, I’d likely flip the box up before folding in the top flaps. So how might we do that? Well, those with an eager eye might have noticed the .package__wrapper element. We are going to use this to slide the package. Then we’re going to rotate the package on the x-axis. This will create the impression of flipping the package onto its side.

.package {
  transform-origin: 50% 100%;
  transform: rotateX(calc(var(--packaged, 0) * -90deg));
}
.package__wrapper {
  transform: translate(0, calc(var(--packaged, 0) * -100%));
}

Adjusting the --step declarations accordingly gives us something like this.

Unfolding the box

If you flip between the folded and not folded states, you’ll notice that the unfold doesn’t look right. The unfolding sequence should be the exact reverse of the folding sequence. We could flip the --step based on --packaged and the number of steps. Our latest step is 15. We can update our transition to this:

.scene *,
.scene *:after {
  --no-of-steps: 15;
  --step-delay: calc(var(--step, 1) - ((1 - var(--packaged, 0)) * (var(--step) - ((var(--no-of-steps) + 1) - var(--step)))));
  transition: transform calc(var(--speed, 0.2) * 1s) calc((var(--step-delay) * var(--delay, 0.2)) * 1s);
}

That is quite the mouthful of calc to reverse the transition-delay. But, it works! We must remind ourselves to keep that --no-of-steps value up to date though!

We do have another option. As we continue down the “pure CSS” route, we will eventually make use of the checkbox hack to toggling between the folding states. We could have two sets of defined “steps” where one set is active when our checkbox gets checked. It’s certainly a more verbose solution. But, it does give us more finite control.

/* Folding */
:checked ~ .scene .package__side--extra {
  --step: 1;
}
/* Unfolding */
.package__side--extra {
  --step: 15;
}

Sizing and centering

Before we ditch the use of dat.gui in our demo, let’s have a play with the size of our package. We want to check that our package remains centered while folding and flipping. In this demo, the package has a larger --height and the .scene has a dashed border.

We may as well tweak our transform to better center the package while we’re at it:

/* Considers package height by translating on z-axis */
.scene {
  transform: rotateX(calc(var(--rotate-x, -24) * 1deg)) rotateY(calc(var(--rotate-y, -32) * 1deg)) rotateX(90deg) translate3d(0, 0, calc(var(--height, 20) * -0.5vmin));
}
/* Considers package depth by sliding the depth before flipping */
.package__wrapper {
  transform: translate(0, calc((var(--packaged, 0) * var(--depth, 20)) * -1vmin));
}

This gives us reliable centering in the scene. It all comes down to preference though!

Adding in the checkbox hack

Now let’s get dat.gui out of the way and make this “pure” CSS. For this, we need to introduce a bunch of controls in the HTML. We are going to use a checkbox for folding and unfolding our package. Then we’re going to use a radio button to pick a package size.

<input id="package" type="checkbox"/>

<input id="one" type="radio" name="size"/>
<label class="size-label one" for="one">S</label>

<input id="two" type="radio" name="size" checked="checked"/>
<label class="size-label two" for="two">M</label>

<input id="three" type="radio" name="size"/>
<label class="size-label three" for="three">L</label>

<input id="four" type="radio" name="size"/>
<label class="size-label four" for="four">XL</label>

<label class="close" for="package">Close Package</label>
<label class="open" for="package">Open Package</label>

In the final demo, we will hide the inputs and make use of the label elements. For now, though, let’s leave them all visible. The trick is to use the sibling combinator (~) when certain controls get :checked. We can then set custom property values on the .scene.

#package:checked ~ .scene {
  --packaged: 1;
}
#one:checked ~ .scene {
  --height: 10;
  --width: 20;
  --depth: 20;
}
#two:checked ~ .scene {
  --height: 20;
  --width: 20;
  --depth: 20;
}
#three:checked ~ .scene {
  --height: 20;
  --width: 30;
  --depth: 20;
}
#four:checked ~ .scene {
  --height: 30;
  --width: 20;
  --depth: 30;
}

And here is the demo with that working!

Final polish

Now we’re in a place to make things look “pretty” and add some extra touches. Let’s start by hiding all the inputs.

input {
  position: fixed;
  top: 0;
  left: 0;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip: rect(0, 0, 0, 0);
  white-space: nowrap;
  border-width: 0;
}

We can style the sizing options as rounded buttons:

.size-label {
  position: fixed;
  top: var(--top);
  right: 1rem;
  z-index: 3;
  font-family: sans-serif;
  font-weight: bold;
  color: #262626;
  height: 44px;
  width: 44px;
  display: grid;
  place-items: center;
  background: #fcfcfc;
  border-radius: 50%;
  cursor: pointer;
  border: 4px solid #8bb1b1;
  transform: translate(0, calc(var(--y, 0) * 1%)) scale(var(--scale, 1));
  transition: transform 0.1s;
}
.size-label:hover {
  --y: -5;
}
.size-label:active {
  --y: 2;
  --scale: 0.9;
}

We want to be able to tap anywhere to toggle between folding and unfolding our package. So our .open and .close labels will take up the full screen. Wondering why we have two labels? It’s a little trick. If we use a transition-delay and scale up the appropriate label, we can hide both labels while the package transitions. This is how we combat spam tapping (even though it won’t stop a user hitting the space bar on a keyboard).

.close,
.open {
  position: fixed;
  height: 100vh;
  width: 100vw;
  z-index: 2;
  transform: scale(var(--scale, 1)) translate3d(0, 0, 50vmin);
  transition: transform 0s var(--reveal-delay, calc(((var(--no-of-steps, 15) + 1) * var(--delay, 0.2)) * 1s));
}

#package:checked ~ .close,
.open {
  --scale: 0;
  --reveal-delay: 0s;
}
#package:checked ~ .open {
  --scale: 1;
  --reveal-delay: calc(((var(--no-of-steps, 15) + 1) * var(--delay, 0.2)) * 1s);
}

Check out this demo to see where we’ve added background-color to both .open and .close. Neither label is visible during the transition.

We’ve got complete functionality! But, our package is a little underwhelming at the moment. Let’s add extra details to make things more “box”-like with things like parcel tape and packing labels.

Little details like this are only limited by our imagination! We can use our --packaged custom property to affect anything. For example, the .package__tape is transitioning the scaleY transform:

.package__tape {
  transform: translate3d(-50%, var(--offset-y), -2px) scaleX(var(--packaged, 0));
}

The thing to remember is that whenever we add a new feature that affects the sequence, we need to update our steps. Not only the --step values, but also the --no-of-steps value.

That’s it!

That’s how you make a pure CSS 3D package toggle. Are you going to drop this into your website? Unlikely! But, it’s fun to see how you might achieve these things with CSS. Custom properties are so powerful.

Why not get super festive and give the gift of CSS!

Stay Awesome! ʕ •ᴥ•ʔ

3D CSS Flippy Snaps with React && GreenSock

Jhey Tompkins — Mon, 10 Jan 2022 15:32:33 +0000

One of Jhey’s main mantras is to make learning fun. In this article, he shows you ways to level up your skills by bringing your ideas to life, and not forgetting that you can be playful with code. With that mindset, every idea is bound to become an opportunity to try something new.

Naming things is hard, right? "Flippy Snaps" was the best thing I could come up with 😂 I saw an effect like this on TV one evening and made a note to myself to make something similar. Although this isn't something I'd look to drop on a website any time soon, it's a neat little challenge to make. It fits in with my whole stance on "Playfulness in Code" to learn. Anyway, a few days later, I sat down at the keyboard, and a couple of hours later I had this.

// Detect dark theme var iframe = document.getElementById('tweet-1457830342413455369-541'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1457830342413455369&theme=dark" }

My final demo is a React app, but we don't need to dig into using React to explain the mechanics of making this work. We will create the React app once we’ve established how to make things work.

NOTE:: Before we get started. It’s worth noting that performance of this demo is affected by the grid size and the demos are best viewed in Chromium based browsers.

Let's start by creating a grid. Let's say we want a 10 by 10 grid. That's 100 cells (This is why React is handy for something like this). Each cell is going to consist of an element that contains the front and back for a flippable card.

<div class="flippy-snap">
  <!-- 100 of these -->
  <div class="flippy-snap__card flippy-card">
    <div class="flippy-card__front></div>
    <div class="flippy-card__rear></div>
  </div>
</div>

The styles for our grid are quite straightforward. We can use display: grid and use a custom property for the grid size. Here we are defaulting to 10.

.flippy-snap {
  display: grid;
  grid-gap: 1px;
  grid-template-columns: repeat(var(--grid-size, 10), 1fr);
  grid-template-rows: repeat(var(--grid-size, 10), 1fr);
}

We won’t use grid-gap in the final demo, but, it’s good for seeing the cells easier whilst developing.

Next, we need to style the sides to our cards and display images. We can do this by leveraging inline CSS custom properties. Let's start by updating the markup. We need each card to know its x and y position in the grid.

<div class="flippy-snap">
  <div class="flippy-snap__card flippy-card" style="--x: 0; --y: 0;">
    <div class="flippy-card__front"></div>
    <div class="flippy-card__rear"></div>
  </div>
  <div class="flippy-snap__card flippy-card" style="--x: 1; --y: 0;">
    <div class="flippy-card__front"></div>
    <div class="flippy-card__rear"></div>
  </div>
  <!-- Other cards -->
</div>

For the demo, I'm using Pug to generate this for me. You can see the compiled HTML by clicking “View Compiled HTML” in the demo.

- const GRID_SIZE = 10
- const COUNT = Math.pow(GRID_SIZE, 2)
.flippy-snap
  - for(let f = 0; f < COUNT; f++)
    - const x = f % GRID_SIZE
    - const y = Math.floor(f / GRID_SIZE)
    .flippy-snap__card.flippy-card(style=`--x: ${x}; --y: ${y};`)
      .flippy-card__front
      .flippy-card__rear

Then we need some styles.

.flippy-card {
  --current-image: url("https://random-image.com/768");
  --next-image: url("https://random-image.com/124");
  height: 100%;
  width: 100%;
  position: relative;
}
.flippy-card__front,
.flippy-card__rear {
  position: absolute;
  height: 100%;
  width: 100%;
  backface-visibility: hidden;
  background-image: var(--current-image);
  background-position: calc(var(--x, 0) * -100%) calc(var(--y, 0) * -100%);
  background-size: calc(var(--grid-size, 10) * 100%);
}
.flippy-card__rear {
  background-image: var(--next-image);
  transform: rotateY(180deg) rotate(180deg);
}

The rear of the card gets its position using a combination of rotations via transform. But, the interesting part is how we show the image part for each card. In this demo, we are using a custom property to define the URLs for two images. And then we set those as the background-image for each card face. But the trick is how we define the background-size and background-position. Using the custom properties --x and --y we multiply the value by -100%. And then we set the background-size to --grid-size multiplied by 100%. This gives displays the correct part of the image for a given card.

You may have noticed that we had --current-image and --next-image. But, currently, there is no way to see the next image. For that, we need a way to flip our cards. We can use another custom property for this. Let's introduce a --count property and set a transform for our cards.

.flippy-snap {
  --count: 0;
  perspective: 50vmin;
}
.flippy-card {
  transform: rotateX(calc(var(--count) * -180deg));
  transition: transform 0.25s;
  transform-style: preserve-3d;
}

We can set the --count property on the containing element. Scoping means all the cards can pick up that value and use it to transform their rotation on the x-axis. We also need to set transform-style: preserve-3d so that we see the back of the cards. Setting a perspective gives us that 3D perspective.

This demo lets you update the --count property value so you can see the effect it has.

At this point, you could wrap it up there and set a simple click handler that increments --count by one on each click.

const SNAP = document.querySelector('.flippy-snap')
let count = 0
const UPDATE = () => SNAP.style.setProperty('--count', count++)
SNAP.addEventListener('click', UPDATE)

Remove the grid-gap and you'd get this. Click the snap to flip it.

Now we have the basic mechanics worked out, it's time to turn this into a React app. There's a bit to break down here.

const App = () => {
  const [snaps, setSnaps] = useState([])
  const [disabled, setDisabled] = useState(true)
  const [gridSize, setGridSize] = useState(9)
  const snapRef = useRef(null)

  const grabPic = async () => {
    const pic = await fetch('https://source.unsplash.com/random/1000x1000')
    return pic.url
  }

  useEffect(() => {
    const setup = async () => {
      const url = await grabPic()
      const nextUrl = await grabPic()
      setSnaps([url, nextUrl])
      setDisabled(false)
    }
    setup()
  }, [])

  const setNewImage = async count => {
    const newSnap = await grabPic()
    setSnaps(
      count.current % 2 !== 0 ? [newSnap, snaps[1]] : [snaps[0], newSnap]
    )
    setDisabled(false)
  }

  const onFlip = async count => {
    setDisabled(true)
    setNewImage(count)
  }

  if (snaps.length !== 2) return <h1 className="loader">Loading...</h1>

  return (
    <FlippySnap
      gridSize={gridSize}
      disabled={disabled}
      snaps={snaps}
      onFlip={onFlip}
      snapRef={snapRef}
    />
  )
}

Our App component handles grabbing images and passing them to our FlippySnap component. That's the bulk of what's happening here. For this demo, we're grabbing images from Unsplash.

const grabPic = async () => {
  const pic = await fetch('https://source.unsplash.com/random/1000x1000')
  return pic.url
}

// Initial effect grabs two snaps to be used by FlippySnap
useEffect(() => {
  const setup = async () => {
    const url = await grabPic()
    const nextUrl = await grabPic()
    setSnaps([url, nextUrl])
    setDisabled(false)
  }
  setup()
}, [])

If there aren't two snaps to show, then we show a "Loading..." message.

if (snaps.length !== 2) return <h1 className="loader">Loading...</h1>

If we are grabbing a new image, we need to disable FlippySnap so we can't spam click it.

<FlippySnap
  gridSize={gridSize}
  disabled={disabled} // Toggle a "disabled" prop to stop spam clicks
  snaps={snaps}
  onFlip={onFlip}
  snapRef={snapRef}
/>

We're letting App dictate the snaps that get displayed by FlippySnap and in which order. On each flip, we grab a new image, and depending on how many times we've flipped, we set the correct snaps. The alternative would be to set the snaps and let the component figure out the order.

const setNewImage = async count => {
  const newSnap = await grabPic() // Grab the snap
  setSnaps(
    count.current % 2 !== 0 ? [newSnap, snaps[1]] : [snaps[0], newSnap]
  ) // Set the snaps based on the current "count" which we get from FlippySnap
  setDisabled(false) // Enable clicks again
}

const onFlip = async count => {
  setDisabled(true) // Disable so we can't spam click
  setNewImage(count) // Grab a new snap to display
}

How might FlippySnap look? There isn’t much to it at all!

const FlippySnap = ({ disabled, gridSize, onFlip, snaps }) => {
  const CELL_COUNT = Math.pow(gridSize, 2)
  const count = useRef(0)

  const flip = e => {
    if (disabled) return
    count.current = count.current + 1
    if (onFlip) onFlip(count)
  }

  const buttonStyle = {
    "--grid-size": gridSize,
    "--count": count.current,
    "--current-image": `url('${snaps[0]}')`,
    "--next-image": `url('${snaps[1]}')`,
  }

  return (
    <button
      className="flippy-snap"
      ref={containerRef}
      style={buttonStyle}>
      {new Array(CELL_COUNT).fill().map((cell, index) => {
        const x = index % gridSize
        const y = Math.floor(index / gridSize)
        const cellStyle = {
          "--x": x,
          "--y": y,
        }
        return (
          <span
            key={index}
            className="flippy-card"
            style={cellStyle}>
            <span className="flippy-card__front"></span>
            <span className="flippy-card__rear"></span>
          </span>
        )
      }}
    </button>
  )
}

The component handles rendering all the cards and setting the inline custom properties. The onClick handler for the container increments the count. It also triggers the onFlip callback. If the state is currently disabled, it does nothing. That flip of the disabled state and grabbing a new snap triggers the flip when the component re-renders.

We have a React component that will now flip through images for as long as we want to keep requesting new ones. But, that flip transition is a bit boring. To spice it up, we're going to make use of GreenSock and it's utilities. In particular, the "distribute" utility. This will allow us to distribute the delay of flipping our cards in a grid like burst from wherever we click. To do this, we're going to use GreenSock to animate the --count value on each card.

It's worth noting that we have a choice here. We could opt to apply the styles with GreenSock. Instead of animating the --count property value, we could animate rotateX. We could do this based on the count ref we have. And this also goes for any other things we choose to animate with GreenSock in this article. It's down to preference and use case. You may feel that updating the custom property value makes sense. The benefit being that you don't need to update any JavaScript to get a different styled behavior. We could change the CSS to use rotateY for example.

Our updated flip function could look like this:

const flip = e => {
  if (disabled) return
  const x = parseInt(e.target.parentNode.getAttribute('data-snap-x'), 10)
  const y = parseInt(e.target.parentNode.getAttribute('data-snap-y'), 10)
  count.current = count.current + 1
  gsap.to(containerRef.current.querySelectorAll('.flippy-card'), {
    '--count': count.current,
    delay: gsap.utils.distribute({
      from: [x / gridSize, y / gridSize],
      amount: gridSize / 20,
      base: 0,
      grid: [gridSize, gridSize],
      ease: 'power1.inOut',
    }),
    duration: 0.2,
    onComplete: () => {
      // At this point update the images
      if (onFlip) onFlip(count)
    },
  })
}

Note how we're getting an x and y value by reading attributes of the clicked card. For this demo, we've opted for adding some data attributes to each card. These attributes communicate a cards position in the grid. We’re also using a new ref called containerRef. This is so we reference only the cards for a FlippySnap instance when using GreenSock.

{new Array(CELL_COUNT).fill().map((cell, index) => {
  const x = index % gridSize
  const y = Math.floor(index / gridSize)
  const cellStyle = {
    "--x": x,
    "--y": y,
  }
  return (
    <span
      className="flippy-card"
      data-snap-x={x}
      data-snap-y={y}
      style={cellStyle}>
      <span className="flippy-card__front"></span>
      <span className="flippy-card__rear"></span>
    </span>
  )
})}

Once we get those x and y values, we can make use of them in our animation. Using gsap.to we want to animate the --count custom property for every .flippy-card that's a child of containerRef.

To distribute the delay from where we click, we set the value of delay to use gsap.utils.distribute. The from value of the distribute function takes an Array containing ratios along the x and y axis. To get this, we divide x and y by gridSize. The base value is the initial value. For this, we want 0 delay on the card we click. The amount is the largest value. We've gone for gridSize / 20 but you could experiment with different values. Something based on the gridSize is a good idea though. The grid value tells GreenSock the grid size to use when calculating distribution. Last but not least, the ease defines the ease of the delay distribution.

gsap.to(containerRef.current.querySelectorAll('.flippy-card'), {
  '--count': count.current,
  delay: gsap.utils.distribute({
    from: [x / gridSize, y / gridSize],
    amount: gridSize / 20,
    base: 0,
    grid: [gridSize, gridSize],
    ease: 'power1.inOut',
  }),
  duration: 0.2,
  onComplete: () => {
    // At this point update the images
    if (onFlip) onFlip(count)
  },
})

As for the rest of the animation, we are using a flip duration of 0.2 seconds. And we make use of onComplete to invoke our callback. We pass the flip count to the callback so it can use this to determine snap order. Things like the duration of the flip could get configured by passing in different props if we wished.

Putting it all together gives us this:

Those that like to push things a bit might have noticed that we can still "spam" click the snap. And that's because we don't disable FlippySnap until GreenSock has completed. To fix this, we can use an internal ref that we toggle at the start and end of using GreenSock.

const flipping = useRef(false) // New ref to track the flipping state

const flip = e => {
  if (disabled || flipping.current) return
  const x = parseInt(e.target.parentNode.getAttribute('data-snap-x'), 10)
  const y = parseInt(e.target.parentNode.getAttribute('data-snap-y'), 10)
  count.current = count.current + 1
  gsap.to(containerRef.current.querySelectorAll('.flippy-card'), {
    '--count': count.current,
    delay: gsap.utils.distribute({
      from: [x / gridSize, y / gridSize],
      amount: gridSize / 20,
      base: 0,
      grid: [gridSize, gridSize],
      ease: 'power1.inOut',
    }),
    duration: 0.2,
    onStart: () => {
      flipping.current = true
    },
    onComplete: () => {
      // At this point update the images
      flipping.current = false
      if (onFlip) onFlip(count)
    },
  })
}

And now we can no longer spam click our FlippySnap!

Now it's time for some extra touches. At the moment, there's no visual sign that we can click our FlippySnap. What if when we hover, the cards raise towards us? We could use onPointerOver and use the "distribute" utility again.

const indicate = e => {
  const x = parseInt(e.currentTarget.getAttribute('data-snap-x'), 10)
  const y = parseInt(e.currentTarget.getAttribute('data-snap-y'), 10)
  gsap.to(containerRef.current.querySelectorAll('.flippy-card'), {
    '--hovered': gsap.utils.distribute({
      from: [x / gridSize, y / gridSize],
      base: 0,
      amount: 1,
      grid: [gridSize, gridSize],
      ease: 'power1.inOut'
    }),
    duration: 0.1,
  })
}

Here, we are setting a new custom property on each card named --hovered. This is set to a value from 0 to 1. Then within our CSS, we are going to update our card styles to watch for the value.

.flippy-card {
  transform: translate3d(0, 0, calc((1 - (var(--hovered, 1))) * 5vmin))
              rotateX(calc(var(--count) * -180deg));
}

Here we are saying a card will move on the z-axis at most 5vmin.

We then apply this to each card using the onPointerOver prop.

{new Array(CELL_COUNT).fill().map((cell, index) => {
  const x = index % gridSize
  const y = Math.floor(index / gridSize)
  const cellStyle = {
    "--x": x,
    "--y": y,
  }
  return (
    <span
      onPointerOver={indicate}
      className="flippy-card"
      data-snap-x={x}
      data-snap-y={y}
      style={cellStyle}>
      <span className="flippy-card__front"></span>
      <span className="flippy-card__rear"></span>
    </span>
  )
})}

And when our pointer leaves our FlippySnap we want to reset our card positions.

const reset = () => {
  gsap.to(containerRef.current.querySelectorAll('.flippy-card'), {
    '--hovered': 1,
    duration: 0.1,
  })
}

And we can apply this with the onPointerLeave prop.

<button
  className="flippy-snap"
  ref={containerRef}
  onPointerLeave={reset}
  style={buttonStyle}
  onClick={flip}>

Put that all together and we get something like this. Try moving your pointer over it.

What next? How about a loading indicator so we know when our App is grabbing the next image? We can render a loading spinner when our FlippySnap is disabled.

{disabled && <span className='flippy-snap__loader'></span>}

The styles for which could make a rotating circle.

.flippy-snap__loader {
  border-radius: 50%;
  border: 6px solid #fff;
  border-left-color: #000;
  border-right-color: #000;
  position: absolute;
  right: 10%;
  bottom: 10%;
  height: 8%;
  width: 8%;
  transform: translate3d(0, 0, 5vmin) rotate(0deg);
  animation: spin 1s infinite;
}
@keyframes spin {
  to {
    transform: translate3d(0, 0, 5vmin) rotate(360deg);
  }
}

And this gives us a loading indicator when grabbing a new image.

That's it!

That's how we can create a FlippySnap with React and GreenSock. It's fun to make things that we may not create on a day to day basis. Demos like this can pose different challenges and can level up your problem solving game.

I took it a little further and added a slight parallax effect along with some audio. You can also configure the grid size! Big grids affect performance though. It’s also worth noting that this demo works best in Chromium based browsers. Where would you take it next? I'd like to see if I can recreate it with ThreeJS next. That’ll address the performance 😅

Stay Awesome! ʕ •ᴥ•ʔ

Parallax Powered by CSS Custom Properties

Jhey Tompkins — Mon, 10 Jan 2022 15:20:11 +0000

Good friend Kent C. Dodds has recently dropped his new website which had a lot of work go into it. I was fortunate enough that Kent reached out a while back and asked if I could come up with some "whimsy" for the site. ✨

One of the first things that drew my attention was the large image of Kody (🐨) on the landing page. He's surrounded by objects and that, to me, screamed, "Make me move!"

I have built parallax-style scenes before that respond to cursor movement, but not to this scale and not for a React application. The neat thing about this? We can power the whole thing with only two CSS custom properties.

Let's start by grabbing our user's cursor position. This is as straightforward as:

const UPDATE = ({ x, y }) => {
  document.body.innerText = `x: ${x}; y: ${y}`
}
document.addEventListener('pointermove', UPDATE)

We want to map these values around a center point. For example, the left side of the viewport should be -1 for x, and 1 for the right side. We can reference an element and work out the value from its center using a mapping function. In this project, I was able to use GSAP and that meant using some of its utility functions. They already provide a mapRange() function for this purpose. Pass in two ranges and you'll get a function you can use to get the mapped value.

const mapRange = (inputLower, inputUpper, outputLower, outputUpper) => {
  const INPUT_RANGE = inputUpper - inputLower
  const OUTPUT_RANGE = outputUpper - outputLower
  return value => outputLower + (((value - inputLower) / INPUT_RANGE) * OUTPUT_RANGE || 0)
}
// const MAPPER = mapRange(0, 100, 0, 10000)
// MAPPER(50) === 5000

What if we want to use the window as the container element? We can map the value to the width and height of it.

import gsap from 'https://cdn.skypack.dev/gsap'

const BOUNDS = 100

const UPDATE = ({ x, y }) => {
  const boundX = gsap.utils.mapRange(0, window.innerWidth, -BOUNDS, BOUNDS, x)
  const boundY = gsap.utils.mapRange(0, window.innerHeight, -BOUNDS, BOUNDS, y)
  document.body.innerText = `x: ${Math.floor(boundX) / 100}; y: ${Math.floor(boundY) / 100};`
}

document.addEventListener('pointermove', UPDATE)

That gives us a range of x and y values that we can plug into our CSS. Note how we are dividing the values by 100 to get a fractional value. This should make sense when we integrate these values with our CSS a little later.

Now, what if we have an element that we want to map that value against, and within a certain proximity? In other words, we want our handler to look up the position of the element, work out the proximity range, and then map the cursor position to that range. The ideal solution here is to create a function that generates our handler for us. Then we can reuse it. For the purpose of this article, though, we’re operating on a “happy path” where we are avoiding type checks or checking for the callback value, etc.

const CONTAINER = document.querySelector('.container')

const generateHandler = (element, proximity, cb) => ({x, y}) => {
  const bounds = 100
  const elementBounds = element.getBoundingClientRect()
  const centerX = elementBounds.left + elementBounds.width / 2
  const centerY = elementBounds.top + elementBounds.height / 2
  const boundX = gsap.utils.mapRange(centerX - proximity, centerX + proximity, -bounds, bounds, x)
  const boundY = gsap.utils.mapRange(centerY - proximity, centerY + proximity, -bounds, bounds, y)
  cb(boundX / 100, boundY / 100)
}

document.addEventListener('pointermove', generateHandler(CONTAINER, 100, (x, y) => {
  CONTAINER.innerText = `x: ${x.toFixed(1)}; y: ${y.toFixed(1)};`
}))

In this demo, our proximity is 100 . We’ll style it with a blue background to make it obvious. We pass a callback that gets fired each time the values for x and y get mapped to the bounds. We can divide these values in the callback or do what we want with them.

But wait, there's an issue with that demo. The values go outside the bounds of -1 and 1. We need to clamp those values. GreenSock has another utility method we can use for this. It's the equal of using a combination of Math.min and Math.max. As we already have the dependency, there's no point in reinventing the wheel! We could clamp the values in the function. But, choosing to do so in our callback will be more flexible as we’ll show coming up.

We could do this with CSS clamp() if we’d like. 😉

document.addEventListener('pointermove', generateHandler(CONTAINER, 100, (x, y) => {
  CONTAINER.innerText = `
    x: ${gsap.utils.clamp(-1, 1, x.toFixed(1))};
    y: ${gsap.utils.clamp(-1, 1, y.toFixed(1))};
  `
}))

Now we have clamped values!

In this demo, adjust the proximity and drag the container around to see how the handler holds up.

That's the majority of JavaScript for this project! All that's left to do is pass these values to CSS-land. And we can do that in our callback. Let’s use custom properties named ratio-x and ratio-y.

const UPDATE = (x, y) => {
  const clampedX = gsap.utils.clamp(-1, 1, x.toFixed(1))
  const clampedY = gsap.utils.clamp(-1, 1, y.toFixed(1))
  CONTAINER.style.setProperty('--ratio-x', clampedX)
  CONTAINER.style.setProperty('--ratio-y', clampedY)
  CONTAINER.innerText = `x: ${clampedX}; y: ${clampedY};`
}

document.addEventListener('pointermove', generateHandler(CONTAINER, 100, UPDATE))

Now that we have some values we can use in our CSS, we can combine them with calc() any way we like. For example, this demo changes the scale of the container element based on the y value. It then updates the hue of the container based on the x value.

The neat thing here is that the JavaScript doesn't care about what you do with the values. It's done its part. That's the magic of using scoped custom properties.

.container {
  --hue: calc(180 - (var(--ratio-x, 0) * 180));
  background: hsl(var(--hue, 25), 100%, 80%);
  transform: scale(calc(2 - var(--ratio-y, 0)));
}

Another interesting point is considering whether you want to clamp the values or not. In this demo, if we didn't clamp x, we could have the hue update wherever we are on the page.

Making a scene

We have the technique in place! Now we can do pretty much whatever we want with it. It's kinda wherever your imagination takes you. I've used this same set up for a bunch of things.

Our demos so far have only made changes to the containing element. But, as we may as well mention again, the power of custom property scope is epic.

My task was to make things move on Kent’s site. When I first saw the image of Kody with a bunch of objects, I could see all the individual pieces doing their own thing—all powered by those two custom properties that we pass in. How might that look though? The key is inline custom properties for each child of our container.

For now, we could update our markup to include some children:

<div class="container">
  <div class="container__item"></div>
  <div class="container__item"></div>
  <div class="container__item"></div>
</div>

Then we update the styles to include some scoped styles for container__item:

.container__item {
  position: absolute;
  top: calc(var(--y, 0) * 1%);
  left: calc(var(--x, 0) * 1%);
  height: calc(var(--size, 20) * 1px);
  width: calc(var(--size, 20) * 1px);
  background: hsl(var(--hue, 0), 80%, 80%);
  transition: transform 0.1s;
  transform:
    translate(-50%, -50%)
    translate(
      calc(var(--move-x, 0) * var(--ratio-x, 0) * 100%),
      calc(var(--move-y, 0) * var(--ratio-y, 0) * 100%)
    )
    rotate(calc(var(--rotate, 0) * var(--ratio-x, 0) * 1deg))
  ;
}

The important part there is how we're making use of --ratio-x and --ratio-y inside the transform. Each item declares its own level of movement and rotation via --move-x , etc. Each item is also positioned with scoped custom properties, --x and --y.

That's the key to these CSS powered parallax scenes. It's all about bouncing coefficients against each other!

If we update our markup with some inline values for those properties, here’s what we get:

<div class="container">
  <div class="container__item" style="--move-x: -1; --rotate: 90; --x: 10; --y: 60; --size: 30; --hue: 220;"></div>
  <div class="container__item" style="--move-x: 1.6; --move-y: -2; --rotate: -45; --x: 75; --y: 20; --size: 50; --hue: 240;"></div>
  <div class="container__item" style="--move-x: -3; --move-y: 1; --rotate: 360; --x: 75; --y: 80; --size: 40; --hue: 260;"></div>
</div>

Leveraging that scope, we can get something like this! That’s pretty neat. It almost looks like a shield.

But, how do you take a static image and turn it into a responsive parallax scene? First, we're going to have to create all those child elements and position them. And to do this we can use the "tracing" technique we use with CSS art.

This next demo shows the image we’re using inside a parallax container with children. To explain this part, we've created three children and given them a red background. The image is fixed with a reduced opacity and lines up with our parallax container.

Each parallax item gets created from a CONFIG object. For this demo, I'm using Pug to generate these in HTML for brevity. In the final project, I'm using React which we can show later. Using Pug here saves me writing out all the inline CSS custom properties individually.

-
  const CONFIG = [
    {
      positionX: 50,
      positionY: 55,
      height: 59,
      width: 55,
    },
    {
      positionX: 74,
      positionY: 15,
      height: 17,
      width: 17,
    },
    {
      positionX: 12,
      positionY: 51,
      height: 24,
      width: 19,
    }
  ]

img(src="https://assets.codepen.io/605876/kody-flying_blue.png")
.parallax
  - for (const ITEM of CONFIG)
    .parallax__item(style=`--width: ${ITEM.width}; --height: ${ITEM.height}; --x: ${ITEM.positionX}; --y: ${ITEM.positionY};`)

How do we get those values? It's a lot of trial and error and is definitely time consuming. To make it responsive, the positioning and sizing use percentage values.

.parallax {
  height: 50vmin;
  width: calc(50 * (484 / 479) * 1vmin); // Maintain aspect ratio where 'aspect-ratio' doesn't work to that scale.
  background: hsla(180, 50%, 50%, 0.25);
  position: relative;
}

.parallax__item {
  position: absolute;
  left: calc(var(--x, 50) * 1%);
  top: calc(var(--y, 50) * 1%);
  height: calc(var(--height, auto) * 1%);
  width: calc(var(--width, auto) * 1%);
  background: hsla(0, 50%, 50%, 0.5);
  transform: translate(-50%, -50%);
}

Once we’ve made elements for all the items, we get something like the following demo. This uses the config object from the final work:

Don't worry if things aren’t perfectly lined up. Everything is going to be moving anyway! That's the joy of using a config object—we get tweak it how we like.

How do we get the image into those items? Well, it’s tempting to create separate images for each item. But, that would result in a lot of network requests for each image which is bad for performance. Instead, we can create an image sprite. In fact, that’s exactly what I did.

Then to keep things responsive, we can use a percentage value for the background-size and background-position properties in the CSS. We make this part of the config and then inline those values, too. The config structure can be anything.

-
  const ITEMS = [
    {
      identifier: 'kody-blue',
      backgroundPositionX: 84.4,
      backgroundPositionY: 50,
      size: 739,
      config: {
        positionX: 50,
        positionY: 54,
        height: 58,
        width: 55,
      },
    },
  ]

.parallax
  - for (const ITEM of ITEMS)
    .parallax__item(style=`--pos-x: ${ITEM.backgroundPositionX}; --pos-y: ${ITEM.backgroundPositionY}; --size: ${ITEM.size}; --width: ${ITEM.config.width}; --height: ${ITEM.config.height}; --x: ${ITEM.config.positionX}; --y: ${ITEM.config.positionY};`)

Updating our CSS to account for this:

.parallax__item {
  position: absolute;
  left: calc(var(--x, 50) * 1%);
  top: calc(var(--y, 50) * 1%);
  height: calc(var(--height, auto) * 1%);
  width: calc(var(--width, auto) * 1%);
  transform: translate(-50%, -50%);
  background-image: url("kody-sprite.png");
  background-position: calc(var(--pos-x, 0) * 1%) calc(var(--pos-y, 0) * 1%);
  background-size: calc(var(--size, 0) * 1%);
}

And now we have a responsive traced scene with parallax items!

All that's left to do is remove the tracing image and the background colors, and apply transforms.

In the first version, I used the values in a different way. I had the handler return values between -60 and 60. We can do that with our handler by manipulating the return values.

const UPDATE = (x, y) => {
  CONTAINER.style.setProperty(
    '--ratio-x',
    Math.floor(gsap.utils.clamp(-60, 60, x * 100))
  )
  CONTAINER.style.setProperty(
    '--ratio-y',
    Math.floor(gsap.utils.clamp(-60, 60, y * 100))
  )
}

Then, each item can be configured for:

the x, y, and z positions,
movement on the x and y axis, and
rotation and translation on the x and y axis.

The CSS transforms are quite long. This is what they look like:

.parallax {
  transform: rotateX(calc(((var(--rx, 0) * var(--range-y, 0)) * var(--allow-motion)) * 1deg))
    rotateY(calc(((var(--ry, 0) * var(--range-x, 0)) * var(--allow-motion)) * 1deg))
    rotate(calc(((var(--r, 0) * var(--range-x, 0)) * var(--allow-motion)) * 1deg));
  transform-style: preserve-3d;
  transition: transform 0.25s;
}

.parallax__item {
  transform: translate(-50%, -50%)
    translate3d(
      calc(((var(--mx, 0) * var(--range-x, 0)) * var(--allow-motion)) * 1%),
      calc(((var(--my, 0) * var(--range-y, 0)) * var(--allow-motion)) * 1%),
      calc(var(--z, 0) * 1vmin)
    )
    rotateX(calc(((var(--rx, 0) * var(--range-y, 0)) * var(--allow-motion)) * 1deg))
    rotateY(calc(((var(--ry, 0) * var(--range-x, 0)) * var(--allow-motion)) * 1deg))
    rotate(calc(((var(--r, 0) * var(--range-x, 0)) * var(--allow-motion)) * 1deg));
  transform-style: preserve-3d;
  transition: transform 0.25s;
}

What’s that --allow-motion thing doing? That’s not in the demo! True. This is a little trick for applying reduced motion. If we have users who prefer "reduced" motion, we can cater for that with a coefficient. The word "reduced" doesn't have to mean "none" after all!

@media (prefers-reduced-motion: reduce) {
  .parallax {
    --allow-motion: 0.1;
  }
}
@media (hover: none) {
  .parallax {
    --allow-motion: 0;
  }
}

This "final" demo shows how the --allow-motion value affects the scene. Move the slider to see how you can reduce the motion.

This demo also shows off another feature: the ability to choose a "team" that changes Kody’s color. The neat part here is that all that requires is pointing to a different part of our image sprite.

And that's it for creating a CSS custom property powered parallax! But, I did mention this was something I built in React. And yes, that last demo uses React. In fact, this worked quite well in a component-based environment. We have an array of configuration objects and we can pass them into a <Parallax> component as children along with any transform coefficients.

const Parallax = ({
  config,
  children,
}: {
  config: ParallaxConfig
  children: React.ReactNode | React.ReactNode[]
}) => {
  const containerRef = React.useRef<HTMLDivElement>(null)
  useParallax(
    (x, y) => {
      containerRef.current.style.setProperty(
        '--range-x', Math.floor(gsap.utils.clamp(-60, 60, x * 100))
      )
      containerRef.current.style.setProperty(
        '--range-y', Math.floor(gsap.utils.clamp(-60, 60, y * 100))
      )
    },
    containerRef,
    () => window.innerWidth * 0.5,
)

  const containerStyle = {
    '--r': config.rotate,
    '--rx': config.rotateX,
    '--ry': config.rotateY,
  }
  return (
    <div
      ref={containerRef}
      className="parallax"
      style={
        containerStyle as ContainerCSS
      }
    >
      {children}
    </div>
  )
}

Then, if you spotted it, there's a hook in there called useParallax. We pass a callback into this that receives the x and y value. We also pass in the proximity which can be a function, and the element to use.

const useParallax = (callback, elementRef, proximityArg = 100) => {
  React.useEffect(() => {
    if (!elementRef.current || !callback) return
    const UPDATE = ({ x, y }) => {
      const bounds = 100
      const proximity = typeof proximityArg === 'function' ? proximityArg() : proximityArg
      const elementBounds = elementRef.current.getBoundingClientRect()
      const centerX = elementBounds.left + elementBounds.width / 2
      const centerY = elementBounds.top + elementBounds.height / 2
      const boundX = gsap.utils.mapRange(centerX - proximity, centerX + proximity, -bounds, bounds, x)
      const boundY = gsap.utils.mapRange(centerY - proximity, centerY + proximity, -bounds, bounds, y)
      callback(boundX / 100, boundY / 100)
    }
    window.addEventListener('pointermove', UPDATE)
    return () => {
      window.removeEventListener('pointermove', UPDATE)
    }
  }, [elementRef, callback])
}

Spinning this into a custom hook means I can reuse it elsewhere. In fact, removing the use of GSAP makes it a nice micro-package opportunity.

Lastly, the <ParallaxItem>. This is pretty straightforward. It's a component that maps the props into inline CSS custom properties. In the project, I opted to map the background properties to a child of the ParallaxItem.

const ParallaxItem = ({
  children,
  config,
}: {
  config: ParallaxItemConfig
  children: React.ReactNode | React.ReactNode[]
}) => {
  const params = {...DEFAULT_CONFIG, ...config}
  const itemStyle = {
    '--x': params.positionX,
    '--y': params.positionY,
    '--z': params.positionZ,
    '--r': params.rotate,
    '--rx': params.rotateX,
    '--ry': params.rotateY,
    '--mx': params.moveX,
    '--my': params.moveY,
    '--height': params.height,
    '--width': params.width,
  }
  return (
    <div
      className="parallax__item absolute"
      style={
        itemStyle as ItemCSS
      }
    >
      {children}
    </div>
  )
}

Tie all that together and you could end up with something like this:

const ITEMS = [
  {
    identifier: 'kody-blue',
    backgroundPositionX: 84.4,
    backgroundPositionY: 50,
    size: 739,
    config: {
      positionX: 50,
      positionY: 54,
      moveX: 0.15,
      moveY: -0.25,
      height: 58,
      width: 55,
      rotate: 0.01,
    },
  },
  ...otherItems
]

const KodyConfig = {
  rotate: 0.01,
  rotateX: 0.1,
  rotateY: 0.25,
}

const KodyParallax = () => (
  <Parallax config={KodyConfig}>
    {ITEMS.map(item => (
      <ParallaxItem key={item.identifier} config={item.config} />
    ))}
  </Parallax>
)

Which gives us our parallax scene!

That’s it!

We just took a static image and turned it into a slick parallax scene powered by CSS custom properties! It’s funny because image sprites have been around a long time, but they still have a lot of use today!

Stay Awesome! ʕ •ᴥ•ʔ

Print.css but not how you know it – Creating a 3D CSS Printer

Jhey Tompkins — Mon, 08 Nov 2021 18:39:56 +0000

For a while now I've been creating these 3D scenes with CSS for fun. Usually on my live stream.

// Detect dark theme var iframe = document.getElementById('tweet-1375639377150410758-444'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1375639377150410758&theme=dark" }

Each demo is an opportunity to try something different or work out ways to do things with CSS. One thing I often do is take suggestions for what we should try and make on the stream. A recent suggestion was a 3D printer. As in a "3D" printer as opposed to an ink/laserjet. And here's what I put together!

// Detect dark theme var iframe = document.getElementById('tweet-1385237899126480901-894'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1385237899126480901&theme=dark" }

Making things 3D with CSS

I've wrote about making things 3D with CSS before. The general gist is that most scenes are a composition of cuboids.

To make a cuboid, we can use CSS transforms to position the sides of a cuboid. The magic property being transform-style. Setting this to preserve-3d allows us to transform elements on the third dimension.

* {
  transform-style: preserve-3d;
}

Once you create a few of these scenes, you start picking up ways to speed things up. I like to use Pug as a HTML preprocessor. The mixin ability gives me a way to create cuboids speedier. The markup examples in this article use Pug. But, for each CodePen demo you can use the “View Compiled HTML” option to see the HTML output.

mixin cuboid()
  .cuboid(class!=attributes.class)
    - let s = 0
    while s < 6
      .cuboid__side
      - s++

Using this code

+cuboid()(class="printer__top")

Would produce

<div class="cuboid printer__top">
  <div class="cuboid__side"></div>
  <div class="cuboid__side"></div>
  <div class="cuboid__side"></div>
  <div class="cuboid__side"></div>
  <div class="cuboid__side"></div>
  <div class="cuboid__side"></div>
</div>

Then I have a set block of CSS I use to lay out the cuboids. The joy here is that we can leverage CSS custom properties to define the properties of a cuboid. As shown in the video above.

.cuboid {
  // Defaults
  --width: 15;
  --height: 10;
  --depth: 4;
  height: calc(var(--depth) * 1vmin);
  width: calc(var(--width) * 1vmin);
  transform-style: preserve-3d;
  position: absolute;
  font-size: 1rem;
  transform: translate3d(0, 0, 5vmin);
}
.cuboid > div:nth-of-type(1) {
  height: calc(var(--height) * 1vmin);
  width: 100%;
  transform-origin: 50% 50%;
  position: absolute;
  top: 50%;
  left: 50%;
  transform: translate(-50%, -50%) rotateX(-90deg) translate3d(0, 0, calc((var(--depth) / 2) * 1vmin));
}
.cuboid > div:nth-of-type(2) {
  height: calc(var(--height) * 1vmin);
  width: 100%;
  transform-origin: 50% 50%;
  transform: translate(-50%, -50%) rotateX(-90deg) rotateY(180deg) translate3d(0, 0, calc((var(--depth) / 2) * 1vmin));
  position: absolute;
  top: 50%;
  left: 50%;
}
.cuboid > div:nth-of-type(3) {
  height: calc(var(--height) * 1vmin);
  width: calc(var(--depth) * 1vmin);
  transform: translate(-50%, -50%) rotateX(-90deg) rotateY(90deg) translate3d(0, 0, calc((var(--width) / 2) * 1vmin));
  position: absolute;
  top: 50%;
  left: 50%;
}
.cuboid > div:nth-of-type(4) {
  height: calc(var(--height) * 1vmin);
  width: calc(var(--depth) * 1vmin);
  transform: translate(-50%, -50%) rotateX(-90deg) rotateY(-90deg) translate3d(0, 0, calc((var(--width) / 2) * 1vmin));
  position: absolute;
  top: 50%;
  left: 50%;
}
.cuboid > div:nth-of-type(5) {
  height: calc(var(--depth) * 1vmin);
  width: calc(var(--width) * 1vmin);
  transform: translate(-50%, -50%) translate3d(0, 0, calc((var(--height) / 2) * 1vmin));
  position: absolute;
  top: 50%;
  left: 50%;
}
.cuboid > div:nth-of-type(6) {
  height: calc(var(--depth) * 1vmin);
  width: calc(var(--width) * 1vmin);
  transform: translate(-50%, -50%) translate3d(0, 0, calc((var(--height) / 2) * -1vmin)) rotateX(180deg);
  position: absolute;
  top: 50%;
  left: 50%;
}

Using custom properties, we can control various characteristics of the cuboids, etc.

--width: The width of a cuboid on the plane
--height: The height of a cuboid on the plane
--depth: The depth of a cuboid on the plane
--x: The X position on the plane
--y: The Y position on the plane

This isn't very impressive until we put the cuboid into a scene and rotate it. Again, I use custom properties to manipulate the scene whilst I work on making something. Dat.GUI comes in super handy here.

If you inspect the demo, using the control panel updates custom CSS properties on the scene. This scoping of CSS custom properties saves a lot of repeated code and keeps things DRY.

More Than One Way

Much like many things in CSS, there's more than one way to do it. Often you can compose a scene from cuboids and position things as and when you need. It can get tricky to manage though. Often there's a need to group things or add some type of container.

Consider this example where the chair is it’s own sub-scene that can be moved around.

Many recent examples aren’t as complex. I've been reaching for extrusion. This means I'm able to map out whatever I'm making in 2D elements. For example, a helicopter I recently created.

.helicopter
  .helicopter__rotor
  .helicopter__cockpit
    .helicopter__base-light
    .helicopter__chair
      .helicopter__chair-back
      .helicopter__chair-bottom
    .helicopter__dashboard
  .helicopter__tail
  .helicopter__fin
    .helicopter__triblade
    .helicopter__tail-light
  .helicopter__stabilizer
  .helicopter__skids
    .helicopter __skid--left.helicopter__ skid
    .helicopter __skid--right.helicopter__ skid
  .helicopter__wing
    .helicopter __wing-light.helicopter__ wing-light--left
    .helicopter __wing-light.helicopter__ wing-light--right
  .helicopter__launchers
    .helicopter __launcher.helicopter__ launcher--left
    .helicopter __launcher.helicopter__ launcher--right
  .helicopter__blades

Then we can drop cuboids into all the containers using the mixin. Then apply a required "thickness" to each cuboid. The thickness becomes dictated by scoped custom properties. This demo toggles the --thickness property for cuboids that make the helicopter. It gives an idea of what the 2D mapping looked like to start with.

That's the gist of how to go about making 3D things with CSS. Digging into the code will unveil some tricks for sure. But, in general, scaffold a scene, populate with cuboids, and color the cuboids. You'll often want some different shades of a color so we can differentiate the sides of a cuboid. Any extra details are either things that we can add to a cuboid side or transforms we can apply to a cuboid. For example, rotating and moving on the Z axis.

Let’s consider a stripped down example.

.scene
  .extrusion
    +cuboid()(class="extrusion__cuboid")

The new CSS for creating a cuboid with extrusion could look like this. Note how we're including scoped custom properties for the color of each side too. It would be wise to drop some defaults under the :root here or fallback values.

.cuboid {
  width: 100%;
  height: 100%;
  position: relative;
}
.cuboid__side:nth-of-type(1) {
  background: var(--shade-one);
  height: calc(var(--thickness) * 1vmin);
  width: 100%;
  position: absolute;
  top: 0;
  transform: translate(0, -50%) rotateX(90deg);
}
.cuboid__side:nth-of-type(2) {
  background: var(--shade-two);
  height: 100%;
  width: calc(var(--thickness) * 1vmin);
  position: absolute;
  top: 50%;
  right: 0;
  transform: translate(50%, -50%) rotateY(90deg);
}
.cuboid__side:nth-of-type(3) {
  background: var(--shade-three);
  width: 100%;
  height: calc(var(--thickness) * 1vmin);
  position: absolute;
  bottom: 0;
  transform: translate(0%, 50%) rotateX(90deg);
}
.cuboid__side:nth-of-type(4) {
  background: var(--shade-two);
  height: 100%;
  width: calc(var(--thickness) * 1vmin);
  position: absolute;
  left: 0;
  top: 50%;
  transform: translate(-50%, -50%) rotateY(90deg);
}
.cuboid__side:nth-of-type(5) {
  background: var(--shade-three);
  height: 100%;
  width: 100%;
  transform: translate3d(0, 0, calc(var(--thickness) * 0.5vmin));
  position: absolute;
  top: 0;
  left: 0;
}
.cuboid__side:nth-of-type(6) {
  background: var(--shade-one);
  height: 100%;
  width: 100%;
  transform: translate3d(0, 0, calc(var(--thickness) * -0.5vmin)) rotateY(180deg);
  position: absolute;
  top: 0;
  left: 0;
}

We've gone with three shades for this example. But, sometimes you may need more. This demo puts that together but allows you to change scoped custom properties. The "thickness" value will change the extrusion of the cuboid. The transforms and dimensions will affect the containing element with the class "extrusion".

Scaffolding a Printer

To start, we can scaffold out all the pieces we need. With practice this becomes more obvious. But, the general rule is trying to visualise everything as boxes. That gives you a good idea of how to break something up.

.scene
  .printer
    .printer __side.printer__ side--left
    .printer __side.printer__ side--right
    .printer __tray.printer__ tray--bottom
    .printer __tray.printer__ tray--top
    .printer__top
    .printer__back

If you visualise the aim of what we're going for here. The two side pieces leave a gap in the middle. Then we have a cuboid that sits across the top and one that fills the back. Then two cuboids to make up the paper tray.

Once you're at that stage, it's a case of populating the cuboids which looks like this.

.scene
  .printer
    .printer __side.printer__ side--left
      +cuboid()(class="cuboid--side")
    .printer __side.printer__ side--right
      +cuboid()(class="cuboid--side")
    .printer __tray.printer__ tray--bottom
      +cuboid()(class="cuboid--tray")
    .printer __tray.printer__ tray--top
      +cuboid()(class="cuboid--tray")
    .printer__top
      +cuboid()(class="cuboid--top")
    .printer__back
      +cuboid()(class="cuboid--back")

Note how we're able to reuse the classnames such as cuboid--side. These cuboids are likely to be the same thickness and use the same colors. Their position and size gets dictated by the containing element.

Piecing it together, we can can get something like this.

Exploding the demo shows the different cuboids that make up the printer. If you turn off the extrusion, you can see the flat containing elements.

Adding Some Detail

Now. You may have noticed that there's more detail than what adding colors to each side would provide. And this comes down to finding ways to add extra detail. We've got different options depending on what we want to add.

If it's an image or some basic color changes, we can make use of background-image to layer up gradients, etc.

For example, the top of the printer has details and the opening of the printer. This code addresses the top side of the top cuboid. The gradient handles the opening of the printer and the details.

.cuboid--top {
  --thickness: var(--depth);
  --shade-one: linear-gradient(#292929, #292929) 100% 50%/14% 54% no-repeat, linear-gradient(var(--p-7), var(--p-7)) 40% 50%/12% 32% no-repeat, linear-gradient(var(--p-7), var(--p-7)) 30% 50%/2% 12% no-repeat, linear-gradient(var(--p-3), var(--p-3)) 0% 50%/66% 50% no-repeat, var(--p-1);
}

For the bear logo, we could use a background-image or even reach for a pseudo-element and position it.

.cuboid--top > div:nth-of-type(1):after {
  content: '';
  position: absolute;
  top: 7%;
  left: 10%;
  height: calc(var(--depth) * 0.12vmin);
  width: calc(var(--depth) * 0.12vmin);
  background: url("https://assets.codepen.io/605876/avatar.png");
  background-size: cover;
  transform: rotate(90deg);
  filter: grayscale(0.5);
}

If we need to add more extensive details, then we are likely going to have to break out of using our cuboid mixin. For example, the top of our printer is going to have a preview screen using an img element.

.printer__top
  .cuboid.cuboid--top
    .cuboid__side
    .cuboid__side
    .cuboid__side
    .cuboid__side
      .screen
        .screen__preview
          img.screen__preview-img
    .cuboid__side
    .cuboid__side

Add some more details and we're ready to get some paper in the mix!

Paper Journey

What's a printer without some paper? We want to animate some paper flying into the printer and getting shot out the other end.

We want something like this demo. Click anywhere to see a piece of paper fed into the printer and printed.

We can add a block of paper to the scene with a cuboid and then use a separate element to act as a single sheet of paper.

.paper-stack.paper-stack--bottom
  +cuboid()(class="cuboid--paper")
.paper-stack.paper-stack--top
  .cuboid.cuboid--paper
    .cuboid__side
      .paper
        .paper__flyer
    .cuboid__side
    .cuboid__side
    .cuboid__side
    .cuboid__side
    .cuboid__side

But, animating the paper flying into the printer takes some trial and error. It's wise to play with different transforms in the DevTools inspector. This is a good way to see how things will look. Often, it’s easier to use wrapper elements too. We use the .paper element to make the transfer and then use .paper__flyer to animate feeding the paper.

:root {
  --load-speed: 2;
}

.paper-stack--top .cuboid--paper .paper {
  animation: transfer calc(var(--load-speed) * 0.5s) ease-in-out forwards;
}
.paper-stack--top .cuboid--paper .paper__flyer {
  animation: fly calc(var(--load-speed) * 0.5s) ease-in-out forwards;
}
.paper-stack--top .cuboid--paper .paper__flyer:after {
  animation: feed calc(var(--load-speed) * 0.5s) calc(var(--load-speed) * 0.5s) forwards;
}

@keyframes transfer {
  to {
    transform: translate(0, -270%) rotate(22deg);
  }
}

@keyframes feed {
  to {
    transform: translate(100%, 0);
  }
}

@keyframes fly {
  0% {
    transform: translate3d(0, 0, 0) rotateY(0deg) translate(0, 0);
  }
  50% {
    transform: translate3d(140%, 0, calc(var(--height) * 1.2)) rotateY(-75deg) translate(180%, 0);
  }
  100% {
    transform: translate3d(140%, 0, var(--height)) rotateY(-75deg) translate(0%, 0) rotate(-180deg);
  }
}

You'll notice that there's a fair bit of calc usage in there. To compose the animation timeline we can make use of CSS custom properties. Referring to a property, we can calculate the correct delays for each animation in the chain. The paper transfers and flies at the same time. One animation handles moving the container, another handles rotating the paper. Once those animations end, the paper gets fed into the printer with the feed animation. The animation delay is equal to the duration of the first two animations that run at the same time.

Run this demo where I’ve colored the container elements red and green. We make use of .paper__flyer's pseudo-element to represent the piece of paper. But, the container elements do the hard work.

You may be wondering when the paper comes out at the other end. But, in fact, the paper isn't the same element throughout. We use one element to go into the printer. And another element for the paper when it flies out of the printer. Another instance where extra elements will make our life easier.

The paper uses more than one element to do the loop and then the paper gets positioned to the edge of that element. Running this demo with more colored container elements shows how it's working.

Once again, it's a bit of trial and error plus thinking about how we can leverage the use of container elements. Having a container with an offset transform-origin allows us to create the loop.

Printing

We have everything in place. Now it's a case of actually printing something. To do this, we're going to add a form that allows users to pass in the URL of an image.

form.customer-form
  label(for="print") Print URL
  input#print(type='url' required placeholder="URL for Printing")
  input(type="submit" value="Print")

With some styling, we get something like this.

The native behavior of forms and the use of required and type="url" means we only accept a URL. We could take this further with a pattern and check for certain image types. But, some good URL for random images don't include the image type. For example, "https://source.unsplash.com/random".

Submitting our form doesn't behave as we want and also the printing animation runs once on load. A way around this would be to only run the animation when a certain class gets applied to the printer.

When we submit the form, we can make a request for the URL and then set the src for images in our scene. One image being the screen preview on the printer. The other being an image on one side of the paper. In fact, when we print, we are going to add a new element for each printed piece of paper. That way each print looks like it gets added to a pile. We can remove the piece of paper we have on load.

Let’s start by handling the form submission. We are going to prevent the default event and call a PROCESS function.

const PRINT = e => {
  e.preventDefault()
  PROCESS()
}

const PRINT_FORM = document.querySelector('form')
PRINT_FORM.addEventListener('submit', PRINT)

This function will handle making the request for our image source.

let printing = false

const PREVIEW = document.querySelector('img.screen__preview-img')
const SUBMIT = document.querySelector('[type="submit"]')
const URL_INPUT = document.querySelector('[type="url"]')

const PROCESS = async () => {
  if (printing) return
  printing = true
  SUBMIT.disabled = true
  const res = await fetch(URL_INPUT.value)
  PREVIEW.src = res.url
  URL_INPUT.value = ''
}

We also set a printing variable to true which we will use to track current state, and disable the form’s button.

The reason we make a request for the image instead of setting it on the image? We want an absolute URL to an image. If we use the "unsplash" URL mentioned above and then share it between the images, this might not work. That's because we can run into scenarios where we have different images displayed.

Once we have the image source, we set the preview image source to that URL and reset the form’s input value.

To trigger the animation, we can hook into the "load" event of our preview image. When the event fires, we create a new element for the piece of paper to print and append it to the printer element. At the same time, we add a printing class to our printer. We can use this to trigger the first part of our paper animation.

PREVIEW.addEventListener('load', () => {
  PRINTER.classList.add('printing')
  const PRINT = document.createElement('div')
  PRINT.className = 'printed'
  PRINT.innerHTML = `
    <div class="printed__spinner">
      <div class="printed__paper">
        <div class="printed__papiere">
          <img class="printed__image" src=${PREVIEW.src}/>
        </div>
      </div>
      <div class="printed__paper-back"></div>
    </div>
  `
  PRINTER.appendChild(PRINT)
  // After a set amount of time reset the state
  setTimeout(() => {
    printing = false
    SUBMIT.removeAttribute('disabled')
    PRINTER.classList.remove('printing')
  }, 4500)
})

After a set amount of time, we can reset the state. An alternative approach would be to debounce a bubbling animationend event. But, we can use a setTimeout as we know how long the animation will take.

Our printing isn't to the correct scale though. And that's because we need to scale the image to the piece of paper. We need a small piece of CSS for this.

.printed__image {
  height: 100%;
  width: 100%;
  object-fit: cover;
}

It would also be neat if the lights on the front of the printer communicated that the printer is busy. We could adjust the hue of one of the lights when the printer is printing.

.progress-light {
  background: hsla(var(--progress-hue, 104), 80%, 50%);
}
.printing {
  --progress-hue: 10; /* Equates to red */
}

Put that together and we’ve got a “working” printer made with CSS and a smidge of JavaScript.

That’s It!

A look at how we can make a functional 3D Printer with CSS, a smidge of JavaScript, and leveraging Pug.

We covered a bunch of different things to achieve this. Some of the things we covered:

How to make 3D things with CSS
Using Pug mixins
Using scoped custom CSS properties to keep things DRY
Using extrusion to create 3D scenes
Handling forms with JavaScript
Composing animation timelines with custom properties

The joy of creating these demos is that many of them pose different problems to overcome. How to create certain shapes or construct certain animations. There’s often more than one way to do something.

What cool things could you make with 3D CSS? I’d love to see!

As always, thanks for reading. Wanna see more? Come find me on Twitter or check out my live stream!

Stay Awesome! ʕ •ᴥ•ʔ

Can We Create a "Resize Hack" With Container Queries?

Jhey Tompkins — Mon, 01 Nov 2021 22:17:05 +0000

If you follow new developments in CSS, you've likely heard of the impending arrival of container queries. We’re going to look at the basics here, but if you’d like another look, check out Una’s "Next Gen CSS: @container” article. After we have a poke at the basics ourselves, we’re going to build something super fun with them: a fresh take on the classic CSS meme featuring Peter Griffin fussing with window blinds. ;)

So, what is a container query? It's… exactly that. Much like we have media queries for querying things such as the viewport size, a container query allows us to query the size of a container. Based on that, we can then apply different styles to the children of said container.

What does it look like? Well, the exact standards are being worked out. Currently, though, it’s something like this:

.container {
  contain: layout size;
  /* Or... */
  contain: layout inline-size;
}

@container (min-width: 768px) {
  .child { background: hotpink; }
}

The layout keyword turns on layout-containment for an element. inline-size allows users to be more specific about containment. This currently means we can only query the container’s width. With size, we are able to query the container’s height.

Again, we things could still change. At the time of writing, the only way to use container queries (without a polyfill) is behind a flag in Chrome Canary (chrome://flags). I would definitely recommend having a quick read through the drafts over on csswg.org.

The easiest way to start playing would be to whip up a quick demo that sports a resizable container element.

Try changing the contain values (in Chrome Canary) and see how the demo responds. This demo uses contain: layout size which doesn’t restrict the axis. When both the height and width of the container meet certain thresholds, the shirt sizing adjusts.

@container (min-width: 400px) and (min-height: 400px) {
  .t-shirt__container {
    --size: "L";
    --scale: 2;
  }
}

That’s what you need to know to about container queries for now. It's really just a few new lines of CSS.

The only thing is: most demos for container queries I’ve seen so far use a pretty standard "card" example to demonstrate the concept. Don't get me wrong, because cards are a great use case for container queries. A card component is practically the poster child of container queries. Consider a generic card design and how it could get affected when used in different layouts. This is a common problem. Many of us have worked on projects where we wind up making various card variations, all catering to the different layouts that use them.

But cards don't inspire much to start playing with container queries. I want to see them pushed to greater limits to do interesting things. I've played with them a little in that t-shirt sizing demo. And I was going to wait until there was better browser support until I started digging in further (I'm a Brave user currently). But then Bramus shared there was a container query polyfill!

Jhey 🐻🛠

@jh3yy

Shout out to @bramus for sharing the Container Queries polyfill by @jon_neal the other day 👏

This prompted me to get "hacking"! 😅

twitter.com/bramusblog/sta…

22:22 PM - 30 Apr 2021

Bram.us @bramusblog
A first look at CQFill, a Polyfill for CSS Container Queries (by @jon_neal) 🔗 https://t.co/koWPzUccMk 🏷 #ContainerQueries #css #polyfill https://t.co/jVxGdSMuzO

And this got me thinking about ways to “hack” container queries.

⚠️ Spoiler alert : My hack didn’t work. It did momentarily, or at least I thought it did. But, this was actually a blessing because it prompted more conversation around container queries.

What was my idea? I wanted to create something sort of like the "Checkbox Hack" but for container queries.

<div class="container">
  <div class="container__resizer"></div>
  <div class="container__fixed-content"></div>
</div>

The idea is that you could have a container with a resizable element inside it, and then another element that gets fixed positioning outside of the container. Resizing containers could trigger container queries and restyle the fixed elements.

.container {
  contain: layout size;
}

.container__resize {
  resize: vertical;
  overflow: hidden;
  width: 200px;
  min-height: 100px;
  max-height: 500px;
}

.container__fixed-content {
  position: fixed;
  left: 200%;
  top: 0;
  background: red;
}

@container(min-height: 300px) {
  .container__fixed-content {
    background: blue;
  }
}

Try resizing the red box in this demo. It will change the color of the purple box.

Can we debunk a classic CSS meme with container queries?

Seeing this work excited me a bunch. Finally, an opportunity to create a version of the Peter Griffin CSS meme with CSS and debunk it!

You’ve probably seen the meme. It’s a knock on the Cascade and how difficult it is to manage it. I created the demo using cqfill@0.5.0… with my own little touches, of course. 😅

Moving the cord handle, resizes an element which in turn affects the container size. Different container breakpoints would update a CSS variable, --open, from 0 to 1, where 1 is equal to an “open” and 0 is equal to a “closed” state.

@container (min-height: 54px) {
  .blinds__blinds {
    --open: 0.1;
  }
}
@media --css-container and (min-height: 54px) {
  .blinds__blinds {
    --open: 0.1;
  }
}
@container (min-height: 58px) {
  .blinds__blinds {
    --open: 0.2;
  }
}
@media --css-container and (min-height: 58px) {
  .blinds__blinds {
    --open: 0.2;
  }
}
@container (min-height: 62px) {
  .blinds__blinds {
    --open: 0.3;
  }
}
@media --css-container and (min-height: 62px) {
  .blinds__blinds {
    --open: 0.3;
  }
}

But…. as I mentioned, this hack isn’t possible.

MiAAAAAAAh (is Terrifying)

@terriblemia

@jh3yy @CodePen Hmmm, containing inline-size shouldn't allow block (height) queries. You're likely hacking a bug in the js polyfill.

I love the idea, but I don't think this approach will work using Container Queries in CSS.

05:39 AM - 01 May 2021

What’s great here is that it prompted conversation around how container queries work. It also highlighted a bug with the container query polyfill which is now fixed. I would love to see this “hack” work though.

Miriam Suzanne has been creating some fantastic content around container queries. The capabilities have been changing a bunch. That's the risk of living on the bleeding edge. One of her latest articles sums up the current status.

Jonathan Neal

@jon_neal

@jh3yy @MiriSuzanne @CodePen I’ll get this fixed soon. Following the spec is CRITICAL.

BTW, I’m kinda worried about how many videos & demos already rely on the "export" behavior. The yet-published code on main drops this requirement, so `import '/path/to/cqfill.js'` will be all that is needed.

03:12 AM - 02 May 2021

Although my original demo/hack didn't work, we can still kinda use a "resize" hack to create those blinds. Again, we can query height if we use contain: layout size. Side note: it’s interesting how we’re currently unable to use contain to query a container’s height based on resizing its child elements.

Anyway. Consider this demo:

The arrow rotates as the container is resized. The trick here is to use a container query to update a scoped CSS custom property.

.container {
  contain: layout size;
}

.arrow {
  transform: rotate(var(--rotate, 0deg));
}

@container(min-height: 200px) {
  .arrow {
    --rotate: 90deg;
  }
}

We've kinda got a container query trick here then. The drawback with not being able to use the first hack concept is that we can't go completely 3D. Overflow hidden will stop that. We also need the cord to go beneath the window which means the windowsill would get in the way.

But, we can almost get there.

This demo uses a preprocessor to generate the container query steps. At each step, a scoped custom property gets updated. This reveals Peter and opens the blinds.

The trick here is to scale up the container to make the resize handle bigger. Then I scale down the content to fit back where it's meant to.

This fun demo “debunking the meme” isn’t 100% there yet, but, we’re getting closer. Container queries are an exciting prospect. And it’ll be interesting to see how they change as browser support evolves. It’ll also be exciting to see how people push the limits with them or use them in different ways.

Who knows? The “resize hack” might fit in nicely alongside the infamous “checkbox hack” one day.

Stay Awesome! ʕ •ᴥ•ʔ

Get Started with React by Building a Whac-A-Mole Game

Jhey Tompkins — Fri, 22 Oct 2021 16:55:20 +0000

Want to get started with React but struggling to find a good place to start? This article should have you covered. We'll focus on some of the main concepts of React and then we'll be building a game from scratch! We assume that you have a working knowledge of JavaScript — ah, and if you're here for the game, please scroll down.

I've been working with React for a long time. Since ~v0.12 (2014! Wow, where did the time go?). It's changed a lot. I recall certain "Aha" moments along the way. One thing that's remained is the mindset for using it. We think about things in a different way as opposed to working with the DOM direct.

For me, my learning style is to get something up and running as fast as I can. Then I explore deeper areas of the docs, etc. when necessary. Learn by doing, having fun, and pushing things.

Aim

The aim here is to show you enough React to cover some of those "Aha" moments. Leaving you curious enough to dig into things yourself and create your own apps. I recommend checking out the docs for anything you want to dig into. I won't be duplicating them.

Please note that you can find all examples in CodePen, but you can also jump to my Github repo for a fully working game.

First App

You can bootstrap a React app in various ways. Below is an example — this is pretty much all you need to create your first React app (besides the HTML) to get started.

import React from 'https://cdn.skypack.dev/react'
import { render } from 'https://cdn.skypack.dev/react-dom'

const App = () => <h1>{`Time: ${Date.now()}`}</h1>

render(<App/>, document.getElementById('app')

We could make this smaller, like so:

render(<h1>{`Time: ${Date.now()}`}</h1>, document.getElementById('app'))

In the first version, App is a component. But, this example tells React DOM to render an element instead of a component. Elements are the HTML elements we see in both examples. What makes a component, is a function returning those elements.

Before we get started with components, what's the deal with this "HTML in JS"?

JSX

That "HTML in JS" is JSX. You can read all about JSX in the React documentation. The gist? A syntax extension to JavaScript that allows us to write HTML in JavaScript. It's like a templating language with full access to JavaScript powers. It's actually an abstraction on an underlying API. Why do we use it? For most, it's easier to follow and comprehend than the equal.

React.createElement('h1', null, `Time: ${Date.now()}`)

The thing to take on board with JSX is that this is how you put things in the DOM 99% of the time with React. And it's also how we bind event handling a lot of the time. That other 1% is a little out of scope for this article. But, sometimes we want to render elements outside the realms of our React application. We can do this using React DOM's Portal. We can also get direct access to the DOM within the component lifecycle(coming up).

Attributes in JSX are camelCase. For example, onclick becomes onClick. There are some special cases such as class which becomes className. Also, attributes such as style now accept an Object instead of a string.

const style = { backgroundColor: 'red' }
<div className="awesome-class" style={style}>Cool</div>

Note: You can check out all the differences in attributes here.

Rendering

How do we get our JSX into the DOM? We need to inject it. In most cases, our apps have a single point of entry. And if we are using React, we use React DOM to insert an element/component at that point. You could use JSX without React though. As we mentioned, it's a syntax extension. You could change how JSX gets interpreted by Babel and have it pump out something different.

Everything within becomes managed by React. This can yield certain performance benefits when we are modifying the DOM a lot. This is because React makes use of a Virtual DOM. Making DOM updates isn't slow by any means. But, it's the impact it has within the browser that can impact performance. Each time we update the DOM, browsers need to calculate the rendering changes that need to take place. That can be expensive. Using the Virtual DOM, these DOM updates get kept in memory and synced with the browser DOM in batches when required.

There's nothing to stop us from having many apps on a page or having only part of a page managed by React.

Take this example. The same app rendered twice between some regular HTML. Our React app renders the current time using Date.now.

const App = () => <h1>{`Time: ${Date.now()}`}</h1>

For this example, we're rendering the app twice between some regular HTML. We should see the title "Many React Apps", followed by some text. Then the first rendering of our app appears, followed by some text and then the second rendering of our app.

For a deeper dive into rendering, check out the docs.

Components && Props

This is one of the biggest parts of React to grok. Components are reusable blocks of UI. But underneath, it's all functions. Components are functions whose arguments we refer to as props. And we can use those "props" to determine what a component should render. Props are "read-only" and you can pass anything in a prop. Even other components. Anything within the tags of a component we access via a special prop, children.

Components are functions that return elements. If we don’t want to show anything, return null.

We can write components in a variety of ways. But, it's all the same result.

Use a function

function App() {
  return <h1>{`Time: ${Date.now()}`}</h1>
}

Use a class

class App extends React.Component {
  render() {
    return <h1>{`Time: ${Date.now()}`}</h1>
  }
}

Before the release of hooks(coming up), we used class-based components a lot. We needed them for state and accessing the component API. But, with hooks, the use of class-based components has petered out a bit. In general, we always opt for function-based components now. This has various benefits. For one, it requires less code to achieve the same result. Hooks also make it easier to share and reuse logic between components. Also, classes can be confusing. They need the developer to have an understanding of bindings and context.

We'll be using function-based and you'll notice we used a different style for our App component.

const App = () => <h1>{`Time: ${Date.now()}`}</h1>

That's valid. The main thing is that our component returns what we want to render. In this case, a single element that is a h1 displaying the current time. If we don't need to write return, etc. then don’t. But, it's all preference. And different projects may adopt different styles.

What if we updated our multi-app example to accept props and we extract the h1 as a component?

const Message = ({ message }) => <h1>{message}</h1>
const App = ({ message }) => <Message message={message} />
render(<App message={`Time: ${Date.now()}`}/>, document.getElementById('app'))

That works and now we can change the message prop on App and we'd get different messages rendered. We could've made the component Time. But, creating a Message component implies many opportunities to reuse our component. This is the biggest thing about React. It’s about making decisions around architecture/design.

What if we forget to pass the prop to our component? We could provide a default value. Some ways we could do that.

const Message = ({message = "You forgot me!"}) => <h1>{message}</h1>

Or by specifying defaultProps on our component. We can also provide propTypes which is something I'd recommend having a look at. It provides a way to type check props on our components.

Message.defaultProps = {
  message: "You forgot me!"
}

We can access props in different ways. We've used ES6 conveniences to destructure props. But, our Message component could also look like this and work the same.

const Message = (props) => <h1>{props.message}</h1>

Props are an object passed to the component. We can read them any way we like.

Our App component could even be this

const App = (props) => <Message {...props}/>

It would yield the same result. We refer to this as "Prop spreading". It's better to be explicit with what we pass through though.

We could also pass the message as a child.

const Message = ({ children }) => <h1>{children}</h1>
const App = ({ message }) => <Message>{message}</Message>

Then we refer to the message via the special children prop.

How about taking it further and doing something like have our App pass a message to a component that is also a prop.

const Time = ({ children }) => <h1>{`Time: ${children}`}</h1>

const App = ({ message, messageRenderer: Renderer }) => <Renderer>{message}</Renderer>

render(<App message={`${Date.now()}`} messageRenderer={Time} />, document.getElementById('app'))

In this example, we create two apps and one renders the time and another a message. Note how we rename the messageRenderer prop to Renderer in the destructure? React won't see anything starting with a lowercase letter as a component. That’s because anything starting in lowercase is seen as an element. It would render it as <messageRenderer>. It's rare that we'll use this pattern but it's a way to show how anything can be a prop and you can do what you want with it.

One thing to make clear is that anything passed as a prop needs processing by the component. For example, want to pass styles to a component, you need to read them and apply them to whatever is being rendered.

Don't be afraid to experiment with different things. Try different patterns and practice. The skill of determining what should be a component comes through practice. In some cases, it's obvious, and in others, you might realize it later and refactor.

A common example would be the layout for an application. Think at a high level what that might look like. A layout with children that comprises of a header, footer, some main content. How might that look? It could look like this.

const Layout = ({ children }) => (
  <div className="layout">
    <Header/>
    <main>{children}</main>
    <Footer/>
  </div>
)

It's all about building blocks. Think of it like LEGO for apps.

In fact, one thing I'd advocate is getting familiar with Storybook as soon as possible (I'll create content on this if people would like to see it). Component-driven development isn't unique to React, we see it in other frameworks too. Shifting your mindset to think this way will help a lot.

Making Changes

Up until now, we've only dealt with static rendering. Nothing changes. The biggest thing to take on board for learning React is how React works. We need to understand that components can have state. And we must understand and respect that state drives everything. Our elements react to state changes. And React will only re-render where necessary.

Data flow is unidirectional too. Like a waterfall, state changes flow down the UI hierarchy. Components don't care about where the data comes from. For example, a component may want to pass state to a child through props. And that change may trigger an update to the child component. Or, components may choose to manage their own internal state which isn't shared.

These are all design decisions that get easier the more you work with React. The main thing to remember is how unidirectional this flow is. To trigger changes higher up, it either needs to happen via events or some other means passed by props.

Let's create an example.

import React, { useEffect, useRef, useState } from 'https://cdn.skypack.dev/react'
import { render } from 'https://cdn.skypack.dev/react-dom'

const Time = () => {
  const [time, setTime] = useState(Date.now())
  const timer = useRef(null)
  useEffect(() => {
    timer.current = setInterval(() => setTime(Date.now()), 1000)
    return () => clearInterval(timer.current)
  }, [])
  return <h1>{`Time: ${time}`}</h1>
}

const App = () => <Time/>

render(<App/>, document.getElementById('app'))

There is a fair bit to digest there. But, here we introduce the use of "Hooks". We are using "useEffect", "useRef", and "useState". These are utility functions that give us access to the component API.

If you check the example, the time is updating every second or 1000ms. And that's driven by the fact we update the time which is a piece of state. We are doing this within a setInterval. Note how we don't change time directly. State variables are treated as immutable. We do it through the setTime method we receive from invoking useState. Every time the state updates, our component re-renders if that state is part of the render. useState always returns a state variable and a way to update that piece of state. The argument passed is the initial value for that piece of state.

We use useEffect to hook into the component lifecycle for events such as state changes. Components mount when they're inserted into the DOM. And they get unmounted when they're removed from the DOM. To hook into these lifecycle stages, we use effects. And we can return a function within that effect that will fire when the component gets unmounted. The second parameter of useEffect determines when the effect should run. We refer to it as the dependency array. Any listed items that change will trigger the effect to run. No second parameter means the effect will run on every render. And an empty array means the effect will only run on the first render. This array will usually contain state variables or props.

We are using an effect to both setup and tear down our timer when the component mounts and unmounts.

We use a ref to reference that timer. A ref provides a way to keep reference to things that don’t trigger rendering. We don't need to use state for the timer. It doesn't affect rendering. But, we need to keep a reference to it so we can clear it on unmount.

Want to dig into hooks a bit before moving on? I wrote an article before about them – "React Hooks in 5 Minutes". And there's also great info in the React docs.

Our Time component has its own internal state that triggers renders. But, what if we wanted to change the interval length? We could manage that from above in our App component.

const App = () => {
  const [interval, updateInterval] = useState(1000)
  return (
    <Fragment>
      <Time interval={interval} />
      <h2>{`Interval: ${interval}`}</h2>
      <input type="range" min="1" value={interval} max="10000" onChange={e => updateInterval(e.target.value)}/>
    </Fragment>
  )
}

Our new interval value is being stored in the state of App. And it dictates the rate at which the Time component updates.

The Fragment component is a special component we have access to through React. In React, a component must return a single child or null. We can't return adjacent elements. But, sometimes we don't want to wrap our content in a div. Fragments allow us to avoid wrapper elements whilst keeping React happy.

You'll also notice our first event bind happening there. We use onChange as an attribute of the input to update the interval.

The updated interval is then passed to Time and the change of interval triggers our effect to run. This is because the second parameter of our useEffect hook now contains interval.

const Time = ({ interval }) => {
  const [time, setTime] = useState(Date.now())
  const timer = useRef(null)
  useEffect(() => {
    timer.current = setInterval(() => setTime(Date.now()), interval)
    return () => clearInterval(timer.current)
  }, [interval])
  return <h1>{`Time: ${time}`}</h1>
}

Have a play with the demo and see the changes!

I recommend visiting the React documentation if you want to dig into some of these concepts more. But, we've seen enough React to get started making something fun! Let's do it!

Whac-A-Mole React Game

Are you ready? We'll be creating our very own "Whac a Mole" with React!. The well-known game is basic in theory but throws up some interesting challenges to build. The important part here is how we're using React. I'll gloss over applying styles and making it pretty. That's your job! Although, I'm happy to take any questions on that.

Also, this game will not be "polished". But, it works. You can go and make it your own! Add your own features, etc.

Design

Let's start by thinking about what we've got to make. What components we may need etc.

Start/Stop Game
Timer
Keeping Score
Layout
Mole Component

Starting Point

We've learned how to make a component and we can roughly gauge what we need.

import React, { Fragment } from 'https://cdn.skypack.dev/react'
import { render } from 'https://cdn.skypack.dev/react-dom'

const Moles = ({ children }) => <div>{children}</div>
const Mole = () => <button>Mole</button>
const Timer = () => <div>Time: 00:00</div>
const Score = () => <div>Score: 0</div>

const Game = () => (
  <Fragment>
    <h1>Whac a Mole</h1>
    <button>Start/Stop</button>
    <Score/>
    <Timer/>
    <Moles>
      <Mole/>
      <Mole/>
      <Mole/>
      <Mole/>
      <Mole/>
    </Moles>
  </Fragment>
)

render(<Game/>, document.getElementById('app'))

Starting/Stopping

Before we do anything, we need to be able to start and stop the game. Starting the game will trigger elements like the timer and moles to come to life. This is where we can introduce conditional rendering.

const Game = () => {
  const [playing, setPlaying] = useState(false)
  return (
    <Fragment>
      {!playing && <h1>Whac a Mole</h1>}
      <button onClick={() => setPlaying(!playing)}>
        {playing ? 'Stop' : 'Start'}
      </button>
      {playing && (
        <Fragment>
          <Score />
          <Timer />
          <Moles>
            <Mole />
            <Mole />
            <Mole />
            <Mole />
            <Mole />
          </Moles>
        </Fragment>
      )}
    </Fragment>
  )
}

We have a state variable of playing and we use that to render elements that we need. In JSX we can use a condition with "&&" to render something if the condition is true. Here we say to render the board and its content if we are playing. This also affects the button text where we can use a ternary.

Timer

Let's get the timer running. By default, we're going to set a time limit of 30000ms. And we can declare this as a constant outside of our React components.

const TIME_LIMIT = 30000

Declaring constants in one place is a good habit to pick up. Anything that can be used to configure your app can be co-located in one place.

Our Timer component only cares about three things.

The time it's counting down;
At what interval it's going to update;
What it does when it ends.

A first attempt might look like this.

const Timer = ({ time, interval = 1000, onEnd }) => {
  const [internalTime, setInternalTime] = useState(time)
  const timerRef = useRef(time)
  useEffect(() => {
    if (internalTime === 0 && onEnd) onEnd()
  }, [internalTime, onEnd])
  useEffect(() => {
    timerRef.current = setInterval(
      () => setInternalTime(internalTime - interval),
      interval
    )
    return () => {
      clearInterval(timerRef.current)
    }
  }, [])
  return <span>{`Time: ${internalTime}`}</span>
}

But, it only updates once?

We're using the same interval technique we did before. But, the issue is we're using state in our interval callback. And this is our first "gotcha". Because we have an empty dependency array for our effect, it only runs once. The closure for setInterval uses the value of internalTime from the first render. This is an interesting problem and makes us think about how we approach things.

Note: I highly recommend reading this article by Dan Abramov that digs into timers and how to get around this problem. It's a worthwhile read and provides a deeper understanding. One issue is that empty dependency arrays can often introduce bugs in our React code. There's also an eslint plugin I'd recommend using to help point these out. The React docs also highlight the potential risks of using the empty dependency array.

One way to fix our Timer would be to update the dependency array for the effect. This would mean that our timerRef would get updated every interval. However, it introduces the issue of drifting accuracy.

useEffect(() => {
  timerRef.current = setInterval(
  () => setInternalTime(internalTime - interval),
    interval
  )
  return () => {
  clearInterval(timerRef.current)
  }
}, [internalTime, interval])

If you check this demo, it has the same Timer twice with different intervals and logs the drift to the developer console. A smaller interval or longer time equals a bigger drift.

We can use a ref to solve our problem. We can use it to track the internalTime and avoid running the effect every interval.

const timeRef = useRef(time)
useEffect(() => {
  timerRef.current = setInterval(
    () => setInternalTime((timeRef.current -= interval)),
    interval
  )
  return () => {
    clearInterval(timerRef.current)
  }
}, [interval])

And this reduces the drift significantly with smaller intervals too. Timers are sort of an edge case. But, it's a great example to think about how we use hooks in React. It's an example that's stuck with me and helped me understand the “Why?”.

Update the render to divide the time by 1000 and append an s and we have a seconds timer.

This timer is still rudimentary. It will drift over time. For our game, it'll be fine. If you want to dig into accurate counters, this is a great video on creating accurate timers with JavaScript.

Scoring

Let's make it possible to update the score. How do we score? Whacking a mole! In our case, that means clicking a button. For now, let's give each mole a score of 100. And we can pass an onWhack callback to our Moles.

const MOLE_SCORE = 100

const Mole = ({ onWhack }) => (
  <button onClick={() => onWhack(MOLE_SCORE)}>Mole</button>
)

const Score = ({ value }) => <div>{`Score: ${value}`}</div>

const Game = () => {
  const [playing, setPlaying] = useState(false)
  const [score, setScore] = useState(0)

  const onWhack = points => setScore(score + points)

  return (
    <Fragment>
      {!playing && <h1>Whac a Mole</h1>}
      <button onClick={() => setPlaying(!playing)}>{playing ? 'Stop' : 'Start'}</button>
      {playing &&
        <Fragment>
          <Score value={score} />
          <Timer
            time={TIME_LIMIT}
            onEnd={() => setPlaying(false)}
          />
          <Moles>
            <Mole onWhack={onWhack} />
            <Mole onWhack={onWhack} />
            <Mole onWhack={onWhack} />
            <Mole onWhack={onWhack} />
            <Mole onWhack={onWhack} />
          </Moles>
        </Fragment>
      }
    </Fragment>
  )
}

Note how the onWhack callback gets passed to each Mole. And that the callback updates our score state. These updates will trigger a render.

This is a good time to install the React Developer Tools extension in your browser. There is a neat feature that will highlight component renders in the DOM. Open the "Components" tab in Dev Tools and hit the settings cog. Select "Highlight updates when components render".

If you open our demo at this link and set the extension to highlight renders. Then you will see that the timer renders as time changes. But, when we whack a mole, all components re-render.

Loops in JSX

You might be thinking the way we're rendering our Moles is inefficient. And you'd be right to think that. There's an opportunity for us here to render these in a loop.

With JSX we tend to use Array.map 99% of the time to render a collection of things. For example,

const USERS = [
  { id: 1, name: 'Sally' },
  { id: 2, name: 'Jack' },
]
const App = () => (
  <ul>
    {USERS.map(({ id, name }) => <li key={id}>{name}</li>)}
  </ul>
)

The alternative would be to generate the content in a for loop and then render the return from a function.

return (
  <ul>{getLoopContent(DATA)}</ul>
)

What's that key attribute for? That helps React determine what changes need to render. If you can use a unique identifier, do! As a last resort, use the index of the item in a collection. Read the docs on lists for more.

For our example we don't have any data to work with. If you need to generate a collection of things. There's a trick you can use.

new Array(NUMBER_OF_THINGS).fill().map()

This could work for you in some scenarios.

return (
  <Fragment>
    <h1>Whac a Mole</h1>
    <button onClick={() => setPlaying(!playing)}>{playing ? 'Stop' : 'Start'}</button>
    {playing &&
      <Board>
        <Score value={score} />
        <Timer time={TIME_LIMIT} onEnd={() => console.info('Ended')}/>
        {new Array(5).fill().map((_, id) =>
          <Mole key={id} onWhack={onWhack} />
        )}
      </Board>
    }
  </Fragment>
)

Or, if you want a persistent collection, you could use something like uuid.

import { v4 as uuid } from 'https://cdn.skypack.dev/uuid'
const MOLE_COLLECTION = new Array(5).fill().map(() => uuid())

// In our JSX
{MOLE_COLLECTION.map((id) =>
  <Mole key={id} onWhack={onWhack} />
)}

Ending Game

We can only end our game with the start button. And when we do end it, the score remains when we start again. The onEnd for our Timer also does nothing yet.

What we need is a 3rd state where we aren't playing but we have finished. In more complex applications, I'd recommend reaching for XState or using reducers. But, for our app, we can introduce a new state variable, finished. When the state is !playing and finished, we can display the score, reset the timer, and give the option to restart.

We need to put our logic caps on now. If we end the game, then instead of toggling playing, we need to also toggle finished. We could create an endGame and startGame function.

const endGame = () => {
  setPlaying(false)
  setFinished(true)
}

const startGame = () => {
  setScore(0)
  setPlaying(true)
  setFinished(false)
}

When we start a game, we reset the score and put the game into the playing state. This triggers the playing UI to render. When we end the game, we set finished to true. The reason we don't reset the score is so we can show it as a result.

And, when our Timer ends, it should invoke that same function.

<Timer time={TIME_LIMIT} onEnd={endGame} />

It can do that within an effect. If the internalTime hits 0, then unmount and invoke onEnd.

useEffect(() => {
  if (internalTime === 0 && onEnd) {
    onEnd()
  }
}, [internalTime, onEnd])

We can shuffle our UI rendering to render 3 states:

Fresh
Playing
Finished

<Fragment>
  {!playing && !finished &&
    <Fragment>
      <h1>Whac a Mole</h1>
      <button onClick={startGame}>Start Game</button>
    </Fragment>
  }
  {playing &&
    <Fragment>
      <button
        className="end-game"
        onClick={endGame}
        >
        End Game
      </button>
      <Score value={score} />
      <Timer
        time={TIME_LIMIT}
        onEnd={endGame}
      />
      <Moles>
        {new Array(NUMBER_OF_MOLES).fill().map((_, index) => (
          <Mole key={index} onWhack={onWhack} />
        ))}
      </Moles>
    </Fragment>
  }
  {finished &&
    <Fragment>
      <Score value={score} />
      <button onClick={startGame}>Play Again</button>
    </Fragment>
  }
</Fragment>

And now we have a functioning game minus moving moles.

Note how we’ve reused the Score component. Was there an opportunity there to not repeat Score? Could you put it in its own conditional? Or does it need to appear there in the DOM. This will come down to your design.

Might you end up with a more generic component to cover it? These are the questions to keep asking. The goal is to keep a separation of concerns with your components. But, you also want to keep portability in mind.

Moles

Moles are the centerpiece of our game. They don't care about the rest of the app. But, they'll give you their score onWhack. This emphasises portability.

We aren't digging into styling in this "Guide". But, for our Mole, we can create a container with overflow: hidden that our Mole(button) moves in and out of. The default position of our Mole will be out of view.

We're going to bring in a 3rd party solution to make our Moles bob up and down. This is an example of how to bring in 3rd party solutions that work with the DOM. In most cases, we use refs to grab DOM elements. And then we use our solution within an effect.

We're going to use GreenSock(GSAP) to make our Moles bob. We won't dig into the GSAP APIs today. But, if you have any questions about what they're doing, please ask me!

Here's an updated Mole with GSAP.

import gsap from 'https://cdn.skypack.dev/gsap'

const Mole = ({ onWhack }) => {
  const buttonRef = useRef(null)
  useEffect(() => {
    gsap.set(buttonRef.current, { yPercent: 100 })
    gsap.to(buttonRef.current, {
      yPercent: 0,
      yoyo: true,
      repeat: -1,
    })
  }, [])
  return (
    <div className="mole-hole">
      <button
        className="mole"
        ref={buttonRef}
        onClick={() => onWhack(MOLE_SCORE)}>
        Mole
      </button>
    </div>
  )
}

We've added a wrapper to the button which allows us to show/hide the Mole. And we've also given our button a ref. Using an effect, we can create a tween(GSAP animation) that moves the button up and down.

You'll also notice, we're using className which is the attribute equal to class in JSX to apply class names. Why don't we use the className with GSAP? Because, if we have many elements with that className, our effect will try to use them all. This is why useRef is a great choice to stick with.

Awesome, now we have bobbing Moles, and our game is complete from a functional sense. They all move exactly the same which isn't ideal. They should operate at different speeds. The points scored should also reduce the longer it takes for a Mole to get whacked.

Our Mole's internal logic can deal with how scoring and speeds get updated. Passing the initial speed, delay, and points in as props will make for a more flexible component.

<Mole key={index} onWhack={onWhack} points={MOLE_SCORE} delay={0} speed={2} />

Now, for a breakdown of our Mole logic.

Let's start with how our points will reduce over time. This could be a good candidate for a ref. We have something that doesn't affect render whose value could get lost in a closure. We create our animation in an effect and it's never recreated. On each repeat of our animation, we want to decrease the points value by a multiplier. The points value can have a minimum value defined by a pointsMin prop.

const bobRef = useRef(null)
const pointsRef = useRef(points)

useEffect(() => {
  bobRef.current = gsap.to(buttonRef.current, {
    yPercent: -100,
    duration: speed,
    yoyo: true,
    repeat: -1,
    delay: delay,
    repeatDelay: delay,
    onRepeat: () => {
      pointsRef.current = Math.floor(
        Math.max(pointsRef.current * POINTS_MULTIPLIER, pointsMin)
      )
    },
  })
  return () => {
    bobRef.current.kill()
  }
}, [delay, pointsMin, speed])

We're also creating a ref to keep a reference of our GSAP animation. We will use this when the Mole gets whacked. Note how we also return a function that kills the animation on unmount. If we don’t kill the animation on unmount, the repeat code will keep firing.

What will happen when our Mole gets whacked? We need a new state for that.

const [whacked, setWhacked] = useState(false)

And instead of using the onWhack prop in the onClick of our button, we can create a new function whack. This will set whacked to true and call onWhack with the current pointsRef value.

const whack = () => {
  setWhacked(true)
  onWhack(pointsRef.current)
}

return (
  <div className="mole-hole">
    <button className="mole" ref={buttonRef} onClick={whack}>
      Mole
    </button>
  </div>
)

The last thing to do is respond to the whacked state in an effect with useEffect. Using the dependency array, we can make sure we only run the effect when whacked changes. If whacked is true, we reset the points, pause the animation, and animate the Mole underground. Once underground, we wait for a random delay before restarting the animation. The animation will start speedier using timescale and we set whacked back to false.

useEffect(() => {
  if (whacked) {
    pointsRef.current = points
    bobRef.current.pause()
    gsap.to(buttonRef.current, {
      yPercent: 100,
      duration: 0.1,
      onComplete: () => {
        gsap.delayedCall(gsap.utils.random(1, 3), () => {
          setWhacked(false)
          bobRef.current
            .restart()
            .timeScale(bobRef.current.timeScale() * TIME_MULTIPLIER)
        })
      },
    })
  }
}, [whacked])

That gives us

The last thing to do is pass props to our Mole instances that will make them behave different. But, how we generate these props could cause an issue.

<div className="moles">
  {new Array(MOLES).fill().map((_, id) => (
    <Mole
      key={id}
      onWhack={onWhack}
      speed={gsap.utils.random(0.5, 1)}
      delay={gsap.utils.random(0.5, 4)}
      points={MOLE_SCORE}
    />
  ))}
</div>

This would cause an issue because the props would change on every render as we generate the Moles. A better solution could be to generate a new Mole array each time we start the game and iterate over that. This way we can keep the game random without causing issues.

const generateMoles = () => new Array(MOLES).fill().map(() => ({
  speed: gsap.utils.random(0.5, 1),
  delay: gsap.utils.random(0.5, 4),
  points: MOLE_SCORE
}))
// Create state for moles
const [moles, setMoles] = useState(generateMoles())
// Update moles on game start
const startGame = () => {
  setScore(0)
  setMoles(generateMoles())
  setPlaying(true)
  setFinished(false)
}
// Destructure mole objects as props
<div className="moles">
  {moles.map(({speed, delay, points}, id) => (
    <Mole
      key={id}
      onWhack={onWhack}
      speed={speed}
      delay={delay}
      points={points}
    />
  ))}
</div>

And here's the result! I’ve gone ahead and added some styling along with an image of a Mole for our buttons.

We now have a fully working “Whac-a-Mole” game built in React. It took us less than 200 lines of code. At this stage you can take it away and make it your own. Style it how you like, add new features, etc. Or stick around and we can put together some extras.

Tracking High Score

We have a working "Whac a Mole". But, how can we keep track of our high score? We could use an effect to write our score to localStorage every time the game ends. But, what if persisting things was a common need. We could create a custom hook called "usePersistentState". This could be a wrapper around "useState" that reads/writes to localStorage.

const usePersistentState = (key, initialValue) => {
  const [state, setState] = useState(
    window.localStorage.getItem(key)
      ? JSON.parse(window.localStorage.getItem(key))
      : initialValue
  )
  useEffect(() => {
    window.localStorage.setItem(key, state)
  }, [key, state])
  return [state, setState]
}

And then we can use that in our game.

const [highScore, setHighScore] = usePersistentState('whac-high-score', 0)

We use it exactly the same as useState. And we can hook into onWhack to set a new high score during the game when appropriate.

const endGame = points => {
  if (score > highScore) setHighScore(score) // play fanfare!
}

How might we be able to tell if our game result is a new high score? Another piece of state? Most likely.

Whimsical Touches

At this stage, we've covered everything we need to. Even how to make your own custom hook. Feel free to go off and make this your own.

Sticking around? Let's create another custom hook for adding audio to our game.

const useAudio = (src, volume = 1) => {
  const [audio, setAudio] = useState(null)
  useEffect(() => {
    const AUDIO = new Audio(src)
    AUDIO.volume = volume
    setAudio(AUDIO)
  }, [src])
  return {
    play: () => audio.play(),
    pause: () => audio.pause(),
    stop: () => {
      audio.pause()
      audio.currentTime = 0
    },
  }
}

This is a rudimentary hook implementation for playing audio. We provide an audio src and then we get back the API to play it. We can add noise when we "Whac” a Mole. Then the decision will be, is this part of Mole? Is it something we pass to Mole? Is it something we invoke in onWhack ?

These are the types of decisions that come up in component-driven development. We need to keep portability in mind. Also, what would happen if we wanted to mute the audio? How could we globally do that? It might make more sense as a first approach to control the audio within the Game component.

// Inside Game
const { play: playAudio } = useAudio('/audio/some-audio.mp3')
const onWhack = () => {
  playAudio()
  setScore(score + points)
}

It’s all about design and decisions. If we bring in lots of audio, renaming the play variable could get tedious. Returning an Array from our hook like useState would allow us to name the variable whatever we want. But, it also might be hard to remember which index of the Array accounts for which API method.

That's It!

More than enough to get you started on your React journey. And we got to make something interesting.

We covered a lot!

Creating an App
JSX
Components and props
Creating timers
Using refs
Creating custom hooks

We made a game! And now you can use your new skills to add new features or make it your own.

Where did I take it? It's at this stage so far.

Where to Go Next!

I hope building “Whac-a-Mole” has motivated you to start your React journey. Where next?

Here are some links to resources to check out if you’re looking to dig in more. Some of which are ones I found useful along the way.

React documentation
“Making setInterval Declarative with React Hooks” – Dan Abramov
“How to fetch data with React Hooks” – Robin Wieruch
“When to useMemo and useCallback” – Kent C Dodds

Stay Awesome! ʕ •ᴥ•ʔ

Going "Meta GSAP": The Quest for "Perfect" Infinite Scrolling

Jhey Tompkins — Mon, 11 Oct 2021 19:40:48 +0000

I'm not sure how this one came about. But, it's a story. This article is more about grokking a concept, one that's going to help you think about your animations in a different way. It so happens that this particular example features infinite scrolling — specifically the "perfect" infinite scroll for a deck of cards without duplicating any of them.

Why am I here? Well, this all started from a tweet. A tweet that got me thinking about layouts and side-scrolling content.

// Detect dark theme var iframe = document.getElementById('tweet-1329534673987506184-715'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1329534673987506184&theme=dark" }

I took that concept and used it on my site. And it's still there in action at the time of writing.

Then I got to thinking more about gallery views and side-scrolling concepts. We hopped on a livestream and decided to try and make something like the old Apple "Cover Flow" pattern. Remember it?

My first thoughts for making this assumed I'd make this so it works without JavaScript, as it does in the demo above, in a way that uses "progressive enhancement." I grabbed Greensock and ScrollTrigger, and off we went. I came away from that work pretty disappointed. I had something but couldn't quite get infinite scrolling to work how the way I wanted. The "Next” and “Previous" buttons didn't want to play ball. You can see it here, and it requires horizontal scrolling.

So I opened up a new thread on the Greensock forum. Little did I know I was about to open myself up to some serious learning! We solved the issue with the buttons. But, being me, I had to ask whether something else was possible. Was there a "clean" way to do infinite scrolling? I'd tried something on stream but had no luck. I was curious. I'd tried a technique like that used in this pen which I created for the ScrollTrigger release.

The initial answer was that it is kinda tricky to do:

The hard part about infinite things on scroll is that the scroll bar is limited while the effect that you're wanting is not. So you have to either loop the scroll position like this demo (found in the ScrollTrigger demos section) or hook directly into the scroll-related navigation events (like the wheel event) instead of actually using the actual scroll position.

I figured that was the case and was happy to leave it "as-is." A couple of days passed and Jack dropped a reply that kinda blew my mind when I started digging into it. And now, after a bunch of going through it, I'm here to share the technique with you.

Animate anything

One thing that is often overlooked with GSAP, is that you can animate almost anything with it. This is often because visual things are what spring to mind when thinking about animation — the actual physical movement of something. Our first thought isn't about taking that process to a meta-level and animating from a step back.

But, think about animation work on a larger scale and then break it down into layers. For example, you play a cartoon. The cartoon is a collection of compositions. Each composition is a scene. And then you have the power to scrub through that collection of compositions with a remote, whether it’s on YouTube, using your TV remote, or whatever. There are almost three levels to what is happening.

And this is the trick we need for creating different types of infinite loops. This is the main concept right here. We animate the play head position of a timeline with a timeline. And then we can scrub that timeline with our scroll position.

Don't worry if that sounds confusing. We're going to break it down.

Going “meta”

Let's start with an example. We're going to create a tween that moves some boxes from left to right. Here it is.

Ten boxes that keep going left to right. That's quite straightforward with Greensock. Here, we use fromTo and repeat to keep the animation going. But, we have a gap at the start of each iteration. We’re also using stagger to space out the movement and that’s something that will play an important role as we continue.

gsap.fromTo('.box', {
  xPercent: 100
}, {
  xPercent: -200,
  stagger: 0.5,
  duration: 1,
  repeat: -1,
  ease: 'none',
})

Now comes the fun part. Let's pause the tween and assign it to a variable. Then let’s create a tween that plays it. We can do this by tweening the totalTime of the tween, which allows us to get or set the tween’s playhead tween, while considering repeats and repeat delays.

const SHIFT = gsap.fromTo('.box', {
  xPercent: 100
}, {
  paused: true,
  xPercent: -200,
  stagger: 0.5,
  duration: 1,
  repeat: -1,
  ease: 'none',
})

const DURATION = SHIFT.duration()

gsap.to(SHIFT, {
  totalTime: DURATION,
  repeat: -1,
  duration: DURATION,
  ease: 'none',
})

This is our first “meta” tween. It looks exactly the same but we’re adding another level of control. We can change things on this layer without affecting the original layer. For example, we could change the tween ease to power4.in. This completely changes the animation but without affecting the underlying animation. We're kinda safeguarding ourselves with a fallback.

Not only that, we might choose to repeat only a certain part of the timeline. We could do that with another fromTo, like this:

The code for that would be something like this.

gsap.fromTo(SHIFT, {
  totalTime: 2,
}, {
  totalTime: DURATION - 1,
  repeat: -1,
  duration: DURATION,
  ease: 'none'
})

Do you see where this is going? Watch that tween. Although it keeps looping, the numbers flip on each repeat. But, the boxes are in the correct position.

Achieving the “perfect” loop

If we go back to our original example, there’s a noticeable gap between each repetition.

Here comes the trick. The part that unlocks everything. We need to build a perfect loop.

Let's start by repeating the shift three times. It's equal to using repeat: 3. Notice how we’ve removed repeat: -1 from the tween.

const getShift = () => gsap.fromTo('.box', {
  xPercent: 100
}, {
  xPercent: -200,
  stagger: 0.5,
  duration: 1,
  ease: 'none',
})

const LOOP = gsap.timeline()
  .add(getShift())
  .add(getShift())
  .add(getShift())

We’ve turned the initial tween into a function that returns the tween and we add it to a new timeline three times. And this gives us the following.

OK. But, there's still a gap. Now we can bring in the position parameter for adding and positioning those tweens. We want it to be seamless. That means inserting each each set of tweens before the previous one ends. That’s a value based on the stagger and the amount of elements.

const stagger = 0.5 // Used in our shifting tween
const BOXES = gsap.utils.toArray('.box')
const LOOP = gsap.timeline({
  repeat: -1
})
  .add(getShift(), 0)
  .add(getShift(), BOXES.length * stagger)
  .add(getShift(), BOXES.length * stagger * 2)

If we update our timeline to repeat and watch it (while adjusting the stagger to see how it affects things)…

You'll notice that there's a window in the middle there that creates a "seamless" loop. Recall those skills from earlier where we manipulated time? That's what we need to do here: loop the window of time where the loop is "seamless."

We could try tweening the totalTime through that window of the loop.

const LOOP = gsap.timeline({
  paused: true,
  repeat: -1,
})
.add(getShift(), 0)
.add(getShift(), BOXES.length * stagger)
.add(getShift(), BOXES.length * stagger * 2)

gsap.fromTo(LOOP, {
  totalTime: 4.75,
},
{
  totalTime: '+=5', // HIGHLIGHT
  duration: 10,
  ease: 'none',
  repeat: -1,
})

Here, we’re saying tween the totalTime from 4.75 and add the length of a cycle to that. The length of a cycle is 5. And that’s the middle window of the timeline. We can use GSAP’s nifty += to do that, which gives us this:

Take a moment to digest what's happening there. This could be the trickiest part to wrap your head around. We're calculating windows of time in our timeline. It’s kinda hard to visualise but I’ve had a go.

This is a demo of a watch that takes 12 seconds for the hands go round once. It's looped infinitely with repeat: -1 and then we're using fromTo to animate a specific time window with a given duration. If you, reduce the time window to say 2 and 6, then change the duration to 1, the hands will go from 2 o'clock to 6 o'clock on repeat. But, we never changed the underlying animation.

Try configuring the values to see how it affects things.

At this point, it’s a good idea to put together a formula for our window position. We could also use a variable for the duration it takes for each box to transition.

const DURATION = 1
const CYCLE_DURATION = BOXES.length * STAGGER
const START_TIME = CYCLE_DURATION + (DURATION * 0.5)
const END_TIME = START_TIME + CYCLE_DURATION

Instead of using three stacked timelines, we could loop over our elements three times where we get the benefit of not needing to calculate the positions. Visualizing this as three stacked timelines is a neat way to grok the concept, though, and a nice way to help understand the main idea.

Let’s change our implementation to create one big timeline from the start.

const STAGGER = 0.5
const BOXES = gsap.utils.toArray('.box')

const LOOP = gsap.timeline({
  paused: true,
  repeat: -1,
})

const SHIFTS = [...BOXES, ...BOXES, ...BOXES]

SHIFTS.forEach((BOX, index) => {
  LOOP.fromTo(BOX, {
    xPercent: 100
  }, {
    xPercent: -200,
    duration: 1,
    ease: 'none',
  }, index * STAGGER)
})

This is easier to put together and gives us the same window. But, we don't need to think about math. Now we loop through three sets of the boxes and position each animation according to the stagger.

How might that look if we adjust the stagger? It will squish the boxes closer together.

But, it’s broken the window because now the totalTime is out. We need to recalculate the window. Now’s a good time to plug in the formula we calculated earlier.

const DURATION = 1
const CYCLE_DURATION = STAGGER * BOXES.length
const START_TIME = CYCLE_DURATION + (DURATION * 0.5)
const END_TIME = START_TIME + CYCLE_DURATION

gsap.fromTo(LOOP, {
  totalTime: START_TIME,
},
{
  totalTime: END_TIME,
  duration: 10,
  ease: 'none',
  repeat: -1,
})

Fixed!

We could even introduce an “offset” if we wanted to change the starting position.

const STAGGER = 0.5
const OFFSET = 5 * STAGGER
const START_TIME = (CYCLE_DURATION + (STAGGER * 0.5)) + OFFSET

Now our window starts from a different position.

But still, this isn’t great as it gives us these awkward stacks at each end. To get rid of that effect, we need to think about a "physical" window for our boxes. Or think about how they enter and exit the scene.

We’re going to use document.body as the window for our example. Let's update the box tweens to be individual timelines where the boxes scale up on enter and down on exit. We can use yoyo and repeat: 1 to achieve entering and exiting.

SHIFTS.forEach((BOX, index) => {
  const BOX_TL = gsap
    .timeline()
    .fromTo(
      BOX,
      {
        xPercent: 100,
      },
      {
        xPercent: -200,
        duration: 1,
        ease: 'none',
      }, 0
    )
    .fromTo(
      BOX,
      {
        scale: 0,
      },
      {
        scale: 1,
        repeat: 1,
        yoyo: true,
        ease: 'none',
        duration: 0.5,
      },
      0
    )
  LOOP.add(BOX_TL, index * STAGGER)
})

Why are we using a timeline duration of 1? It makes things easier to follow. We know the time is 0.5 when the box is at the midpoint. It's worth noting that easing won't have the effect we usually think of here. In fact, easing will actually play a part in how the boxes position themselves. For example, an ease-in would bunch the boxes up on the right before they move across.

The code above gives us this.

Almost. But, our boxes disappear for a time in the middle. To fix this, let’s introduce the immediateRender property. It acts like animation-fill-mode: none in CSS. We’re telling GSAP that we don’t want to retain or pre-record any styles that are being set on a box.

SHIFTS.forEach((BOX, index) => {
  const BOX_TL = gsap
    .timeline()
    .fromTo(
      BOX,
      {
        xPercent: 100,
      },
      {
        xPercent: -200,
        duration: 1,
        ease: 'none',
        immediateRender: false, // HIGHLIGHT
      }, 0
    )
    .fromTo(
      BOX,
      {
        scale: 0,
      },
      {
        scale: 1,
        repeat: 1,
        zIndex: BOXES.length + 1,
        yoyo: true,
        ease: 'none',
        duration: 0.5,
        immediateRender: false, // HIGHLIGHT
      },
      0
    )
  LOOP.add(BOX_TL, index * STAGGER)
})

That small change fixes things for us! Note how we’ve also included z-index: BOXES.length. That should safeguard us against any z-index issues.

There we have it! Our first infinite seamless loop. No duplicate elements and perfect continuation. We’re bending time! Pat yourself on the back if you’ve gotten this far! 🎉

If we want to see more boxes at once, we can tinker with the timing, stagger, and ease. Here, we have a STAGGER of 0.2 and we’ve also introduced opacity into the mix.

The key part here is that we can make use of repeatDelay so that the opacity transition is quicker than the scale. Fade in over 0.25 seconds. Wait 0.5 seconds. Fade back out over 0.25 seconds.

.fromTo(
  BOX, {
    opacity: 0, // HIGHLIGHT
  }, {
    opacity: 1, // HIGHLIGHT
    duration: 0.25,
    repeat: 1,
    repeatDelay: 0.5, // HIGHLIGHT
    immediateRender: false,
    ease: 'none',
    yoyo: true,
  }, 0)

Cool! We could do whatever we want with those in and out transitions. The main thing here is that we have our window of time that gives us the infinite loop.

Hooking this up to scroll

Now that we have a seamless loop, let’s attach it to scroll. For this we can use GSAP’s ScrollTrigger. This requires an extra tween to scrub our looping window. Note how we’ve set the loop to be paused now, too.

const LOOP_HEAD = gsap.fromTo(LOOP, {
  totalTime: START_TIME,
},
{
  totalTime: END_TIME,
  duration: 10,
  ease: 'none',
  repeat: -1,
  paused: true,
})

const SCRUB = gsap.to(LOOP_HEAD, {
  totalTime: 0,
  paused: true,
  duration: 1,
  ease: 'none',
})

The trick here is to use ScrollTrigger to scrub the play head of the loop by updating the totalTime of SCRUB. There are various ways we could set up this scroll. We could have it horizontal or bound to a container. But, what we're going to do is wrap our boxes in a .boxes element and pin that to the viewport. (This fixes its position in the viewport.) We'll also stick with vertical scrolling. Check the demo to see the styling for .boxes which sets things to the size of the viewport.

import ScrollTrigger from 'https://cdn.skypack.dev/gsap/ScrollTrigger'
gsap.registerPlugin(ScrollTrigger)

ScrollTrigger.create({
  start: 0,
  end: '+=2000',
  horizontal: false,
  pin: '.boxes',
  onUpdate: self => {
    SCRUB.vars.totalTime = LOOP_HEAD.duration() * self.progress
    SCRUB.invalidate().restart()
  }
})

The important part is inside onUpdate. That’s where we set the totalTime of the tween based on the scroll progress. The invalidate call flushes any internally recorded positions for the scrub. The restart then sets the position to the new totalTime we set.

Try it out! We can go back and forth in the timeline and update the position.

How cool is that? We can scroll to scrub a timeline that scrubs a timeline that is a window of a timeline. Digest that for a second because that's what's happening here.

Time travel for infinite scrolling

Up to now, we've been manipulating time. Now we're going to time travel!

To do this, we're going to use some other GSAP utilities and we're no longer going to scrub the totalTime of LOOP_HEAD. Instead, we're going to update it via proxy. This is another great example of going “meta” GSAP.

Let’s start with a proxy object that marks the playhead position.

const PLAYHEAD = { position: 0 }

Now we can update our SCRUB to update the position. At the same time, we can use GSAP’s wrap utility, which wraps the position value around the LOOP_HEAD duration. For example, if the duration is 10 and we provide the value 11, we will get back 1.

const POSITION_WRAP = gsap.utils.wrap(0, LOOP_HEAD.duration())

const SCRUB = gsap.to(PLAYHEAD, {
  position: 0,
  onUpdate: () => {
    LOOP_HEAD.totalTime(POSITION_WRAP(PLAYHEAD.position))
  },
  paused: true,
  duration: 1,
  ease: 'none',
})

Last, but not least, we need to revise ScrollTrigger so it updates the correct variable on the SCRUB. That’s position, instead of totalTime.

ScrollTrigger.create({
  start: 0,
  end: '+=2000',
  horizontal: false,
  pin: '.boxes',
  onUpdate: self => {
    SCRUB.vars.position = LOOP_HEAD.duration() * self.progress
    SCRUB.invalidate().restart()
  }
})

At this point we’ve switched to a proxy and we won’t see any changes.

We want an infinite loop when we scroll. Our first thought might be to scroll to the start when we complete scroll progress. And it would do exactly that, scroll back. Although that's what we want to do, we don't want the playhead to scrub backwards. This is where totalTime comes in. Remember? It gets or sets the position of the playhead according to the totalDuration which includes any repeats and repeat delays.

For example, say the duration of the loop head was 5 and we got there, we won't scrub back to 0. Instead, we will keep scrubbing the loop head to 10. If we keep going, it'll go to 15, and so on. Meanwhile, we'll keep track of an iteration variable because that tells us where we are in the scrub. We'll also make sure that we only update iteration when we hit the progress thresholds.

Let’s start with an iteration variable:

let iteration = 0

Now let’s update our ScrollTrigger implementation:

const TRIGGER = ScrollTrigger.create({
  start: 0,
  end: '+=2000',
  horizontal: false,
  pin: '.boxes',
  onUpdate: self => {
    const SCROLL = self.scroll()
    if (SCROLL > self.end - 1) {
      // Go forwards in time
      WRAP(1, 1)
    } else if (SCROLL < 1 && self.direction < 0) {
      // Go backwards in time
      WRAP(-1, self.end - 1)
    } else {
      SCRUB.vars.position = (iteration + self.progress) * LOOP_HEAD.duration() // HIGIHLIGHT
      SCRUB.invalidate().restart()
    }
  }
})

Notice how we're now factoring iteration into the position calculation. Remember that this gets wrapped with the scrubber. We're also detecting when we hit the limits of our scroll, and that's the point where we WRAP. This function sets the appropriate iteration value and sets the new scroll position.

const WRAP = (iterationDelta, scrollTo) => {
  iteration += iterationDelta
  TRIGGER.scroll(scrollTo)
  TRIGGER.update()
}

We have infinite scrolling! If you have one of those fancy mice with the scroll wheel that you can let loose on, give it a go! It’s fun!

Here’s a demo that displays the current iteration and progress:

Scroll snapping

We're there. But, there are always ”nice to haves" when working on a feature like this. Let's start with scroll snapping. GSAP makes this easy, as we can use gsap.utils.snap without any other dependencies. That handles snapping to a time when we provide the points. We declare the step between 0 and 1 and we have 10 boxes in our example. That means a snap of 0.1 would work for us.

const SNAP = gsap.utils.snap(1 / BOXES.length)

And that returns a function we can use to snap our position value.

We only want to snap once the scroll has ended. For that, we can use an event listener on ScrollTrigger. When the scroll ends, we are going to scroll to a certain position.

ScrollTrigger.addEventListener('scrollEnd', () => {
  scrollToPosition(SCRUB.vars.position)
})

And here’s scrollToPosition:

const scrollToPosition = position => {
  const SNAP_POS = SNAP(position)
  const PROGRESS =
    (SNAP_POS - LOOP_HEAD.duration() * iteration) / LOOP_HEAD.duration()
  const SCROLL = progressToScroll(PROGRESS)
  TRIGGER.scroll(SCROLL)
}

What are we doing here?

Calculating the point in time to snap to
Calculating the current progress. Let’s say the LOOP_HEAD.duration() is 1 and we’ve snapped to 2.5. That gives us a progress of 0.5 resulting in an iteration of 2, where 2.5 - 1 * 2 / 1 === 0.5 . We calculate the progress so that it’s always between 1 and 0.
Calculating the scroll destination. This is a fraction of the distance our ScrollTrigger can cover. In our example, we’ve set a distance of 2000 and we want a fraction of that. We create a new function progressToScroll to calculate it.

const progressToScroll = progress =>
  gsap.utils.clamp(1, TRIGGER.end - 1, gsap.utils.wrap(0, 1, progress) * TRIGGER.end)

This function takes the progress value and maps it to the largest scroll distance. But we use a clamp to make sure the value can never be 0 or 2000. This is important. We are safeguarding against snapping to these values as it would put us in an infinite loop.

There is a bit to take in there. Check out this demo that shows the updated values on each snap.

Why are things a lot snappier? The scrubbing duration and ease have been altered. A smaller duration and punchier ease give us the snap.

const SCRUB = gsap.to(PLAYHEAD, {
  position: 0,
  onUpdate: () => {
    LOOP_HEAD.totalTime(POSITION_WRAP(PLAYHEAD.position))
  },
  paused: true,
  duration: 0.25,
  ease: 'power3',
})

But, if you played with that demo, you'll notice there's an issue. Sometimes when we wrap around inside the snap, the playhead jumps about. We need to account for that by making sure we wrap when we snap — but, only when it's necessary.

const scrollToPosition = position => {
  const SNAP_POS = SNAP(position)
  const PROGRESS =
    (SNAP_POS - LOOP_HEAD.duration() * iteration) / LOOP_HEAD.duration()
  const SCROLL = progressToScroll(PROGRESS)
  if (PROGRESS >= 1 || PROGRESS < 0) return WRAP(Math.floor(PROGRESS), SCROLL)
  TRIGGER.scroll(SCROLL)
}

And now we have infinite scrolling with snapping!

What next?

We've completed the groundwork for a solid infinite scroller. We can leverage that to add things, like controls or keyboard functionality. For example, this could be a way to hook up "Next" and "Previous" buttons and keyboard controls. All we have to do is manipulate time, right?

const NEXT = () => scrollToPosition(SCRUB.vars.position - (1 / BOXES.length))
const PREV = () => scrollToPosition(SCRUB.vars.position + (1 / BOXES.length))

// Left and Right arrow plus A and D
document.addEventListener('keydown', event => {
  if (event.keyCode === 37 || event.keyCode === 65) NEXT()
  if (event.keyCode === 39 || event.keyCode === 68) PREV()
})

document.querySelector('.next').addEventListener('click', NEXT)
document.querySelector('.prev').addEventListener('click', PREV)

That could give us something like this.

We can leverage our scrollToPosition function and bump the value as we need.

That’s it!

See that? GSAP can animate more than elements! Here, we bent and manipulated time to create an almost perfect infinite slider. No duplicate elements, no mess, and good flexibility.

Let’s recap what we covered:

We can animate an animation. 🤯
We can think about timing as a positioning tools when we manipulate time.
How to use ScrollTrigger to scrub an animation via proxy.
How to use some of GSAP’s awesome utilities to handle logic for us.

You can now manipulate time! 😅

That concept of going "meta” GSAP opens up a variety of possibilities. What else could you animate? Audio? Video? As for the ”Cover Flow” demo, here’s where that went!

Stay Awesome! ʕ •ᴥ•ʔ

Squeaky Portraits: Having Fun with the CSS path() Function

Jhey Tompkins — Thu, 29 Apr 2021 20:09:59 +0000

With the Chrome 88 release, we got support for clip-path: path(). That means it now has support in "most" major browsers!

With path(), we’re able to use path definitions for a clip-path (Catch up on what clip-path is here). These path definition strings are the same as those we can use with the SVG path element. What's cool about this is that it provides a way to create shapes that before may have meant using SVG. We can even create paths that break without requiring any tricks.

With the increased support came an opportunity to try something fun with it! Let’s make “Squeaky Portraits”! A fun take on using clip-path: path() to clip the viewable area of an element into these “Nickelodeon-esque” splats.

// Detect dark theme var iframe = document.getElementById('tweet-1360019670393360389-622'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1360019670393360389&theme=dark" }

Creating a Path

First up, we need our own SVG style path definition string. And in this case, more than one. The neat thing with clip-path is that we can transition them with CSS. As long as the clip-path function and number of nodes are consistent, we can transition.

To make some paths, we can hop in any vector graphic editor. In this case, I’m using Figma. And instead of creating the paths from scratch, we can use a desired "splat" as a foundation. This one looks good!

The trick here is to create more splats based on the foundation splat. And we need to do this without introducing or removing any nodes. These are the three splats I came up with. But, you could make any shapes you like as long as you stick to that rule!

You may notice that the third splat has two blobs that separate off from the main shape. This is fine. Because SVG path definitions allow us to do this. We can start a line, close it, and move to another point to start another.

But didn't I say they needed a consistent number of points? They do. And they do! Those two blobs appear for each splat. But, the trick is that we can move them behind the rest of the path when they aren't needed.

Once we have our splats, we can export them and grab the path definition strings.

Applying Splats

To apply the splats, we're going to create variables for each path.

.portrait {
  --splat: "M161 188.375C170 193.5 177.919 193.854 186 188.375C197.919 180.294...";
  --splattier: "M161 188.375C170 193.5 177.919 193.854 186 188.375C197.919...";
  --splatted: "M232.5 256C225 251 209.5 262.5 224 281.5C232.736 292.948...";
}

These are the paths we’ve lifted straight out of the exported SVG.

We’re going with the names “splat”, “splattier”, and “splatted”. Naming things is hard. Ha! But, if we take for example the “splatted” SVG.

<svg width="300" height="300" viewBox="0 0 300 300" fill="none" xmlns="http://www.w3.org/2000/svg">
  <path d="M232.5 256C225 251 209.5 262.5 224 281.5C232.736 292.948 238.561 297.756 251 290.5C257 287 256.114 271.924 250 264.5C243.886 257.076 240 261 232.5 256ZM147 92.5C118.738 94.6708 118 17 93 44C68 71 123.543 76.5 108 101.5C90.5 115 70.81 98.3664 64 115C56.7766 132.643 91.1967 136.948 90.5 156C89.4406 184.974 19.1766 161.499 24.5 190C29.9178 219.006 78.6461 172.635 100 193C130.207 221.808 1 248.5 58.5 291.5C94.5576 318.465 114.991 206.551 140.5 211C183.5 218.5 134.5 294 186.5 279.5C207.5 273 174.638 224.658 196 204C223.117 177.777 275.916 253 291.5 218.5C311.375 174.5 228.698 194.565 224 160C219.553 127.282 291.5 123.5 267.5 87.5C238.5 57 247 125.5 196 105.5C147 92.5 229.5 13.5 173.5 2.5C140.5 2.49999 183.532 89.694 147 92.5ZM45 92.5C36.8766 80.3149 14.1234 75.3149 6.00001 87.5C0.584412 95.6234 2.00001 120.357 14.5 115C27.9606 109.231 36.8766 124.685 45 112.5C50.4156 104.377 50.4156 100.623 45 92.5Z" fill="#A91CFF"/>
</svg>

We’re lifting out the d attribute from the path elements and creating CSS variables for them. Next, we need an element to apply these to. Let's create an element with the class "portrait".

<div class="portrait"></div>

Next, apply some styling to it:

.portrait {
  --splat: "M161 188.375C170 193.5 177.919 193.854 186 188.375C197.919 180.294...";
  --splattier: "M161 188.375C170 193.5 177.919 193.854 186 188.375C197.919...";
  --splatted: "M232.5 256C225 251 209.5 262.5 224 281.5C232.736 292.948...";
  --none: "";
  height: 300px;
  width: 300px;
  background: #daa3f5;
  clip-path: path(var(--clip, var(--none)));
  transition: clip-path 0.2s;
}

Here’s a demo where you can switch between the different clip states:

Note how the shape transitions between the three splat shapes. But, also note how we've given our element an explicit height and width. This size matches the dimensions of our SVG exports. This is important. This is the one drawback of using clip-path: path(). It's not responsive. The path definition is relative to the dimensions of your element. This is the same problem faced by CSS motion paths.

This is fine if we're mindful of the sizes of things we're clipping. We could also create different path variables for different viewport sizes. But, if you have images that resize in a fluid way, other solutions using SVG are going to be more robust.

Interaction

For our demo, we want the splat to be interactive. We can do this with CSS alone. We can use a scoped CSS variable --clip to control the current clip. And then we can update that variable on both :hover and :active. The --active state is triggered when we press our pointer down.

.portrait {
  clip-path: path(var(--clip, var(--splat)));
}
.portrait:hover {
  --clip: var(--splattier);
}
.portrait:active {
  --clip: var(--splatted);
}

Throw that together and we get something like this. Try hovering over the splat and pressing it.

Adding Some Character

Now we can transition the splat, it needs a little something extra. What if we transform it in those states too?

.portrait {
  transition: clip-path 0.2s, transform 0.2s;
  transform: scale(var(--scale, 1)) rotate(var(--rotate, 0deg));
}
.portrait:hover {
  --scale: 1.15;
  --rotate: 30deg;
}
.portrait:active {
  --scale: 0.85;
  --rotate: -10deg;
}

Using scoped CSS variables to apply a transform, we can add something. Here we update the scale and rotation of our splat. We can experiment with different values and play with different effects here. Translating the element a little could look good?

Adding a Portrait.

Now for the fun stuff! I wouldn't recommend using these pictures of me. But, you can if you want ha! I had this idea that I'd take three silly pictures of myself and have them respond to the user. I got some help and ended up with these three pictures.

Then we need to put them into the portrait.

<div class="portrait">
  <img class="portrait__img" src="/me--standing.png" alt="Me"/>
  <img class="portrait__img" src="/me--noticing.png" alt="Me"/>
  <img class="portrait__img" src="/me--falling.png" alt="Me"/>
</div>

That won’t look great. They need some styles.

.portrait {
  position: relative;
}
.portrait__img {
  height: 100%;
  width: 100%;
  position: absolute;
  top: 0;
  left: 0;
}

Almost.

How can we show and hide them on :hover and :active. It's a little verbose but we can use nth-of-type with display: none.

.portrait__img {
  display: none;
}
.portrait__img:nth-of-type(1) {
  display: block;
}
.portrait:hover .portrait__img:nth-of-type(1),
.portrait:hover .portrait__img:nth-of-type(3) {
  display: none;
}
.portrait:hover .portrait__img:nth-of-type(2) {
  display: block;
}
.portrait:active .portrait__img:nth-of-type(1),
.portrait:active .portrait__img:nth-of-type(2) {
  display: none;
}
.portrait:active .portrait__img:nth-of-type(3) {
  display: block;
}

Why not refactor those styles and group them up? The cascade will kick in and we won't get the effect we want.

Parallax Icons

We're getting there but it looks a little bland. We could create a rudimentary parallax effect if we pull in an icon. Let's go with this one.

The trick here is to use an image as a background for our element but size it so that it tiles with background-repeat.

.portrait {
  background-image: url("/code-icon.svg");
  background-color: hsl(10, 80%, 70%);
}

Neat.

But, we want parallax! To get that parallax effect, we can update the background-position in response to pointer movement. And we can map the pointer position against some limit that we define.

Let's start by creating a utility that generates a mapping function for us. The returned function will give us the result of a value in one range mapped onto another.

const genMapper = (inputLower, inputUpper, outputLower, outputUpper) => {
  const inputRange = inputUpper - inputLower
  const outputRange = outputUpper - outputLower
  const MAP = input => outputLower + (((input - inputLower) / inputRange) * outputRange || 0)
  return MAP
}

Take a moment to understand what’s happening here. For example, if our input range was 0 to 500 and our output range was 0 to 100. What would the result of calling the returned function be with 250? It would be 50.

// Generate a function
genMapper(0, 500, 0, 100)
// Returns a function by going through these steps
const inputRange = 500
const outputRange = 100
const MAP => input => 0 + (((input - 0) / 500) * 100)
// If our input value is 250
(250 / 500) * 100
0.5 * 100
// The result!
50

Once we have our utility function to generate the mapping functions, we need a limit to use with it. And we need to generate a mapper for both the horizontal and vertical axes.

const LIMIT = 25 // The amount our icons can move in pixels in either direction
const getX = genMapper(0, window.innerWidth, -LIMIT, LIMIT)
const getY = genMapper(0, window.innerHeight, -LIMIT, LIMIT)

The final part is tying that up to an event listener. We destructure the x and y value from the event and set CSS variables on the portrait element. The value comes from passing x and y into the respective mapping functions.

const PORTRAIT = document.querySelector('.portrait')
document.addEventListener('pointermove', ({ x, y }) => {
  PORTRAIT.style.setProperty('--x', getX(x))
  PORTRAIT.style.setProperty('--y', getY(y))
})

And now we have parallax icons!

The Squeak

Last touch. It's in the title. We need some squeaks. I usually find audio bytes on sites like freesound.org. You can get them in all places though and even record them yourself if you want.

It’s not a bad idea to create an object where you can reference your Audio.

const AUDIO = {
  IN: new Audio('/squeak-in.mp3'),
  OUT: new Audio('/squeak-out.mp3'),
}

Then, to play an audio clip, all we need do is

AUDIO.IN.play()

We need to integrate this with our portrait. We can use the pointerdown and pointerup events here – the idea being that we play one squeak when we press and another on release.

If a user clicks the portrait a lot in quick succession this could cause undesirable effects. The trick is to play the desired sound and at the same time, stop the other. To "stop" a piece of Audio, we can pause it and set the currentTime to 0.

PORTRAIT.addEventListener('pointerdown', () => {
  AUDIO.OUT.pause()
  AUDIO.IN.currentTime = AUDIO.OUT.currentTime = 0
  AUDIO.IN.play()
})
PORTRAIT.addEventListener('pointerup', () => {
  AUDIO.IN.pause()
  AUDIO.IN.currentTime = AUDIO.OUT.currentTime = 0
  AUDIO.OUT.play()
})

And that gives us a “Squeaky Portrait”!

That’s It!

That's how you make "Squeaky Portraits". But, the actionable thing here is having fun while trying out new things.

I could have morphed a couple of shapes and left it there. But, why stop there? Why not come up with an idea and have some fun with it? It's a great way to try things out and explore techniques.

We:

Created the clips
Morphed them with transitions
Made interactive images
Added Audio
Created parallax with a mapping utility

What could you do with clip-path: path()? What would your "Squeaky Portrait" look like? It could do something completely different. I'd love to see what you make!

As always, thanks for reading. Wanna see more? Come find me on Twitter or check out the the live stream!

p.s If you want to grab all the code. It’s here in this CodePen collection.

Stay Awesome! ʕ •ᴥ•ʔ

Make a Functional Stopwatch with CSS – Exploring @property and its Animating Powers

Jhey Tompkins — Wed, 21 Apr 2021 18:55:01 +0000

Uh, what’s @property? It’s a new CSS feature! It gives you superpowers. No joke, there is stuff that @property can do that unlocks things in CSS we’ve never been able to do before.

Want to make a stopwatch with nothing but HTML and CSS? Read on!

While everything about @property is exciting, perhaps the most interesting thing is that it provides a way to specify a type for custom CSS properties. A type provides more contextual information to the browser, and that results in something cool: We can give the browser the information it needs to transition and animate those properties!

But before we get too giddy about this, it’s worth noting that support isn’t quite there. As it currently stands at the time of this writing, @property is supported in Chrome and, by extension, Edge. We need to keep an eye on browser support for when we get to use this in other places, like Firefox and Safari.

First off, we get type checking

@property --spinAngle {
  /* An initial value for our custom property */
  initial-value: 0deg;
  /* Whether it inherits from parent set values or not */
  inherits: false;
  /* The type. Yes, the type. You thought TypeScript was cool */
  syntax: '<angle>';
}

@keyframes spin {
  to {
    --spinAngle: 360deg;
  }
}

That’s right! Type checking in CSS. It’s sorta like creating our very own mini CSS specification. And that's a simple example. Check out all of the various types we have at our disposal:

length
number
percentage
length-percentage
color
image
url
integer
angle
time
resolution
transform-list
transform-function
custom-ident (a custom identifier string)

Before any of this, we may have relied on using "tricks" for powering animations with custom properties.

Liquid error: internal

What cool stuff can we do then? Let’s take a look to spark your imagination.

Let's Animate Color

How might you animate an element either through a series of colors or between them? I’m a big advocate for the HSL color space which breaks things down into fairly understandable numbers: hue, saturation, and lightness, respectively.

Animating a hue feels like something fun we can do. What’s colorful? A rainbow! There’s a variety of ways we could make a rainbow. Here’s one:

In this example, CSS Custom Properties are set on the different bands of the rainbow using :nth-child() to scope them to individual bands. Each band also has an --index set to help with sizing.

To animate those bands, we might use that --index to set some negative animation delays, but then use the same keyframe animation to cycle through hues.

.rainbow__band {
  border-color: hsl(var(--hue, 10), 80%, 50%);
  animation: rainbow 2s calc(var(--index, 0) * -0.2s) infinite linear;
}

@keyframes rainbow {
  0%, 100% {
    --hue: 10;
  }
  14% {
    --hue: 35;
  }
  28% {
    --hue: 55;
  }
  42% {
    --hue: 110;
  }
  56% {
    --hue: 200;
  }
  70% {
    --hue: 230;
  }
  84% {
    --hue: 280;
  }
}

That might work out okay if you want a "stepped" effect. But, those keyframe steps aren’t particularly accurate. I’ve used steps of 14% as a rough jump.

We could animate the border-color and that would get the job done. But, we'd still have a keyframe step calculation issue. And we need to write a lot of CSS to get this done:

@keyframes rainbow {
  0%, 100% {
    border-color: hsl(10, 80%, 50%);
  }
  14% {
    border-color: hsl(35, 80%, 50%);
  }
  28% {
    border-color: hsl(55, 80%, 50%);
  }
  42% {
    border-color: hsl(110, 80%, 50%);
  }
  56% {
    border-color: hsl(200, 80%, 50%);
  }
  70% {
    border-color: hsl(230, 80%, 50%);
  }
  84% {
    border-color: hsl(280, 80%, 50%);
  }
}

Enter @property. Let’s start by defining a custom property for hue. This tells the browser our custom property, --hue, is going to be a number (not a string that looks like a number):

@property --hue {
  initial-value: 0;
  inherits: false;
  syntax: '<number>';
}

Hue values in HSL can go from 0 to 360. We start with an initial value of 0. The value isn't going to inherit. And our value, in this case, is a number. The animation is as straightforward as:

@keyframes rainbow {
  to {
    --hue: 360;
  }
}

Yep, that’s the ticket:

To get the starting points accurate, we could play with delays for each band. This gives us some cool flexibility. For example, we can up the animation-duration and we get a slow cycle. Have a play with the speed in this demo.

It may not be the “wildest” of examples, but I think animating color has some fun opportunities when we use color spaces that make logical use of numbers. Animating through the color wheel before required some trickiness. For example, generating keyframes with a preprocessor, like Stylus:

@keyframes party
  for $frame in (0..100)
    {$frame * 1%}
      background 'hsl(%s, 65%, 40%)' % ($frame * 3.6)

We do this purely because this isn’t understood by the browser. It sees going from 0 to 360 on the color wheel as an instant transition because both HSL values show the same color.

@keyframes party {
  from {
    background: hsl(0, 80%, 50%);
  }
  to {
    background: hsl(360, 80%, 50%);
  }
}

The keyframes are the same, so the browser assumes the animation stays at the same background value when what we actually want is for the browser to go through the entire hue spectrum, starting at one value and ending at that same value after it goes through the motions.

Think of all the other opportunities we have here. We can:

animate the saturation
use different easings
animate the lightness
Try rgb()
Try degrees in hsl() and declare our custom property type as <angle>

What's neat is that we can share that animated value across elements with scoping! Consider this button. The border and shadow animate through the color wheel on hover.

Animating color leads me to think… wow!

Straight-up numbering

Because we can define types for numbers—like integer and number—that means we can also animate numbers instead of using those numbers as part of something else. Carter Li actually wrote an article on this over on CSS-Tricks. The trick is to use an integer in combination with CSS counters. This is similar to how we can work the counter in "Pure CSS" games like this one.

The use of counter and pseudo-elements provides a way to convert a number to a string. Then we can use that string for the content of a pseudo-element. Here are the important bits:

@property --milliseconds {
  inherits: false;
  initial-value: 0;
  syntax: '<integer>';
}

.counter {
  counter-reset: ms var(--milliseconds);
  animation: count 1s steps(100) infinite;
}

.counter:after {
  content: counter(ms);
}

@keyframes count {
  to {
    --milliseconds: 100;
  }
}

Which gives us something like this. Pretty cool.

Take that a little further and you’ve got yourself a working stopwatch made with nothing but CSS and HTML. Click the buttons! The rad thing here is that this actually works as a timer. It won’t suffer from drift. In some ways, it may be more accurate than the JavaScript solutions we often reach for such as setInterval. Check out this great video from Google Chrome Developer about JavaScript counters.

Who'd have thought it? Making a working stopwatch with nothing but CSS! In fact, people were pretty interested in that stopwatch. It prompted a walkthrough over on YouTube.

What other things could you use animated numbers for? A countdown perhaps?

Animated gradients

You know the ones, linear, radial, and conic. Ever been in a spot where you wanted to transition or animate the color stops? Well, @property can do that!

Consider a gradient where we're creating some waves on a beach. Once we've layered up some images we could make something like this.

body {
  background-image:
    linear-gradient(transparent 0 calc(35% + (var(--wave) * 0.5)), var(--wave-four) calc(75% + var(--wave)) 100%),
    linear-gradient(transparent 0 calc(35% + (var(--wave) * 0.5)), var(--wave-three) calc(50% + var(--wave)) calc(75% + var(--wave))),
    linear-gradient(transparent 0 calc(20% + (var(--wave) * 0.5)), var(--wave-two) calc(35% + var(--wave)) calc(50% + var(--wave))),
    linear-gradient(transparent 0 calc(15% + (var(--wave) * 0.5)), var(--wave-one) calc(25% + var(--wave)) calc(35% + var(--wave))), var(--sand);
}

There is quite a bit going on there. But, to break it down, we're creating each color stop with calc(). And in that calculation, we add the value of --wave. The neat trick here is that when we animate that --wave value, all the wave layers move.

This is all the code we needed to make that happen:

body {
  animation: waves 5s infinite ease-in-out;
}
@keyframes waves {
  50% {
    --wave: 25%;
  }
}

Without the use of @property, our waves would step between high and low tide. But, with it, we get a nice chilled effect like this.

It's exciting to think other neat opportunities that we get when manipulating images. Like rotation. Or how about animating the angle of a conic-gradient… but, within a border-image. Bramus Van Damme does a brilliant job of covering this concept.

Let's break it down by creating a charging indicator. We’re going to animate an angle and a hue at the same time. We can start with two custom properties:

@property --angle {
  initial-value: 0deg;
  inherits: false;
  syntax: '<angle>';
}

@property --hue {
  initial-value: 0;
  inherits: false;
  syntax: '<number>';
}

The animation will update the angle and hue with a slight pause on each iteration.

@keyframes load {
  0%, 10% {
    --angle: 0deg;
    --hue: 0;
  }
  100% {
    --angle: 360deg;
    --hue: 100;
  }
}

Now let’s apply it as the border-image of an element.

.loader {
  --charge: hsl(var(--hue), 80%, 50%);
  border-image: conic-gradient(var(--charge) var(--angle), transparent calc(var(--angle) * 0.5deg)) 30;
  animation: load 2s infinite ease-in-out;
}

Pretty cool.

Unfortunately, border-image doesn't play nice with border-radius. But, we could use a pseudo-element behind it. Combine it with the number animation tricks from before and we've got a full charging/loading animation. (Yep, it changes when it gets to 100%.)

Transforms are cool, too

One issue with animating transforms is transitioning between certain parts. It often ends up breaking or not looking how it should. Consider the classic example of a ball being throw. We want it to go from point A to point B while imitating the effect of gravity.

An initial attempt might look like this

@keyframes throw {
  0% {
    transform: translate(-500%, 0);
  }
  50% {
    transform: translate(0, -250%);
  }
  100% {
    transform: translate(500%, 0);
  }
}

But, we’ll soon see that it doesn’t look anything like we want.

Before, we may have reached for wrapper elements and animated them in isolation. But, with @property, we can animate the individual values of the transform. And all on one timeline. Let's flip the way this works by defining custom properties and then setting a transform on the ball.

@property --x {
  inherits: false;
  initial-value: 0%;
  syntax: '<percentage>';
}

@property --y {
  inherits: false;
  initial-value: 0%;
  syntax: '<percentage>';
}

@property --rotate {
  inherits: false;
  initial-value: 0deg;
  syntax: '<angle>';
}

.ball {
  animation: throw 1s infinite alternate ease-in-out;
  transform: translateX(var(--x)) translateY(var(--y)) rotate(var(--rotate));
}

Now for our animation, we can compose the transform we want against the keyframes:

@keyframes throw {
  0% {
    --x: -500%;
    --rotate: 0deg;
  }
  50% {
    --y: -250%;
  }
  100% {
    --x: 500%;
    --rotate: 360deg;
  }
}

The result? The curved path we had hoped for. And we can make that look different depending on the different timing functions we use. We could split the animation into three ways and use different timing functions. That would give us different results for the way the ball moves.

Consider another example where we have a car that we want to drive around a square with rounded corners.

We can use a similar approach to what we did with the ball:

@property --x {
  inherits: false;
  initial-value: -22.5;
  syntax: '<number>';
}

@property --y {
  inherits: false;
  initial-value: 0;
  syntax: '<number>';
}

@property --r {
  inherits: false;
  initial-value: 0deg;
  syntax: '<angle>';
}

The car's transform is using calculated with vmin to keep things responsive:

.car {
  transform: translate(calc(var(--x) * 1vmin), calc(var(--y) * 1vmin)) rotate(var(--r));
}

Now can write an extremely accurate frame-by-frame journey for the car. We could start with the value of --x.

@keyframes journey {
  0%, 100% {
    --x: -22.5;
  }
  25% {
    --x: 0;
  }
  50% {
    --x: 22.5;
  }
  75% {
    --x: 0;
  }
}

The car makes the right journey on the x-axis.

Then we build upon that by adding the travel for the y-axis:

@keyframes journey {
  0%, 100% {
    --x: -22.5;
    --y: 0;
  }
  25% {
    --x: 0;
    --y: -22.5;
  }
  50% {
    --x: 22.5;
    --y: 0;
  }
  75% {
    --x: 0;
    --y: 22.5;
  }
}

Well, that’s not quite right.

Let’s drop some extra steps into our @keyframes to smooth things out:

@keyframes journey {
  0%, 100% {
    --x: -22.5;
    --y: 0;
  }
  12.5% {
    --x: -22.5;
    --y: -22.5;
  }
  25% {
    --x: 0;
    --y: -22.5;
  }
  37.5% {
    --y: -22.5;
    --x: 22.5;
  }
  50% {
    --x: 22.5;
    --y: 0;
  }
  62.5% {
    --x: 22.5;
    --y: 22.5;
  }
  75% {
    --x: 0;
    --y: 22.5;
  }
  87.5% {
    --x: -22.5;
    --y: 22.5;
  }
}

Ah, much better now:

All that's left is the car's rotation. We're going with a 5% window around the corners. It's not precise but it definitely shows the potential of what’s possible:

@keyframes journey {
  0% {
    --x: -22.5;
    --y: 0;
    --r: 0deg;
  }
  10% {
    --r: 0deg;
  }
  12.5% {
    --x: -22.5;
    --y: -22.5;
  }
  15% {
    --r: 90deg;
  }
  25% {
    --x: 0;
    --y: -22.5;
  }
  35% {
    --r: 90deg;
  }
  37.5% {
    --y: -22.5;
    --x: 22.5;
  }
  40% {
    --r: 180deg;
  }
  50% {
    --x: 22.5;
    --y: 0;
  }
  60% {
    --r: 180deg;
  }
  62.5% {
    --x: 22.5;
    --y: 22.5;
  }
  65% {
    --r: 270deg;
  }
  75% {
    --x: 0;
    --y: 22.5;
  }
  85% {
    --r: 270deg;
  }
  87.5% {
    --x: -22.5;
    --y: 22.5;
  }
  90% {
    --r: 360deg;
  }
  100% {
    --x: -22.5;
    --y: 0;
    --r: 360deg;
  }
}

And there we have it, a car driving around a curved square! No wrappers, no need for complex Math. And we composed it all with custom properties.

Powering an entire scene with variables

When you start putting it all together, @property opens up new opportunities. You can start to power scenes with few properties. Consider this 404 concept page. Two registered properties power the different moving parts. We have a moving gradient we clip with the text using -webkit-background-clip. We make the shadow move by reading the values of the properties. And we swing another element for the light effect.

That’s it!

It's exciting to think about what types of things we can do with the ability to define types with @property. By giving the browser additional context about a custom property, we can go nuts in ways we couldn’t before with basic strings.

What ideas do you have for the other types? Time and resolution would make for interesting transitions, though I’ll admit I wasn't able to make them work that way I was hoping. url could also be neat, like perhaps transitioning between a range of sources the way an image carousel typically does. Just brainstorming here!

I hope this quick look at @property inspires you to go check it out and make your own awesome demos! I look forward to seeing what you make. In fact, please share them with me here in the comments!

As always, thanks for reading. Wanna know more? Wanna see something else? Come find me on Twitter!

Stay awesome! ʕ •ᴥ•ʔ

Go Headless with Netlify CMS

Jhey Tompkins — Wed, 31 Mar 2021 15:19:10 +0000

Got a site? How easy is it to make content changes? Are you using a CMS? What's a CMS? How do I set up a CMS?

After this article, you'll know how to get up and running with Netlify CMS. And you'll know some tricks to make your life easier.

Set up Netlify CMS with Next.js
Use netlify-cli
Make use of Netlify CMS Beta features!

What's a CMS?

A content management system(CMS) is a convenient way for you to manage content. Think of it as a special place you visit that allows you to update your website. Update images, copy, content! It can live on the same domain or a completely different one.

What's a "headless" CMS? This means that our CMS is not coupled to a front end. It has no notion of how the content will get displayed. This is ideal. It gives portability to our content. Want to switch front-end frameworks? Cool! Drop all your content into something new. The underlying structure of what you're presenting doesn't have to change.

Why CMS?

We mentioned it there. But, "Portability". Decoupling your content from the presentation layer has the benefit of "Create once, display anywhere!". Also, "Convenience". Realized you made a typo on your site? But, you're not at your desk? Log into your CMS, make the change, hit "Publish", done! It also opens your content up for a more collaborative experience. Want to support different authors or guest posting? Create separate logins for those users.

Netlify CMS

Netlify CMS is a great option if you're new to CMS and even if you're not. It's an interesting offering that is "Git Based". That means it creates and updates the content in your Git repo. This is great if you're new to CMSs as you have the ability to see the content changes on your machine as you develop. It's very customizable too. Think custom widgets and previews.

Setting Up Netlify CMS

For today's demo, we're going to set up Netlify CMS with a Next.js site. The set up is the same though for whatever you use. If you don't have an app to use, follow along and create a Next.js site.

The prerequisites?

Github/Gitlab/Bitbucket account
Netlify account
Optional – An app to integrate. Or create a demo app from the steps below.

For those in camp TL;DR , you can grab the demo app and starter kit from this repo.

Create App

Let's get started by creating an app.

yarn create next-app netlify-cms-next-starter

And for this app, I've gone ahead and pulled Tailwind in with the new shiny "JIT" compiler.

Install Netlify CMS

Then we need netlify-cms-app.

yarn add netlify-cms-app

Set Up Admin Page

Next, we need an "admin" page. This needs to be accessible via /admin. Different frameworks have different ways of doing this. We're using Next.js. We could drop an HTML file into public at public/admin/index.html or create pages/admin/index.js.

The straight HTML would use the CDN links for Netlify CMS and looks like this.

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Admin: Netlify CMS && Next.js Starter</title>
    <link rel="shortcut icon" href="/assets/icons/favicon-32x32.png" />
    <link rel="apple-touch-icon" href="/assets/icons/logo-192x192.png" />
    <link rel="manifest" href="/manifest.webmanifest" />
    <script src="https://identity.netlify.com/v1/netlify-identity-widget.js"></script>
  </head>
  <body>
    <!-- Include the script that builds the page and powers Netlify CMS -->
    <script src="https://unpkg.com/netlify-cms@^2.0.0/dist/netlify-cms.js"></script>
  </body>
</html>

But, we've installed netlify-cms-app. That means we can start up the CMS from a module.

import CMS from 'netlify-cms-app'
// Initialize the CMS object
CMS.init()

We're using Next.js though. And that means we can do something a little different with our setup.

import dynamic from 'next/dynamic'

const CMS_CONFIG = {}
const Loading = () => (
  <div className="min-h-screen flex items-center justify-center">
    <p className="text-gray-500 font-semibold text-xl">Loading...</p>
  </div>
)

const CMS = dynamic(
  () =>
    import('netlify-cms-app').then((CMS) => {
      CMS.init({ CMS_CONFIG })
    }),
  { ssr: false, loading: Loading }
)

const Admin = () => <CMS />

export default Admin

Here, we load the netlify-cms-app dynamically into the browser with next/dynamic and then initialize the CMS.

Set Up CMS Config

The CMS is config-driven. We create a configuration file and this tells Netlify CMS what fields to show, what to update, etc. We need a config.yml file that our "Admin" page has access to. There are a variety of options for configuring the CMS. Here's a basic starting point. In this config, we're creating two collections. One handles global data such as site copy for example. The other is for standalone pages. This could be the same structure for creating blog posts, etc.

backend:
  name: git-gateway
  branch: main
publish_mode: editorial_workflow
media_folder: "public/images"
public_folder: "/images"
collections:
  - label: "Globals"
    name: "globals"
    files:
      - label: "Site Copy"
        name: "site_copy"
        delete: false
        create: true
        file: "_data/copy.json"
        fields:
          - { label: "Tagline", name: "tagline", widget: "string" }
          - { label: "Headline", name: "headline", widget: "string" }
  - name: "standalone pages"
    label: "Standalone Pages"
    folder: "standalone-pages"
    slug: ""
    file: "standalone-pages/.mdx"
    create: true
    extension: mdx
    format: frontmatter
    fields:
      - { label: "Title", name: "title", widget: "string" }
      - {
          label: "SEO Meta Title",
          name: "metaTitle",
          widget: "string",
          required: false,
        }
      - {
          label: "SEO Meta Description",
          name: "metaDesc",
          widget: "string",
          required: false,
        }
      - {
          label: "Social Image",
          name: "socialImage",
          widget: "image",
          required: false,
        }
      - { label: "Body", name: "body", widget: "markdown" }

We've got so many options for setting up Netlify CMS. The main things here are the "backend", "media_folder", and how our collections work.

When it comes to collections, we can define the types of files, where they live, how we create the content. For example, our standalone page collection. We are stating that the files will have the MDX extension and live under standalone-pages/. Each field under fields makes up the managed content for a page. In our example, we're using the string widget for text fields. But, the body of the file will be markdown. Note the format field on our collection? This tells Netlify CMS that we want to store the data in frontmatter and follow it with the content for body. It's worth checking out the "Configuration" docs and "Fields" docs.

Creating An Identity

If we start up our app and visit /admin we're hit with a login screen. The CMS is working! But, we don't have any credentials to log in with.

We need an identity for authentication. You can use different auth options. But, we're going to use Netlify Identity for auth. It's the quickest to set up and will give you exposure to using Netlify Identity if you've not used it before.

Open up your Netlify dashboard and you'll want to create a "New site from Git". That's assuming you've pushed your app to a Git repository.

This will take you through your site setup. Follow the prompts and Netlify will detect your build settings for you. Note how in our case, we get the neat "Essential Next.js" build plugin installed for us.

Now we need to enable "Identity" for our site. Navigate to the "Identity" tab and hit "Enable Identity".

Go into "Settings and usage" and hit "Enable Git Gateway". It's a bit of scrolling down.

We are almost there! Now we need to invite a user to use our CMS. Hit "Invite users" and send an invite to an email address you want to use.

Once you've done that, you'll see the user in the list.

Check your email and you should see one inviting you to join the app. But, if you hit the link, you'll get directed to your hosted site and nothing will happen. That's because we need to drop the identity widget into the page and run a piece of code for it.

This only needs to doing on our root page. We need the following code to run.

if (window.netlifyIdentity) {
  window.netlifyIdentity.on('init', (user) => {
    if (!user) {
      window.netlifyIdentity.on('login', () => {
        document.location.href = '/admin/'
      })
    }
  })
}

And this script included.

<script src="https://identity.netlify.com/v1/netlify-identity-widget.js"></script>

For our Next.js app, we could update our "Home" page to run the code in an effect and use next/head to include the script.

import { useEffect, Fragment } from 'react'
import Head from 'next/head'

const Home = () => {
  useEffect(() => {
    if (window.netlifyIdentity) {
      window.netlifyIdentity.on('init', (user) => {
        if (!user) {
          window.netlifyIdentity.on('login', () => {
            document.location.href = '/admin/'
          })
        }
      })
    }
  }, [])
  return (
    <Fragment>
      <Head>
        <title>Netlify CMS && Next.js Starter</title>
        <script src="https://identity.netlify.com/v1/netlify-identity-widget.js"></script>
      </Head>
      <main className="min-h-screen flex items-center justify-center mx-auto flex-col prose">
        <h1 className="text-center">Netlify CMS && Next.js Starter</h1>
      </main>
    </Fragment>
  )
}

Re-Deploy

For the changes to take effect, we need to re-deploy our site. We can do this by pushing our changes up to our git repo. Netlify will detect the changes and re-deploy for us.

Or, we could use netlify-cli to re-deploy our site. I recommend making use of netlify-cli. It can improve your workflow a lot. Especially if you've already got your terminal open. To use netlify-cli, install it first.

npm i -g netlify-cli

Once installed, login with

netlify login

And then from within your repo directory, link your repo to your site with

netlify link

Now you can build and deploy from the command line. Your build settings including plugins get pulled down for you too. It's a great way to get a deploy preview without opening a pull request too.

netlify build
netlify deploy

When you're happy with what you're deploying.

netlify build
netlify deploy --prod

Access the CMS

Once that's deployed, use your invite link from the email and you'll see a form to "Complete your signup". Create a password and you'll get logged in.

Now visit /admin and you'll get prompted for your CMS login details. Log in and we're in! We've set up a CMS for your site with Netlify CMS.

Update Content

Now we're in the CMS, have a poke around and explore what you can do. For example, upload an image or change the content in one of your collections. Here I've changed the content under a "Tagline" field in our "Globals" collection. When we're ready to push the changes, we hit "Save", update the status to "Ready", and then hit "Publish".

Next, it's a waiting game. Wait for the changes to get pushed. Pull them down to your repo in your terminal and you'll see that in our case _data/copy.json has updated. This was the path we defined in our config.yml file.

Now you can integrate your content any way you like with your frontend. For example, in our demo app, I've added an import path for _data. And I've updated the "Home" page to display the headline and tagline.

import { useEffect, Fragment } from 'react'
import Head from 'next/head'
import copy from '@data/copy.json'

const Home = () => {
  useEffect(() => {...}, [])
  return (
    <Fragment>
      <Head>
        <title>Netlify CMS && Next.js</title>
        <script src="https://identity.netlify.com/v1/netlify-identity-widget.js"></script>
      </Head>
      <main className="min-h-screen flex items-center justify-center mx-auto flex-col prose">
        <h1 className="text-center">{copy.headline}</h1>
        <h2>{copy.tagline}</h2>
      </main>
    </Fragment>
  )
}

At this stage, you've got a working CMS for your app. Explore the docs and manage your content any way you like. But, we're not quite done yet. Let's improve this setup.

Local Backend

We've got a working CMS. But, the workflow could be slow. Especially if we're feeling out what we're going to put in our CMS. We haven't got time to keep deploying, making changes in the CMS, and waiting for things to get pushed to Git. Builds take time and they'll use up your build minutes on Netlify.

To get around this we're going to use a Beta feature, local_backend. In fact, if you've been using Netlify CMS already, this trick might help you out a bunch if you didn't know about it.

To use local_backend, add it to our config.yml file.

local_backend: true
backend:
  name: git-gateway
  branch: main
publish_mode: editorial_workflow
media_folder: "public/images"
public_folder: "/images"

And then we have one more step. We need to use netlify-cms-proxy-server when we are developing. We can update our dev script to accommodate this.

"scripts": {
  "dev": "npx netlify-cms-proxy-server & next dev",
}

Run our dev server and visit /admin. We're in! No log-in screen required. Make some content changes, hit publish, and the content gets updated in your directory. Awesome. This improves our workflow tenfold. No more waiting.

This is all possible because of netlify-cms-proxy-server which creates a local unauthenticated server. This is what the CMS runs on when we use local_backend. You can configure local_backend in different ways. And you don't have to worry if you deploy a config.yml file with local_backend on.

But, if that doesn't sit right with you, you can write a node script that you run when running your dev server.

Here's a script you can use that copies your config.yml to the public directory on change. It uses chokidar to watch the file changes and logs any activity with pino.

const chokidar = require('chokidar')
const logger = require('pino')({ prettyPrint: true })
const fs = require('fs')

// Write file to public/config.yml
const writeConfig = () => {
  logger.info('Updating Netlify CMS Config')
  const CONFIG = fs.readFileSync('./admin/config.yml', 'utf-8')
  fs.writeFileSync(
    `${process.cwd()}/public/config.yml`,
    `local_backend: true\n${CONFIG}`,
    'utf-8'
  )
}
// Set up Netlify CMS Config Watching
logger.info('Setting up Netlify CMS config watch')
chokidar.watch(`${process.cwd()}/admin/config.yml`).on('change', writeConfig)
// Write on script run so it's there
writeConfig()

In this script, we are copying the config and appending the local_backend option. This means we no longer need a committed version of config.yml inside public. In the demo app, I've moved it into an admin directory along with the watch script.

To have that run at dev time, we can update our package.json script to run this alongside netlify-cms-proxy-server.

{
  "scripts": {
    "dev": "npx netlify-cms-proxy-server & next dev & node admin/config-watcher.js"
  }
}

That's It!

That's how to get up and running with a "Headless" CMS. In this case, Netlify CMS. It's a neat solution and a great entry point if you've not set up a CMS for yourself before.

I'd recommend setting up a CMS for your sites. Especially your personal portfolio sites. How about trying Netlify CMS? Get set up, have a look around the docs, customize it to your needs!

Want to try it out with Next.js? Check out the demo repository that's set up with Tailwind and use that as a starting point.

As always, thanks for reading. Wanna know more? Wanna see something else? Come find me on Twitter!

Stay awesome! ʕ •ᴥ•ʔ

Creating Directionally Lit 3D Buttons with CSS

Jhey Tompkins — Thu, 18 Mar 2021 19:55:33 +0000

I'm not too sure how I stumbled into this one. But, something led me to this tweet.

// Detect dark theme var iframe = document.getElementById('tweet-1278384065087893505-704'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1278384065087893505&theme=dark" }

And, to me, that's a challenge. I took it to the live stream!

The button design is neat. But, I didn't want to do a direct copy. Instead, we decided on making a "Twitter" button. The idea is that we create an almost transparent button with a social icon on it. And then that social icon casts a shadow below. Moving our mouse across the button shines a light over it. Pressing the button pushes it onto the surface.

// Detect dark theme var iframe = document.getElementById('tweet-1355305224416669701-17'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1355305224416669701&theme=dark" }

And today, we're going to look at how you can make it too. The cool thing is, you can swap the icon out to whatever you want.

The Markup

My first take approach for creating something like this is to scaffold the markup. Upon first inspection, we'll need to duplicate the social icon used. And a neat way to do this is to use Pug and leverage mixins.

mixin icon()
  svg.button__icon(role='img' xmlns='http://www.w3.org/2000/svg' viewbox='0 0 24 24')
    title Twitter icon
    path(d='M23.953 4.57a10 10 0 01-2.825.775 4.958 4.958 0 002.163-2.723c-.951.555-2.005.959-3.127 1.184a4.92 4.92 0 00-8.384 4.482C7.69 8.095 4.067 6.13 1.64 3.162a4.822 4.822 0 00-.666 2.475c0 1.71.87 3.213 2.188 4.096a4.904 4.904 0 01-2.228-.616v.06a4.923 4.923 0 003.946 4.827 4.996 4.996 0 01-2.212.085 4.936 4.936 0 004.604 3.417 9.867 9.867 0 01-6.102 2.105c-.39 0-.779-.023-1.17-.067a13.995 13.995 0 007.557 2.209c9.053 0 13.998-7.496 13.998-13.985 0-.21 0-.42-.015-.63A9.935 9.935 0 0024 4.59z')

Here we’ve created a mixin for rendering an SVG of the Twitter icon. This would render the Twitter icon if we invoke it like so.

+icon()

Doing that will give us a big Twitter icon.

Because social icon sets tend to use the same "0 0 24 24" viewBox, we could make the title and path arguments.

mixin icon(title, path)
  svg.button__icon(role='img' xmlns='http://www.w3.org/2000/svg' viewbox='0 0 24 24')
    title= title
    path(d=path)

Then our Twitter icon becomes

+icon('Twitter Icon', 'M23.953 4.57a10 10 0 01-2.825.775 4.958 4.958 0 002.163-2.723c-.951.555-2.005.959-3.127 1.184a4.92 4.92 0 00-8.384 4.482C7.69 8.095 4.067 6.13 1.64 3.162a4.822 4.822 0 00-.666 2.475c0 1.71.87 3.213 2.188 4.096a4.904 4.904 0 01-2.228-.616v.06a4.923 4.923 0 003.946 4.827 4.996 4.996 0 01-2.212.085 4.936 4.936 0 004.604 3.417 9.867 9.867 0 01-6.102 2.105c-.39 0-.779-.023-1.17-.067a13.995 13.995 0 007.557 2.209c9.053 0 13.998-7.496 13.998-13.985 0-.21 0-.42-.015-.63A9.935 9.935 0 0024 4.59z')

But, we could pass it a key. And then have the paths stored in an object if we have many icons we wanted to use or repeat.

mixin icon(key)
  -
    const PATH_MAP = {
      Twitter: "M23.953 4.57a10 10 0 01-2.825.775 4.958 4.958 0 002.163-2.723c-.951.555-2.005.959-3.127 1.184a4.92 4.92 0 00-8.384 4.482C7.69 8.095 4.067 6.13 1.64 3.162a4.822 4.822 0 00-.666 2.475c0 1.71.87 3.213 2.188 4.096a4.904 4.904 0 01-2.228-.616v.06a4.923 4.923 0 003.946 4.827 4.996 4.996 0 01-2.212.085 4.936 4.936 0 004.604 3.417 9.867 9.867 0 01-6.102 2.105c-.39 0-.779-.023-1.17-.067a13.995 13.995 0 007.557 2.209c9.053 0 13.998-7.496 13.998-13.985 0-.21 0-.42-.015-.63A9.935 9.935 0 0024 4.59z"
    }
  svg.button__icon(role='img' xmlns='http://www.w3.org/2000/svg' viewbox='0 0 24 24')
    title= `${key} Icon`
    path(d=PATH_MAP[key])

+icon('Twitter')

This can be a neat way to create an icon mixin to reuse. It's a little overkill for our example, but worth noting.

Now, we need some markup for our button.

.scene
  button.button
    span.button__shadow
      +icon('Twitter')
    span.button__content
      +icon('Twitter')
      span.button__shine

It's always good to be mindful of accessibility. We can check what our button gives off by checking the "Accessibility" panel in Dev Tools.

Might be a good idea to put a span in for our button text and hide the icons with aria-hidden. We can hide the span text too whilst making it available to screen readers.

.scene
  button.button
    span.button__shadow
      +icon('Twitter')
    span.button__content
      span.button__text Twitter
      +icon('Twitter')
      span.button__shine

We've got different options for applying those aria-hidden attributes. The one we will use is changing the mixin code to apply aria-hidden.

mixin icon(key)
  -
    const PATH_MAP = {
      Twitter: "...path code"
    }
  svg.button__icon(role='img' aria-hidden="true" xmlns='http://www.w3.org/2000/svg' viewbox='0 0 24 24')
    title= `${key} Icon`
    path(d=PATH_MAP[key])

Another neat way with Pug is to pass through all attributes to a mixin. This is useful in scenarios where we only want to pass some attributes through.

mixin icon(key)
  -
    const PATH_MAP = {
      Twitter: "...path code"
    }
  svg.button__icon(role='img' xmlns='http://www.w3.org/2000/svg' viewbox='0 0 24 24')&attributes(attributes)
    title= `${key} Icon`
    path(d=PATH_MAP[key])

If we check the “Accessibility” panel again, our button only reads “Twitter”. And that’s what we want!

The Styles

Here's the part you came for. How we style the thing. To start, we've dropped this in;

* {
  transform-style: preserve-3d;
}

That allows us to create the 3D transforms we need for our button. Try switching that off in the final demo and you'll see that everything breaks.

Let's hide the span text from our eyes. We can do this in many ways. One recommended way to hide an element from our eyes, but not those of the screenreader is to use these styles.

.button__text {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip: rect(0, 0, 0, 0);
  white-space: nowrap;
  border-width: 0;
}

Before we start working on our button, we're going to tilt the scene. We can do this using a transform. Here we chain the transform to get it into the position we want. I spent a bit of time tinkering with values here on live stream to get it close to the original.

.scene {
  height: var(--size);
  position: relative;
  width: var(--size);
  transform: rotateX(-40deg) rotateY(18deg) rotateX(90deg);
}

You’ll notice a size variable there too. We're going to drive certain things for our button with CSS variables. This will make it handy for tinkering with values and the effect. Usually, we would put these under the scope they're required in. But, for demos like this, putting them under the :root at the top of our file makes it easier for us to play with.

:root {
  --blur: 8px;
  --shine-blur: calc(var(--blur) * 4);
  --size: 25vmin;
  --transition: 0.1s;
  --depth: 3vmin;
  --icon-size: 75%;
  --radius: 24%;
  --shine: rgba(255,255,255,0.85);
  --button-bg: rgba(0,0,0,0.025);
  --shadow-bg: rgba(0,0,0,0.115);
  --shadow-icon: rgba(0,0,0,0.35);
  --bg: #e8f4fd;
}

These are the variables, we’re working with and these will make sense as we build up our button.

The Button

Let's move onto the button!

First things first. The actual button element. This is going to fill the scene element. We could have applied the sizing and transforms direct on the button. But, if we were to introduce other buttons and elements, we'd have to transform and size them all. This is something to be mindful of with CSS in general. Try and make your container elements dictate the layout.

.button {
  appearance: none;
  background: none;
  border: 0;
  cursor: pointer;
  height: 100%;
  outline: transparent;
  position: absolute;
  width: 100%;
}

Here we strip the button styles. And that gives us this.

Next we need to create a common start point for the button content and the shadow. We can do this by giving each element absolute positioning. The content will have a 3D translate based on the depth variable we defined before.

.button__content,
.button__shadow {
  border-radius: var(--radius);
  display: grid;
  height: 100%;
  place-items: center;
  position: absolute;
  width: 100%;
}
.button__content {
  transform: translate3d(0, 0, var(--depth));
}

Note how we’re also making use of the --radius variable too.

It's hard to distinguish between the two icons at this stage. And now's a good time to style them. We can apply some basic icon styling and use a scoped fill for each SVG icon.

.button__content {
  --fill: var(--icon-fill);
}
.button__shadow {
  --fill: var(--shadow-fill);
}

.button__icon {
  height: var(--icon-size);
  fill: var(--fill);
  width: var(--icon-size);
}

It’s getting there! The icons aren’t the same size at the moment though. We’ll get to that.

Let’s get the button press in place. This part is real quick to integrate.

.button__content {
  transition: transform var(--transition);
}
.button:active {
  --depth: 0;
}

That’s it! Using scoped CSS variables we’re saying remove the z-axis translation on :active. Adding the transition to the transform stops it from being so instant.

All that's left to do is style the button layers and the shine. Let's start with the shadow.

.button__shadow {
  background: var(--bg-shadow);
  filter: blur(var(--blur));
  transition: filter var(--transition);
}
.button:active {
  --blur: 0;
}

Another scoped style here. We’re saying that when we press the button, the shadow is no longer blurred. And to blur the shadow, we use the CSS filter property with a blur filter. The value of which we defined in our CSS variables. Have a play with the --blur variable and see what happens.

For the content layer, we're going to use a background color and then apply a backdrop filter. Much like filter, backdrop-filter is a way for us to apply visual effects to elements. A common use case currently is using blur for "Glassmorphism".

.button__content {
  backdrop-filter: blur(calc(var(--blur) * 0.25));
  background: var(--button-bg);
  overflow: hidden;
  transition: transform var(--transition), backdrop-filter var(--transition);
}

We use the value of --blur and apply a transition for backdrop-filter. Because of the way we scoped our --blur variable on :active, we get the transition almost for free. Why the overflow: hidden? We’re anticipating that shine element that will move around the button. We don’t want it wandering off outside though.

And now, the last piece of the puzzle. That light shine. This is what has been causing the icons to be a different size. Because it has no styles, it's affecting the layout. Let's give it some styles.

.button__shine {
  --shine-size: calc(var(--size) * 0.5);
  background: var(--shine);
  border-radius: 50%;
  height: var(--shine-size);
  filter: blur(var(--shine-blur)) brightness(1.25);
  position: absolute;
  transform: translate3d(0, 0, 1vmin);
  width: var(--shine-size);
}

That absolute positioning will sort out the icon sizing. Applying a border radius will make the spotlight round. And we use filter again to give the blurry spot light effect. You’ll notice we’ve chained a brightness filter on the end there to brighten things up a bit after they’re blurred.

Using the 3D translation ensures that the shine sits above the button which it would do. This way, there’s no chance of it getting cut by z-fighting with other elements.

That's all we need for the styles for now. Now it's time for some scripts.

Scripts

We're going to use GreenSock today for convenience. They have some neat utilities for what we want. But, we could achieve the same result with vanilla JavaScript. Because we're using scripts with type "module", we can take advantage of SkyPack.

import gsap from 'https://cdn.skypack.dev/gsap'

And now we're ready to start tinkering. We want our button to respond to pointer movement. The first thing we want is to translate the shine as if it follows our pointer. The second is to shift the button dependant on where our pointer is.

Let's grab the elements we need and set up some basic event listeners on the document.

import gsap from 'https://cdn.skypack.dev/gsap'

const BUTTON = document.querySelector('.button')
const CONTENT = document.querySelector('.button__content')
const SHINE = document.querySelector('.button__shine')

const UPDATE = ({x, y}) => console.info({x, y})

document.addEventListener('pointermove', UPDATE)
document.addEventListener('pointerdown', UPDATE)

Try moving your pointer around in this demo to see the valuables we get returned for x and y.

This is the trickiest bit. We need some math to work out the shine position. We're going to translate the shine after it's initial reset. We need to first update the shine styles to accommodate this. We’re using the scoped CSS variables --x and --y. We give them a fallback of -150 so they’ll be out of shot when the demo loads.

.button__shine {
  top: 0;
  left: 0;
  transform: translate3d(-50%, -50%, 1vmin) translate(calc(var(--x, -150) * 1%), calc(var(--y, -150) * 1%));
}

Then, in our update function we calculate the new position for the shine. We're basing this on a percentage of the button size. We can calculate this by subtracting the button position from our pointer position. Then we divide that by the position. To finish, multiply by 200 to get a percentage.

const BOUNDS = CONTENT.getBoundingClientRect()
const POS_X = ((x - BOUNDS.x) / BOUNDS.width) * 200
const POS_Y = ((y - BOUNDS.y) / BOUNDS.height) * 200

For example, POS_X.

Grab pointer position x.
Subtract button position x.
Divide by button width.
Multiply by 200.

We multiply by 200 because the shine is half the size of the button. This particular part is tricky because we’re trying to track the pointer and map it into 3D space.

To apply that to the button, we can set those CSS variables using gsap.set. That’s a GSAP method that works as a zero second tween. It’s particularly useful for setting values on elements.

gsap.set(SHINE, {
  '--x': POS_X,
  '--y': POS_Y
})

But, if we want to take it one step further, we can use a quickSetter from GSAP which would be better for performance in real-world scenarios where we’re making lots of updates.

const xySet = gsap.quickSetter(SHINE, 'css')
// Then to update the values
xySet({
  '--x': POS_X,
  '--y': POS_Y
})

That makes our update function look something like this.

const UPDATE = ({x, y}) => {
  const BOUNDS = CONTENT.getBoundingClientRect()
  const POS_X = ((x - BOUNDS.x) / BOUNDS.width) * 200
  const POS_Y = ((y - BOUNDS.y) / BOUNDS.height) * 200
  xySet({
    '--x': POS_X,
    '--y': POS_Y
  })
}

The accuracy of following the pointer would need more calculations to be precise. Have a play with this demo where the overflow on the button is visible and the shine is more prominent. You can see how the shine element loses it's tracking.

This demo puts everything where it should be.

Last feature. Let’s shift the button for an added touch. Here, we're going to base the shift of the button on pointer position. But, we're going to limit it's movement. To do this, we can use another GSAP utility. We're going to use mapRange. This allows us to map one set of values to another. We can then pass a value in and get a mapped value back out.

First, we’ll define a limit for movement. This will be a percentage of the button size.

const LIMIT = 10

Now in our update function we can calculate the percentage of shift. We do this by mapping the the window width against the limit. And we input our pointer position to get the mapped percentage back.

const xPercent = gsap.utils.mapRange(
  0,
  window.innerWidth,
  -LIMIT,
  LIMIT,
  x
)

In this block we’re mapping the range of 0 to window.innerWidth against -10 to 10. Passing pointer position x will give us a value between -10 and 10. And then we can apply that percentage shift to our button. We do the same for vertical shift and this gives us an update function like the following.

const buttonSet = gsap.quickSetter(BUTTON, 'css')
const xySet = gsap.quickSetter(SHINE, 'css')
const LIMIT = 10

const UPDATE = ({x, y}) => {
  const BOUNDS = CONTENT.getBoundingClientRect()
  const POS_X = ((x - BOUNDS.x) / BOUNDS.width) * 200
  const POS_Y = ((y - BOUNDS.y) / BOUNDS.height) * 200
  xySet({
    '--x': POS_X,
    '--y': POS_Y
  })
  const xPercent = gsap.utils.mapRange(
    0,
    window.innerWidth,
    -LIMIT,
    LIMIT,
    x
  )
  const yPercent = gsap.utils.mapRange(
    0,
    window.innerHeight,
    -LIMIT,
    LIMIT,
    y
  )
  buttonSet({
    xPercent,
    yPercent,
  })
}

That’s it!

That’s how you create a directional lit 3D button with CSS and a little scripting. The cool thing is that we can make changes with relative ease.

For the final demo, I’ve added some extra details and changed the icon. You might recognise it.

As always, thanks for reading. Wanna see more? Come find me on Twitter or check out the live stream!

DEV Community: Jhey Tompkins

Circular Text with CSS?

How you might solve this today

Enter trigonometric functions

Introducing CSS trigonometry

Further reading

How to Make a Pure CSS 3D Package Toggle

Where to start?

Mixins are a good idea

Nesting the sides

Transforming all the things

Folding up

Multi-step transitions!

Maybe we oughta flip the box, too

Unfolding the box

Sizing and centering

Adding in the checkbox hack

Final polish

That’s it!

3D CSS Flippy Snaps with React && GreenSock

That's it!

Parallax Powered by CSS Custom Properties

Making a scene

That’s it!

Print.css but not how you know it – Creating a 3D CSS Printer

Making things 3D with CSS

More Than One Way

Scaffolding a Printer

Adding Some Detail

Paper Journey

Printing

That’s It!

Can We Create a "Resize Hack" With Container Queries?

Can we debunk a classic CSS meme with container queries?

Get Started with React by Building a Whac-A-Mole Game

Aim

First App

JSX

Rendering

Components && Props

Making Changes

Whac-A-Mole React Game

Design

Starting Point

Starting/Stopping

Timer

Scoring

Loops in JSX

Ending Game

Moles

Tracking High Score

Whimsical Touches

That's It!

Where to Go Next!

Going "Meta GSAP": The Quest for "Perfect" Infinite Scrolling

Animate anything

Going “meta”

Achieving the “perfect” loop

Hooking this up to scroll

Time travel for infinite scrolling

Scroll snapping

What next?

That’s it!

Squeaky Portraits: Having Fun with the CSS path() Function

Creating a Path

Applying Splats

Interaction

Adding Some Character

Adding a Portrait.

Parallax Icons

The Squeak

That’s It!

Make a Functional Stopwatch with CSS – Exploring @property and its Animating Powers

First off, we get type checking

Let's Animate Color

Straight-up numbering

Animated gradients

Transforms are cool, too

Powering an entire scene with variables

That’s it!