CSS-Tricks

Computing and Displaying Discounted Prices in CSS

Preethi — Thu, 14 May 2026 14:05:01 +0000

CSS math isn’t just about how things look! It can also be used to work out useful numeric information. For instance, you could calculate and show the percentage of tasks completed in a to-do list with CSS, helping users keep track of their progress. No need for script or server computation. No latency. No use of additional browser resources.

Working with math has become much simpler and more flexible. I’m going to give you an example using CSS to calculate and display a discounted price whenever you need it, using the base price and discount provided. It’s the sort of thing you see often on e-commerce sites where heavy JavaScript is used to show a product’s full price, its discount amount, and its sale price.

Screenshot taken from gap.com

We can absolutely do that in CSS:

CodePen Embed Fallback

It does rely on some bleeding-edge features that are waiting to gain more browser support, but I think it’s still a good exercise to dig into how we will eventually be able to put these things in practice and eventually use them in our everyday work.

Here’s how I put it together.

The initial markup

The interface in this specific demo displays a list of streaming services for the user to choose from — Netflix, Disney+, ~~HBO~~, ~~HBO Now~~, ~~HBO Go~~, HBO Max, etc. There’s a student discount offer on each subscription that takes a certain percentage amount off the full price.


  
  
    Netflix
    
    $7.99
    
    
  

  
  
    Apply Student Discount 
 20%

The base price and discount are included as data-* attributes in the element displaying the price. Just remember, the discount only kicks in when you select “Apply Student Discount,” and then you’ll see how much the price is after the discount is applied.

Calculating the price cut

When the discount kicks in, the first step is to slash the base price with a line across it.

/* When the discount toggle is checked inside the .ott container */
.ott:has(.is-ott-discounted:checked) {
  /* Strike through the original price */
  .ott-price {
    text-decoration: line-through;
  }
}

Next, let’s figure out the new discounted price using the data-price and data-discount values.

.ott:has(.is-ott-discounted:checked) {
  .ott-price {
    text-decoration: line-through;
    /* 
        Calculate the new price from the data-* attributes:
        Original Price * (1 - Discount Applied)
    */
    --n: calc(attr(data-price number) * (1 - attr(data-discount number)));
  }
}

The attr( ) syntax is relatively new. The function used to only work with the content property, but now supports any CSS property… and parses values into a range of data types, whereas before they were always parsed as strings.

Those arguments:

: This is the name of the HTML attribute we want to look at (like href, data-count, or title).
: This tells CSS how to “read” the value (like a color, a number, or a length). It’s the newer superpower that makes the work we’re doing here possible.

In our case, we’re using the function to parse both data-price and data-discount into numbers, and then we subtract the discount from the price with CSS math-iness.

The upgraded attr() is super cool, but not Baseline as I’m writing this, so keep an eye on it.

Showing the discounted price

Here’s how we display the updated price once the discount is applied:

.ott:has(.is-ott-discounted:checked) {
  .ott-price {
    text-decoration: line-through;
    --n: calc(attr(data-price number) * (1 - attr(data-discount number)));

    &::after {
      display: inline-block;
      /* Splits the variable --n into two counters: 
          'a' for the whole number (in dollars) and 'b' for the decimals (in cents) */
      counter-set: a calc(round(down, var(--n))) b calc((mod(var(--n), 1)) * 100);
      /* Output: two spaces (\2000), a dollar sign ($), the number, a dot, and the decimals */
      content: "\2000\2000$" counter(a) "." counter(b, decimal-leading-zero);
    }
  }
}

The counter() function helps us turn the numeric value of the --n varable into a content string. Since CSS counters can’t handle decimals (they round the value by default), we treat the numbers before and after the decimal as separate counters and then combine them as strings, adding a dot between them.

calc(round(down, var(--n))) takes the variable --n and rounds it down to get the whole dollar amount (stored as counter(a)).
calc((mod(var(--n), 1)) * 100) uses the modulo mod() function to isolate the fraction, then multiplies it by 100 to get the cents (stored as counter(b)).
The content property inserts a dollar sign before the two counters and then joins them with a dot.

We know that calc() has plenty of browser support. And guess what? The mod() function is newly Baseline!

That’s only if you need decimals and all that. If you’re rounding prices, this would be plenty enough:

counter-set: price calc(var(--n));
content: counter(price);

Here’s the demo once again:

CodePen Embed Fallback

Wrapping up

So, there we have it, a working combination of newer CSS features (the upgraded attr() function), CSS math functions (mod(), round()), and custom counters to nail down something that we see in so many websites, only without scripts. When attr()‘s support for data types becomes a thing in all browsers, this is something you can use in your everyday work.

Computing and Displaying Discounted Prices in CSS originally handwritten and published with love on CSS-Tricks. You should really get the newsletter as well.

rotateX()

Gabriel Shoyombo — Wed, 13 May 2026 14:36:54 +0000

The CSS rotateX() function rotates an element around the x-axis in a three-dimensional space. Specifically, it vertically flips the element, making it tilt backward or forward, depending on the angle set. It is one of many transform functions used in the transform property.

The x-axis is the axis of rotation, so the element turns vertically. Imagine a pin is stuck to the left side of an element and it can only turn up or down.

In the demo below, rotateX(0) is given as the element’s default rotation:

.demo-element {
  transform: rotateY(var(--deg));
  transition: transform 0.3s ease;
}

CodePen Embed Fallback

The rotateX() function is defined in the CSS Transforms Module Level 2 specification.

Syntax

rotateX() = rotateX( [  |  ] )

Arguments

/* angle in degrees */
rotateX(45deg) /* rotates 45 degrees backwards */
rotateX(-90deg) /* rotates 90 degrees forwards */

/* angle in turns */
rotateX(0.5turn) /* rotates 180 degrees (half a full turn) */
rotateX(1turn)   /* Rotates a full 360-degree turn */

/* angle in radians */
rotateX(1.57rad) /* Approximately 90 degrees */

/* angle in gradians */
rotate(200grad)  /* rotates 180 degrees */

The rotateX() function takes a single argument, which defines how much the element is rotated around its vertical axis.

: values like 45deg, 0.5turn, -90deg, 1.57rad, etc. can be passed.
A positive angle tilts the top of the element toward the back and the bottom toward the front.
While a negative angle does otherwise: it tilts the element’s top towards you, and its bottom away from you.

The type can be one of four units:

deg: One degree is 1/360 of a full circle.
grad: One gradian is 1/400 of a full circle.
rad: A radian is the length of a circle’s diameter around the shape’s arc. One radian is 180deg, or 1/2 of a full circle. One full circle is 2π radians, which is equal to 6.2832rad or 360deg.
turn: One turn is one full circle. So, halfway around a circle is equal to .5turn, or 180deg.

Setting up 3D transforms

rotateX() is part of the CSS 3D transform functions, so it’s better represented in a 3D view. For rotateX() to produce a visible 3D effect, you need to set the perspective property on the parent element. The perspective property determines how the element is projected, adding depth to the element and making it look natural and 3D.

In this demo, we have two sliders to control the rotateX() degree and perspective property.

CodePen Embed Fallback

In the absence of perspective, the element looks oddly skewed and ugly.

It’s also worth setting transform-style to preserve-3d, which determines if that element’s children are positioned in 3D space or flattened.

Basic usage

One of the most popular uses of rotateX() is creating flip cards that reveal content on the back when clicked or hovered. You can use this technique for pricing tables, profile cards, or interactive galleries.

To set the stage and give the card a projection value and 3D presence, we set the perspective and preserve-3d styles on the parent elements.

.flip-card {
  perspective: 1000px;
}

.flip-card-inner {
  transform-style: preserve-3d;
  transition: transform 0.8s cubic-bezier(0.175, 0.885, 0.32, 1.275);
}

Then we position the front and back faces of the card absolutely within the container while setting backface-visibility to hidden:

.flip-card-front,
.flip-card-back {
  position: absolute;
  backface-visibility: hidden;
}

Next, we pre-rotate the back face by 180 degrees, so it is ready to be revealed when the card flips

.flip-card-back {
  transform: rotateX(180deg);
}

And, finally, we flip the card when the parent is :hover-ed:

.flip-card:hover .flip-card-inner {
  transform: rotateX(180deg);
}

CodePen Embed Fallback

Example: 3D Loading spinner

We can also create engaging loading indicators with the rotateX() function..

In this example, we’re not only using the rotateX() function, but we’re combining it with the rotateY() function for a two-axis rotation animation. By continuously rotating an element horizontally and vertically, we create a 3D spinning effect.

Once again, we give the element’s parent a perspective:

.spinner-wrapper {
  perspective: 1000px;
  margin-bottom: 2rem;
}

Then, we apply the animation to the element using the CSS animation shorthand property.

.spinner {
  width: 80px;
  height: 80px;
  animation: spin-3d 2s ease-in-out infinite;
}

Next, we define the keyframe, which dictates how the element rotates from one point to another.

@keyframes spin-3d {
  0% {
    transform: rotateX(0deg) rotateY(0deg);
  }
  25% {
    transform: rotateX(180deg) rotateY(90deg);
  }
  50% {
    transform: rotateX(180deg) rotateY(180deg);
  }
  75% {
    transform: rotateX(360deg) rotateY(270deg);
  }
  100% {
    transform: rotateX(360deg) rotateY(360deg);
  }
}

The order in which the transform functions are defined is important. The effect of the first function comes to life before the second, so at 25% the element flips halfway horizontally before the vertical flip, and the animation is so smooth you hardly notice it.

CodePen Embed Fallback

Example: 3D accordion

Let’s skip the boring accordion component content reveal animation and make ours a bit interesting.

We can enhance traditional accordions by adding a subtle rotateX() rotation when items expand or collapse, creating a more staggered fall effect that further engages the user and improves the experience, rather than the simple slide-down-and-back-up animation.

Once again, as usual, we set the perspective on the parent

.accordion-item {
  perspective: 1000px;
}

Then, we define the transform and transform-origin. Since we want the .accordion-content to fall toward the user, we use a negative 90° angle to shift the element out of the user’s view.

Also, we can change the default rotation axis from the center to the top using transfom-origin: top;

.accordion-content {
  transform-origin: top;
  transform: rotateX(-90deg);
  overflow: hidden;
  transition:
    transform 0.4s ease,
    opacity 0.3s ease,
    max-height 0.4s ease;
}

The transform-origin:top ensures the rotation occurs from the top edge, making it look like a door opening downward, while rotateX(-90deg) makes the content appear to unfold into view.

As the accordion opens, the .accordion-content element falls in a staggered manner to 0 degrees, which is the default position.

.accordion-item.open .accordion-content {
  transform: rotateX(0deg);
  opacity: 1;
  max-height: 500px;
}

CodePen Embed Fallback

A note about `transform-origin` and `rotateX()`

By default, the rotateX() function rotates an element around its center. However, you can change this rotation axis using the CSS transform-origin property. transform-origin lets you change the point of origin of any transform function, so rather than being restricted to center, you can use top center, top right, bottom left, or even percentages and lengths.

.child {
  transform: rotateX(120deg);
  transform-origin: top center;
}

Specification

The CSS rotateX() function is defined in the CSS Transforms Module Level 2 draft.

Browser Support

The rotateX() function has baseline support on all modern browsers.

rotateX() originally handwritten and published with love on CSS-Tricks. You should really get the newsletter as well.

rotateY()

Gabriel Shoyombo — Wed, 13 May 2026 14:33:58 +0000

The CSS rotateY() function rotates an element around its vertical y-axis. Specifically, it horizontally flips an element from left to right (or right to left for that matter). It is one of many transform functions used along with the transform property.

The y-axis is the axis of rotation, so the element turns horizontally. Imagine a pin is stuck to the top of an element and it can only rotate left or right.

.demo-element {
  transform: rotateY(var(--deg));
  transition: transform 0.3s ease;
}

CodePen Embed Fallback

The rotateY() function is defined in the CSS Transforms Module Level 2 specification.

Syntax

rotateY() = rotateY( [  |  ] )

Arguments

/*  in degrees */
rotateY(90deg)   /* Element rotates 90 degrees to the right */
rotateY(-180deg) /* Element rotates 180 degrees to the left */

/*  in turns */
rotateY(0.5turn) /* Element rotates 180 degrees (half a full rotation) */
rotateY(1turn)   /* Element completes a full 360-degree rotation */

/*  in radians */
rotateY(1.57rad) /* Approximately 90 degrees to the right */
rotateY(-3.14rad) /* Approximately 180 degrees to the left */

The rotateY() function takes a single argument, which defines how much the element is rotated around its vertical axis.

: Values like 45deg, 0.5turn, -90deg, 1.57rad, etc. When it is a positive angle, the right edge of the element rotates away from you (the element appears to rotate to the right). When the angle is a negative value, the left edge rotates and the element appears to rotate to the left.

The type has four units to choose from:

deg: One degree is 1/360 of a full circle.
grad: One gradian is 1/400 of a full circle.
rad: A radian is the length of a circle’s diameter around the shape’s arc. One radian is 180deg, or 1/2 of a full circle. One full circle is 2π radians, which is equal to 6.2832rad or 360deg.
turn: One turn is one full circle. So, halfway around a circle is equal to .5turn, or 180deg.

Setting up 3D transforms

We’ve gotta talk about this first because, for any 3D transform function to create a visible 3D effect, you have to set the perspective property on the parent element. perspective defines the projection of the 3D element from the viewer’s eyes.

Lower values (like 400px) make the 3D element appear closer, while higher values (like 2000px) make it appear farther, reducing the visibility of the 3D effect.

.parent {
  perspective: 1000px;
}

.card {
  transform: rotateY(45deg);
}

Without perspective, the rotation will appear flat and shrunken, and the 3D depth won’t be visible.

While with perspective, it looks slightly tilted to the right

It’s also worth setting transform-style to preserve-3d, which determines if that element’s children are positioned in 3D space, or flattened.

CodePen Embed Fallback

Basic usage

One of the most popular uses of rotateY() is creating horizontal flip cards that show content on the back when clicked or hovered. To make one, we first set the 3D stage and projection by applying transform-style to preserve-3d; to the card and perspective to 1000px; styles to the parent elements.

.flip-card {
  perspective: 1000px;
}

.flip-card-inner {
  transform-style: preserve-3d;
  transition: transform 0.8s cubic-bezier(0.175, 0.885, 0.32, 1.275);
}

Next, we position the front and back faces of the card absolutely within the container, while setting backface-visibility to hidden. It prevents the content of each face from showing through when rotated to the other side.

.flip-card-front,
.flip-card-back {
  position: absolute;
  backface-visibility: hidden;
}

We also need to pre-rotate the back face by 180deg. This ensures the back face is readable when flipped and viewed from the front.

.flip-card-back {
  transform: rotateY(180deg);
}

And, finally, we flip the card when the parent is :hover-ed.

.flip-card:hover .flip-card-inner {
  transform: rotateX(180deg);
}

CodePen Embed Fallback

Example: Image carousel

The rotateY() function is also perfect for creating 3D image carousels that showcase products or galleries. Each item can be positioned around a cylinder and rotated to show the viewer.

Once again, as usual, we set up the 3D stage with perspective and preserve-3d.

.carousel {
  perspective: 1200px;
}

.carousel-container {
  transform-style: preserve-3d;
  transition: transform 0.8s cubic-bezier(0.4, 0, 0.2, 1);
}

Afterwards, we try to position all .carousel-item in the center of the .carousel-container using absolute positioning

.carousel-item {
  position: absolute;
  left: 50%;
  top: 50%;
  transform: translate(-50%, -50%);
}

Later, we reposition them to form a cylinder around the .carousel-container using rotateY(calc(var(--n) * 72deg)), which pushes each item forward with translateZ(400px), without which the items would edge into one another.

400px serves as the cylinder’s radius. I tried different radii from 100 to see which one would make each item appear individually, and 400px won.

.carousel-item {
  position: absolute;
  left: 50%;
  top: 50%;
  transform: translate(-50%, -50%) rotateY(calc(var(--n) * 72deg)) translateZ(400px);
}

Each .carousel-item has a variable, --n: x, where x is a number from 0 to 4. Since there are five total items, we found the perfect angle for the rotateY() function by dividing 360deg (a full turn) by 5 to get 72deg

Now we use JavaScript to rotate the .carousel-container by 72deg when the “Next” and “Prev” buttons are clicked. This pushes the next or previous panel to the front, depending on the button you click.

let currentRotation = 0;
const anglePerItem = 72;

function rotateCarousel(direction) {
  currentRotation += direction * anglePerItem;
  carouselContainer.style.transform = `rotateY(${currentRotation}deg)`;
}

nextBtn.addEventListener("click", () => {
  rotateCarousel(1);
});

prevBtn.addEventListener("click", () => {
  rotateCarousel(-1);
});

CodePen Embed Fallback

Example: Page turn

Remember the horizontal flipping card we looked at earlier? We can build off of it to make it look like a book page turn.

We’re going to add the transform-origin property to it. It defines the point on the axis at which the rotation occurs. By default, it’s the center, and that’s what we’ve used so far, but we’re changing it here to left center. The new position allows the element to be flipped from the center of the left edge, as in books, rather than from the main center in the flipping card effect.

.page {
  transform-origin: left center;
  transform-style: preserve-3d;
  transition: transform 1.5s cubic-bezier(0.645, 0.045, 0.355, 1);
}

The rotateY() function, when combined with transform-origin: left center;, can create a realistic page-turning effect for digital books, portfolios, or storytelling interfaces.

You should know how to use rotateY() by now, so let’s skip to the magic. Only the right page is animated, so that’s where the transform is focused. We gave .page a transform-origin of left center; so it rotates on the vertical axis around the center of the left end.

Then, when the .turning class is triggered on clicking the page, rotateY(-180deg) flip it over around the defined rotation point.

.page.turning {
  transform: rotateY(-180deg);
}

To prevent the content of the page’s front and back from showing through, we use backface-visibility: hidden; to hide it when it’s turned over.

.page-front,
.page-back {
  backface-visibility: hidden;
}

Also, we pre-rotate the back page so the content isn’t inverted when it’s turned toward the viewer.

.page-back {
  transform: rotateY(180deg);
}

CodePen Embed Fallback

Specification

The CSS rotateY() function is defined in the CSS Transforms Module Level 2 draft.

Browser support

The rotateY() function is supported on all modern browsers.

rotateY() originally handwritten and published with love on CSS-Tricks. You should really get the newsletter as well.

rotateZ()

Gabriel Shoyombo — Wed, 13 May 2026 14:33:03 +0000

The CSS rotateZ() function rotates an element around its z-axis, so clockwise or counterclockwise. While it produces the same visual effect as the rotate() function, it’s best used in 3D transformations. It is one of many transform functions used along with the transform property.

CodePen Embed Fallback

In the demo, we first set up a stage for our 3D element with perspective. It represents the projection of the 3D element from the viewer’s perspective, indicating how far or close the object appears.

.stage {
  perspective: 800px;
}

We then simulate the tumbling effect of a coin that is spun on a table in slow motion, so we use three 3D rotation transform functions: rotateX(), rotateY(), and rotateZ().

The rotate() shorthand cannot be used here because it maps to a 2D matrix and could lead to wrong calculations in the browser’s matrix math when combined with 3D functions.

.tumbling-coin {
  animation: tumble 3s infinite linear;
}

@keyframes tumble {
  0% {
    transform: rotateX(0deg) rotateY(0deg) rotateZ(0deg);
  }
  100% {
    transform: rotateX(360deg) rotateY(180deg) rotateZ(360deg);
  }
}

The rotateZ() function is defined in the CSS Transforms Module Level 2 specification.

Syntax

 = rotateZ( [  |  ] )

Arguments

/*  in degrees */
rotateZ(90deg)   /* Element rotates 90 degrees clockwise */
rotateZ(-180deg) /* Element rotates 180 degrees counterclockwise */

/*  in turns */
rotateZ(0.25turn) /* Element makes a quater turn clockwise */
rotateZ(1turn) /* Element completes a full 360-degree rotation */

/*  in radians */
rotateZ(1.57rad) /* Approximately 90 degrees clockwise */
rotateZ(-3.14rad) /* Approximately 180 degrees counterclockwise */

The rotateZ() function takes a single argument, which specifies how much to rotate the element around the z-axis

The direction the element spins depends on whether the angle value is positive or negative

A positive angle spins in the clockwise direction, while
A negative angle spins in the counterclockwise direction

The type can be one of four units:

deg: One degree is 1/360 of a full circle.
grad: One gradian is 1/400 of a full circle.
rad: A radian is the length of a circle’s diameter around the shape’s arc. One radian is 180deg, or 1/2 of a full circle. One full circle is 2π radians, which is equal to 6.2832rad or 360deg.
turn: One turn is one full circle. So, halfway around a circle is equal to .5turn, or 180deg.

Basic usage

The rotateZ() and rotate() functions have the same visual effect, but their applications are best suited to 3D and 2D animations, respectively. Also, rotateZ() is a better option for any animation that requires the GPU compositing layer, as it’s hardware-accelerated.

CodePen Embed Fallback

In this demo, rotateZ() is used instead of rotate() though they have the same visual effect. However, if you have a complex animation on a webpage with a lot of heavy DOM elements, rotate() might cause the browser to constantly recalculate the layout on the main thread. By using rotateZ(), you force browser to promote that specific element to its own layer on the computer’s GPU, making the animation smoother and faster.

.gpu-spinner {
  animation: gpu-spin 1s linear infinite;
}

@keyframes gpu-spin {
  from {
    transform: rotateZ(0deg);
  }
  to {
    transform: rotateZ(360deg);
  }
}

Example: Isometric card

When building 3D effects, you have to rotate elements on multiple axes. While combining transform: rotateX(60deg) rotate(-45deg) technically works, using transform: rotateX(60deg) rotateZ(-45deg) is the semantically correct approach.

.isometric-container {
  perspective: 1000px;
}

.isometric-card {
  transition: transform 0.5s ease;
  transform: rotateX(60deg) rotateZ(-45deg);
}

.isometric-card:hover {
  transform: rotateX(0deg) rotateZ(0deg) scale(1.1);
  box-shadow: 0px 10px 20px rgba(0, 0, 0, 0.2);
}

CodePen Embed Fallback

Specification

The rotateZ() function is defined in the CSS Transforms Module Level 2 specification.

Browser support

The rotateZ() function has baseline support on all modern browsers.

rotateZ() originally handwritten and published with love on CSS-Tricks. You should really get the newsletter as well.

rotate()

Gabriel Shoyombo — Wed, 13 May 2026 14:32:47 +0000

The CSS rotate() function spins an element either clockwise or counterclockwise in a 2D plane. It is one of many transform functions used in the transform property.

For example, using rotate() we can rotate the hand around the clock:

.seconds-hand {
  transform: rotate(var(--deg));
  transform-origin: bottom center;
}

CodePen Embed Fallback

For rotating elements tri-dimensionally, consider using rotateX() and rotateY().

The rotate() functions is defined in the CSS Transforms Module Level 1 specification.

Syntax

rotate() = rotate( [  |  ] )

Arguments

/*  */
rotateZ(90deg) /* Rotates 90 degrees clockwise  */
rotateZ(-180deg) /* Rotates 180 degrees counterclockwise */

/*  in turns */
rotateZ(0.25turn) /* Rotates a quater turn clockwise. */
rotateZ(1turn)    /* Rotates a full 360-degree turn. */

/*  in radians */
rotateZ(1.57rad)  /* Rotates ~90 degrees clockwise. */
rotateZ(-3.14rad) /* Rotate ~180 degrees counterclockwise. */

The rotate() function accepts a single argument, which dictates the direction of its spin. A positive argument spins the element clockwise, while a negative argument spins the element counterclockwise.

The type has four units to choose from:

deg: One degree is 1/360 of a full circle.
grad: One gradian is 1/400 of a full circle.
rad: A radian is the length of a circle’s diameter around the shape’s arc. One radian is 180deg, or 1/2 of a full circle. One full circle is 2π radians, which is equal to 6.2832rad or 360deg.
turn: One turn is one full circle. So, halfway around a circle is equal to .5turn, or 180deg.

Also, rotate() spins the element around its center axis. To change the rotation point, we have to pass a specific point to the transform-origin property that’ll serve as the axis of rotation.

Basic usage

The rotate() function is the backbone of some of the basic animations you’ve most likely come across on, like switching from “+” to “x” when an accordion is opened. We can do that by rotating the “+” symbol by 45deg.

So, if we have a button like this:

We can sprinkle a little JavaScript in there to trigger an .active class when the button is clicked, which rotates the icon:

.toggle.active .icon {
  transform: rotate(45deg);
}

CodePen Embed Fallback

Example: Hamburger menu

Have you seen those menus that switch from a hamburger icon to a closing “X” icon when a menu dropdown or sidebar is opened? That’s a rotation, too!

We start with three spans that are styled as horizontal lines:

.bar {
  width: 100%;
  height: 4px;
  background: #333;
  transition: transform 0.3s ease, opacity 0.3s ease;
}

Notice we have a transition in there so that, when the button is clicked and the rotation happens (again, using JavaScript to toggle on an .active class), the spans transform smoothly:

.hamburger.active .top {
  transform: translateY(14px) rotate(45deg);
}

.hamburger.active .middle {
  opacity: 0;
}

.hamburger.active .bottom {
  transform: translateY(-14px) rotate(-45deg);
}

CodePen Embed Fallback

Example: Loading icons

We can also use rotate() for loading indicators. Loading indicators usually spin while a page is, you know, loading. A common example is a semi-circle that spins until the page is done loading.

The .spinner uses the CSS animation shorthand to define an infinite spinning loading indicator, and the @keyframes spin defines a 360deg spin with the rotate() function.

.spinner {
  animation: spin 0.8s linear infinite;
}

@keyframes spin {
  to {
    transform: rotate(360deg);
  }
}

Now the spinner keeps on a’spinning:

CodePen Embed Fallback

Example: Rotating text

Rotating things isn’t always about animation! We can, for example, position something like a “Feature” label next to a blog post and rotate it vertically for an interesting visual effect.

.vertical-header {
  writing-mode: vertical-rl;
  transform: rotate(180deg);
}

CodePen Embed Fallback

Demo

Let’s look at a more complex animation to demonstrate just how neat it is to rotate() things with CSS. If you “Rerun” the demo, you’ll see the photo swing back and forth. You can also drag the photo from left to right to rotate it.

CodePen Embed Fallback

Specification

The CSS rotate() function is defined in the CSS Transforms Module Level 1 specification, which is currently in Editor’s Draft.

Browser support

cursor

Article on Aug 28, 2019

Can you rotate the cursor in CSS?

Chris Coyier

Article on Mar 8, 2023

Creating a Clock with the New CSS sin() and cos() Trigonometry Functions

Mads Stoumann

transform

Article on Mar 30, 2020

How They Fit Together: Transform, Translate, Rotate, Scale, and Offset

Chris Coyier

Article on Mar 2, 2021

How to Animate the Details Element

Chris Coyier

conic gradients custom properties dates gradients

Article on Sep 19, 2022

Making a Real-Time Clock With a Conic Gradient Face

Brecht De Ruyte

animation

Article on Sep 26, 2025

Recreating Gmail’s Google Gemini Animation

John Rhea

Article on Nov 20, 2017

Recreating the Apple Watch Breathe App Animation

Geoff Graham

tables

Article on Jun 1, 2020

Rotated Table Column Headers… Now With Fewer Magic Numbers!

Cappie Pomeroy

rotate() originally handwritten and published with love on CSS-Tricks. You should really get the newsletter as well.

Soon We Can Finally Banish JavaScript to the ShadowRealm

Mat Marquis — Tue, 12 May 2026 13:59:35 +0000

It’s gonna be tough to keep it together on this one. Okay. I got this. I am a professional technical writer. Straight face; all-business. Ahem: if you’ve been following the ongoing work at TC39 (the standards body responsible for maintaining and developing the standards that inform JavaScript) you may have encountered some of their recent work on ShadowRealms— snrk. Sorry! Sorry, I’m good! Just, whew — what a name, “ShadowRealms.” Okay, hang on, let me start at the beginning. Maybe that will help.

It’s exceptionally likely you’ve seen JavaScript described as “single-threaded” at some point — that’s usually pretty high up on the list of JavaScript fundamentals, alongside “case sensitive,” “whitespace insensitive,” and “bad at math.” That is correct, in the strict “computer science” sense, but it still gets my hackles up a little whenever I see it.

I mean, accurate in that JavaScript isn’t multi-threaded, for sure. A script is always executed in a very linear way — top to bottom, left to right, one execution context after another, winding up the call stack and then back down again. It’s just that you eventually come to learn about something like Web Workers, which — not to put too fine a point on this — allow you to execute JavaScript code in another thread. That’s where I think “JavaScript is single-threaded” becomes a less helpful framing, because even though JavaScript isn’t a multi-threaded language, a JavaScript application can make use of multiple threads.

It’s a better framing — and every bit as technically accurate — to say that a JavaScript realm is single-threaded. A realm refers to the environment where code is executed: a browser tab is a realm, and within that realm is the single thread where JavaScript is executed — the main thread. A Web Worker is a realm with a worker thread. JavaScript running in a cross-origin iframe is running in that iframe realm’s main thread. We can’t, for example, offload the execution of a single function to another thread — JavaScript is itself single-threaded, as a language. But a JavaScript application can span multiple realms and make use of multiple execution threads, and each of those realms can communicate with other realms in specific ways.

Each JavaScript realm has its own global environment. In a browser tab, the global object is the Window interface. The same is true in a non-same-origin iframe within that browser tab — the global object is the Window “owned” by that iframe:

These aren’t the same global object:

The outer page and the inner iframe are two separate realms, both single-threaded, each with their own global objects and their own intrinsic objects:

So, as you might expect, any global properties defined in the context of one realm will be unavailable to another:

“Unavailable” — or, depending on how you look at it, unable to interfere with the the global object of another realm. If you’ve been JavaScripting for a while, you know that no matter how meticulous we are about managing scope, the global environment can get pretty messy despite our best efforts. Some of that is on us, sure — a stray variable binding happens to the best of us — but a lot of that clutter is a result of the early design decisions that went into the language itself, like the function declaration in the previous example. When you consider the staggering amount of JavaScript we don’t control that can get piled onto the average project — from frameworks to third-party helper libraries to polyfills to user analytics to advertisements — there’s potential for collisions, to say the least.

Given the global scope pollution that has haunted the language since time immemorial (the 90s), it isn’t hard to imagine the use cases for offloading code to a realm that can act as a sandbox for the execution of JavaScript we don’t want to impact, or be impacted by, whatever is already cluttering up the global scope. We might want to run part of our test suite in a “clean room” where performing the testing can’t potentially interfere with the results of your testing and mock data can’t run afoul of the real thing, or a place to run code we want quarantined away from the realm that contains our JavaScript application itself to prevent third-party libraries that don’t need access to the global environment from cluttering it up, to no benefit.

We can’t do that with realms, as they stand right now — remember, JavaScript is single-threaded in that each realm is single-threaded, and communication between those threads is limited. As undeniable as the use case is, we can’t repurpose an alternate realm to execute code on its single thread of execution, then weave the results of that execution back into the main thread of our primary realm. That’s multi-threaded execution by definition, and not just contrary to the fundamental nature of JavaScript, but, well, let me put it this way: JavaScript allowing multiple threads of execution at the same time mean would problems us new for.

To offload code in this way would require a new kind of realm — one that has its own global and intrinsic objects, but not it’s own thread — a realm where code offloaded to it will still be executed on the main thread of the realm that “owns” that script. A dark reflection of our own realms; a realm the light can never touch, where only fleeting, ephemeral shadows of our banished code can dwell! Imagine a distant peal of thunder, here; maybe also imagine that I’m wearing a cape, maybe I hurl a wine glass to the floor. Y’know, have fun with it. How could you not? I mean, they’re called:

ShadowRealms

The proposed ShadowRealm API introduces a new kind of realm specifically designed for isolation, and only that. A ShadowRealm does not have an execution context of its own — code offloaded to a ShadowRealm will exist in a pseudo-realm with its own global and built-in objects. That code continues to run on the same thread as the code where the ShadowRealm is created; we’re not forced to communicate and share resources back and forth between two separate threads in limited ways. In short, a script is executed the way it would if limited to a single realm, but quarantined away from that outer realm’s intrinsic objects, APIs, global object, and anything our script has done to that global object.

That sounds complicated, but the proposed API would be exceptionally simple in practice:

// Create a ShadowRealm:
const shadow = new ShadowRealm();

function globalFunction() {};

console.log( globalthis.globalFunction );
// Result: function globalFunction()

// Evaluate `globalThis.globalFunction` inside the ShadowRealm:
console.log( shadow.evaluate( 'globalThis.globalFunction' ) );
// Result: undefined

Note: Keep in mind that this code is still theoretical — it doesn’t exist in the ES-262 standard or browsers just yet.

globalFunction is defined on the outer realm’s global object just like we saw earlier, but it isn’t defined on the global object inside of our newly-created ShadowRealm — that ShadowRealm’s global object remains pristine, no matter what we do outside of it. The inverse is true, naturally:

// Create a ShadowRealm:
const shadow = new ShadowRealm();

// Declare a global function inside the ShadowRealm:
shadow.evaluate( 'function globalFunction() {};' );

// It doesn't exist in the outer realm's global object:
console.log( globalthis.globalFunction );
// Result: undefined

// But when we evaluate `globalThis.globalFunction` inside the ShadowRealm:
console.log( shadow.evaluate( 'globalThis.globalFunction' ) );
// Result: function globalFunction()

We’ve declared that function inside the ShadowRealm, and we can call it by way of the variable that references that ShadowRealm object. That function remains quarantined away from the outer global object and that of any other ShadowRealm:

// Create a ShadowRealm:
const firstShadow = new ShadowRealm();
const secondShadow = new ShadowRealm();

// Declare a global function inside the ShadowRealm referenced by `secondShadow`:
secondShadow.evaluate( 'function globalFunction() {};' );

// It doesn't exist in the outer realm's global object:
console.log( globalthis.globalFunction );
// Result: undefined

// It doesn't exist in the global object of the ShadowRealm referencd by `firstShadow`:
console.log( firstShadow.evaluate( 'globalThis.globalFunction' ) );
// Result: undefined

// It only exists within the ShadowRealm referenced by `secondShadow`:
console.log( secondShadow.evaluate( 'globalThis.globalFunction' ) );
// Result: function globalFunction()

“Quarantined” to an extent, that is. ShadowRealms don’t provide a true security boundary in that code running inside a ShadowRealm can still make inferences about code running in other realms. They can be thought of as an integrity boundary, in that code running inside a ShadowRealm can’t directly interfere with another realm — unless we let it, of course. Even though code shunted off into a ShadowRealm can’t interfere with the objects outside of it, we’re still free to use the results of those operations the way we would use the results of that same operation in the host realm:

// Create a ShadowRealm:
const shadow = new ShadowRealm();

// Create a binding that calls a function inside the ShadowRealm:
const shadowFunction = shadow.evaluate( '( value ) => globalThis.someValue = value );

// ...and call our wrapped function using that binding:
shadowFunction( "Hello from the ShadowRealm!" );

// Executing this function in the host realm doesn't _change_ anything here, of course:
console.log( globalThis.someValue );
// Result: undefined

// But we can grab the result from the ShadowRealm:
const shadowValue = shadow.evaluate( 'globalThis.someValue' );

// And use it here in the host realm:
console.log( shadowValue );
// Result: Hello from the ShadowRealm!

Infinite disposable cleanrooms! Pocket dimensions where we can execute whatever code we want, without fear of that code interfering with the scope of any other ShadowRealm or the outer realm — the “light realm,” if you will.

Now, some of you — especially those of you who’ve been doing this since the early days of JavaScript — have probably been recoiling at these examples. You’d be forgiven for thinking that ShadowRealm API is just goth eval, and you wouldn’t be strictly wrong: apart from running in the context of a ShadowRealm, what you’ve seen so far here are basically indirect calls to eval — even subject to the same unsafe-eval Content Security Policy rule.

Fear not for your workflows, however: while these are illustrative examples, this isn’t the only way to put ShadowRealms to use. The proposal includes an importValue method on the ShadowRealm object’s prototype, which allows you to dynamically import modules, then capture and work with exported values and functions:

// spookycode.js
export function greeting() {
 return "Hello from the ShadowRealm!";
}

async function shadowGreeter() {
  // I INVOKE THE DARK POWER OF THE SHADOWREALM- ahem. Sorry.
  const shadow = new ShadowRealm();

  /* 
  * `importValue` returns a promise that resolves with the value of the function 
  * specified in the second argument: 
  */
  const shadowGreet = await shadow.importValue( "./spookycode.js", "greeting" );

  // Call our wrapped function, annnnd...
  shadowGreet();
}

shadowGreeter();
// Result: Hello from the ShadowRealm!

The shadow hasn’t fallen yet

I’m pleased to say that you’ve now seen the entirety of the proposed ShadowRealms API, at this point. The proposal includes only those the two methods you’ve seen here — evaluate and importValue — both means of ~~banishing~~ evaluating code in the context of a ShadowRealm instance while still executing that code in the context of the host realm’s thread.

Again, though: none of this can be put to use just yet. The proposed specification is currently at Stage 2.7 — “approved in principle and undergoing validation,” meaning that it’s only likely to change as a result of feedback from tests and trial implementations in browsers, if at all. You’re playing a move ahead by reading this. When this proposal reaches Stage 3 and we start to see implementations in browsers, you’ll be ready to try it out for yourself. Nay, more than ready — at such time as the awesome power of the ShadowRealm is loosed upon the web, you shall stand at the ready to command its dark and fearsome majjycks! The very realm upon which our code stands shall quake, as— okay, okay, sorry. Look, I can’t help it! I mean, “ShadowRealm,” for cryin’ out loud.

Soon We Can Finally Banish JavaScript to the ShadowRealm originally handwritten and published with love on CSS-Tricks. You should really get the newsletter as well.

Using CSS corner-shape For Folded Corners

Daniel Schwarz — Fri, 08 May 2026 13:54:10 +0000

I came across Kitty Giraudel’s folded corners technique. It leverages CSS clip-path, and I thought that that was such a cool way to do it. clip-path has been trending lately, most likely because web browsers support the shape() function now.

However, I’ve been on a bit of a corner-shape kick lately (have a look at my introduction to corner-shape as well as these scroll-driven corner-shape animations), so I figured that corner-shape could be used to create folded corners as well, and this is what I came up with:

CodePen Embed Fallback

So open Chrome, which supports corner-shape, and let’s dig in (if you’re looking at this in other browsers, it basically falls back to a rounded corner).

Step 1: Set some CSS variables

Elements have four corners, but when we use border-radius, each corner is split into two coordinates. The x-axis coordinate moves along the x-axis, away from its associated corner, while the y-axis coordinate does the same thing along the y-axis. It’s from these coordinates that border-radius draws the curvature of the rounded corners.

First, store the coordinates as CSS variables. We’ll need the values that they hold more than once, so this simplifies things, makes the fold animatable, and maintains some degree of realism.

:root {
  /* x-axis coordinate */
  --x-coord: 9rem;

  /* y-axis coordinate */
  --y-coord: 5rem;
}

Step 2: Establishing the fold

Given what we now know about border-radius, it should be obvious what border-top-right-radius does. As for corner-top-right-shape: bevel, that ensures that a straight line is drawn between the coordinates instead of rounded corners (corner-top-right-shape: round). That’s right, border-radius includes corner-shape: round by default (behind the scenes, of course).

/* Square */
div {
  /* Place coordinates */
  border-top-right-radius: var(--x-coord) var(--y-coord);

  /* Draw line between coordinates */
  corner-top-right-shape: bevel;
}

CodePen Embed Fallback

Step 3: Creating the flip side

Now that we’ve established the fold, it’s time to create the flip side. Start by selecting ::before, then declare content: "" to create the element without content. The background can be inherited from the square, and the dimensions should leverage the coordinates that we saved. As you can see, I’ve also added a box-shadow where the blur radius scales with --x-coord and --y-coord, but you’re welcome to adapt the formula as you see fit.

/* Square */
div {
  /* Place coordinates */
  border-top-right-radius: var(--x-coord) var(--y-coord);

  /* Draw line between coordinates */
  corner-top-right-shape: bevel;

  /* Flip side */
  &::before {
    /* Generate empty element */
    content: "";

    /* Inherit background */
    background: inherit;

    /* Same as coordinates */
    width: var(--x-coord);
    height: var(--y-coord);

    /* Scale blur radius with --x-coord and --y-coord */
    box-shadow: 0 0 calc((var(--x-coord) + var(--y-coord)) / 3) #00000050;
  }
}

CodePen Embed Fallback

Step 4: Positioning the flip side (`::before`)

Next, we need to shift ::before to the (top-)right corner. We’re avoiding anchor positioning, because there’s no need for modern features if more supported features work well using the same amount of code. So, declare position: relative on the square and position: absolute on ::before. This makes ::before position relative to the square, and is a trick that only works for parent-child relationships. Actually, this shortcoming is why anchor positioning was invented, but we just don’t need it in this case.

In addition, declare inset: 0 0 auto auto on ::before to align it to the top-right corner of the square, and overflow: clip on the square to clip the half of ::before that overflows it.

/* Square */
div {
  /* Place coordinates */
  border-top-right-radius: var(--x-coord) var(--y-coord);

  /* Draw line between coordinates */
  corner-top-right-shape: bevel;

  /* Clip any overflow */
  overflow: clip;

  /* For alignment */
  position: relative;

  /* Flip side */
  &::before {
    /* Generate empty element */
    content: "";

    /* Inherit background */
    background: inherit;

    /* Same as coordinates */
    width: var(--x-coord);
    height: var(--y-coord);

    /* Scale blur radius with --x-coord and --y-coord */
    box-shadow: 0 0 calc((var(--x-coord) + var(--y-coord)) / 3) #00000050;

    /* For alignment */
    position: absolute;

    /* Align to top-right */
    inset: 0 0 auto auto;
  }
}

CodePen Embed Fallback

You can stop here if you want, but there’s room for improvement…

Step 5: Sculpting the flip side

To make the outcome look a bit more realistic, we’ll use corner-bottom-left-shape: bevel to make one more straight cut, this time to ::before. There are, most likely, many ways to tackle this depending on how sharply we want to crease the fold, how elevated we want the flip side to be, and the angle from which we want to view the square, but I don’t think it matters as long as the effect looks decent, so we’re aiming for a sharp crease, the flip side sticking up, and an aerial view. If you’d rather something different, keep in mind that the shadow also impacts the outcome, and that you’d be facing a trickier implementation.

The only degree of complexity that I suggest is this:

/* Ensure realistic fold */
@container style(--x-coord < --y-coord) {
  border-bottom-left-radius: 100% calc(100% - var(--x-coord));
}

@container style(--x-coord >= --y-coord) {
  border-bottom-left-radius: calc(100% - var(--y-coord)) 100%;
}

These are container style queries using the range syntax, where if the value of --x-coord is less than the value of --y-coord, we subtract the value of --x-coord from 100% and use it as the y-axis coordinate for the relevant border radius (border-bottom-left-radius, in this case). The other axis is set to 100%. Adversely, if the value of --x-coord is more than (or equal to) the value of --y-coord, we subtract the value of --y-coord from 100% and use it as the x-axis coordinate. Once again, the other axis is set to 100%.

The result is that the crease, shadow, and now perspective of the fold is calculated using only --x-coord and --y-coord to look realistic (or realistic enough, anyway). Using the slideVars toggles in the top-right corner of the demo, you can see for yourself by testing various combinations of coordinates:

CodePen Embed Fallback

If you want to implement a failsafe to ensure that the coordinates don’t exceed the dimensions of the square, breaking the effect, you can use min(). The modified coordinate variables below set --y-coord to an impossible 999999999rem, but caps it at the height of the square (although I can’t imagine that you’d actually need this, to be completely honest):

--x-coord: min(--square-width, 9rem);
--y-coord: min(--square-height, 999999999rem);

CodePen Embed Fallback

All in all, we have not only a folded corner effect but a utility that builds the effect based on only two coordinates.

The full code:

:root {
  /* x-axis coordinate */
  --x-coord: 9rem;

  /* y-axis coordinate */
  --y-coord: 5rem;

  /* Square */
  div {
    /* Place coordinates */
    border-top-right-radius: var(--x-coord) var(--y-coord);

    /* Draw line between coordinates */
    corner-top-right-shape: bevel;

    /* Clip any overflow */
    overflow: clip;

    /* For alignment */
    position: relative;

    /* Flip side */
    &::before {
      /* Generate empty element */
      content: "";

      /* Inherit background */
      background: inherit;

      /* Same as coordinates */
      width: var(--x-coord);
      height: var(--y-coord);

      /* Scale blur radius with --x-coord and --y-coord */
      box-shadow: 0 0 calc((var(--x-coord) + var(--y-coord)) / 3) #00000050;

      /* For alignment */
      position: absolute;

      /* Align to top-right */
      inset: 0 0 auto auto;

      /* Draw line between coordinates */
      corner-bottom-left-shape: bevel;

      /* Ensure realistic fold */
      @container style(--x-coord < --y-coord) {
        border-bottom-left-radius: 100% calc(100% - var(--x-coord));
      }

      @container style(--x-coord >= --y-coord) {
        border-bottom-left-radius: calc(100% - var(--y-coord)) 100%;
      }
    }
  }
}

Note: We could swap container style queries for if() functions, which are shorter but less readable.

Folded corners using `clip-path` vs. `corner-shape`

Kitty’s Giraudel’s folded corners work in all browsers, and because clip-path is used, which is a more versatile shaping feature, there are more ways to customize the shape. It’s also the more correct approach, for whatever that’s worth. However, my corner-shape approach is cleaner and likely wouldn’t require any further customization anyway, but lacks Safari and Firefox support for now. So unless you need folded corners today, I’d bookmark both:

Using CSS corner-shape For Folded Corners originally handwritten and published with love on CSS-Tricks. You should really get the newsletter as well.

A Scrollytelling Gift for Mum on Mother’s Day 2026

Lee Meyer — Thu, 07 May 2026 14:22:38 +0000

My mum loved logic because she was born at a time when nothing made sense. She was born in 1945, the year World War II ended, so she dodged a literal bullet because we are Jewish. But from the first day of her life, she found that famine, racism, and misfortune kept trying to take her away. In 2011, cancer took her away from me forever. But on a lighter note, this Mother’s Day I’m bringing her back to life the only way I know how: UI mad science!

I will explain how my mum inspired this 2026 Mother’s Day scrollytelling experiment — but also, how she inspired my approach to dev and life. Along the way, I’ll discuss some of the tech involved in this virtual Mother’s Day gift. I normally write either inspirational or technical posts — but for Mother’s Day, you’re getting a twofer.

Try the interactive Mother’s Day card

Here’s the CodePen, which uses scroll-snap events and scroll-state queries, so it will only work in Chromium-based browsers at the moment.

CodePen Embed Fallback

Alternatively, here’s a video demo with commentary by my eight-year-old. It was bittersweet to realise that this is the closest he has come to interacting with his nana, because she passed before he was born.

Why I made this

Mum was born in a hospital in Kazakhstan, where civilian patients shared wards with discharged soldiers suffering PTSD. They wandered in and out of the maternity rooms, terrifying the patients and making labour even harder for my grandmother.

When Mum was born, she wasn’t breathing. The staff immersed her in cold water, then hot, then cold water again — a so-called remedy at the time based on no science. This was the beginning of a larger pattern in her life: She kept surviving not because of the help she received, but despite chaos disguised as help.

So, as an adult, Mum learned to survive by finding patterns and sense in the unfathomable. She accomplished this by combining her three passions:

In photography, she framed moments when the chaos of her surroundings temporarily harmonized into beauty.
In teaching, she used those images to help tell a story that broke the chaos into logical steps people could follow.
In computer programming, she encapsulated those illustrated teachable moments within interactive experiences. Unlike in real life, if a programmed interaction goes wrong, you can trace why and solve the problem.

In other words, she educated me by using the skill set I now think of as web development—before the web existed.

Gamifying the experience of knowing my mum

I drew inspiration from Roland Franke’s deconstructed radial slice transition using scroll-snap events. Roland’s Pen showcases eye-catching, scroll-triggered transitions between landscapes as a figure sits in the foreground watching. This made me think of the patience my mum put into observing the world—but then she’d encapsulate everything in short, interactive stories I could digest as a young child.

I’m symbolizing that experience in my Mother’s Day game with the scroll-triggered time-lapse animation of day to night, stylized with CSS shapes. Using a single scroll gesture, we grasp the gist of an entire day. That experience is like the way my mum could explain a big topic to me in a way that felt like play.

My mum taught me that video games don’t have to be about blowing things up. She once used QuickBASIC to build a photography game long before Pokémon Snap existed. I remember passing a shop in the 90s with Armor Alley playing in demo mode in the window. I was obviously fascinated, but my mum said, “I don’t like it. The helicopter started it,” then she went home and built her photography game for me to play instead.

She once told me a story about photography from her childhood in the Soviet Union. She remembered taking a photo of a government building just because it looked cool, but a soldier saw her and confiscated the roll of film from her camera. Maybe the lesson was that exposing the reality of something can be just as much of a threat as shooting things in the militaristic sense of the word.

The violence common in games is a metaphor for the uncertainty and randomness we face in life, but my mum’s photography game taught me that violence isn’t the only way of coping with that problem, even in a game.

How the scrollytelling Mother’s Day card works

My mum inspired the randomness of the UFOs in this experiment with her ability to use a camera to capture the fleeting moments of sense in a chaotic world.

The combination of deterministic scroll-triggered animations with the randomness of the UFOs and text physics is possible using alien technology I’ve not seen used much in the wild: scroll-snap events. This emergent module — available only in Chrome and Opera at the time of writing — provides a simple JavaScript API so that when we style the page to snap between the day and night scenes, we can trigger behavior that isn’t possible in CSS alone, like the random flight paths of the UFOs, and the Pretext-inspired effect of the UFOs repelling letters as the spaceships fly through the text.

Sidenote: Randomness in CSS is coming, but it only works in Safari for now.

Here’s the CSS to enable scroll snapping:

/* The scroll container */
body {
  overflow-y: auto;
  scroll-snap-type: y mandatory;
}

/* Each snap target */
.snap-panel {
  scroll-snap-align: start;
  scroll-snap-stop: always;
}

…and the JavaScript to handle scroll snap events:

// scrollsnapchanging fires while the user is scrolling —
// snapTargetBlock is the panel they are heading toward.
snapScroller.addEventListener('scrollsnapchanging', ({ snapTargetBlock }) => {
  markPanelStates({ active: selectedPanel, incoming: snapTargetBlock });
  if (snapTargetBlock === dayPanel)   onScrollingTowardDay();
  if (snapTargetBlock === nightPanel) onScrollingTowardNight();
});

// scrollsnapchange fires once a panel has snapped into place —
// snapTargetBlock is the panel now fully in view.
snapScroller.addEventListener('scrollsnapchange', ({ snapTargetBlock }) => {
  selectedPanel = snapTargetBlock;
  markPanelStates({ active: selectedPanel, incoming: null });
  if (snapTargetBlock === dayPanel)   onLandedOnDay();
  if (snapTargetBlock === nightPanel) onLandedOnNight();
});

You can see that handling these events lets us create context-aware transitions between the two scenes, depending on the state of the game logic when the user slides between day and night and back again. My mum would always give me another chance to get things right.

In case you found this while Googling for a conventional Mother’s Day gift idea…

Parting words: In the unlikely event that your mum is not into avant-garde homemade virtual gifts that showcase emergent browser features, get her a Kindle or something. I bought my mum a Kindle when she was alive. We’d read the same novel separately on our Kindles, then we’d compare notes over the phone on the days I couldn’t visit.

Happy Mother’s Day, everyone!

A Scrollytelling Gift for Mum on Mother’s Day 2026 originally handwritten and published with love on CSS-Tricks. You should really get the newsletter as well.

Google’s Prompt API

Geoff Graham — Wed, 06 May 2026 19:41:29 +0000

Mat Marquis on Google pulling the web standards equivalent of U2 album marketing:

As a Chrome user, you’ll have received Gemini Nano in the form of a 4GB transfer recently; no permission asked or required. If you remove it, Chrome will re-download it. For reasons I can only guess at, Gemini Nano is presumably now considered to be part of Chrome itself, despite being a standalone product that is included alongside but not integrated into the browser — the way a copy of Bonzi Buddy included in a browser update might be considered a part of said browser.

It’s not exactly new news, as we’ve had published explainers on it for over a year now, as well as an intent to prototype for just as long.

Mozilla has already voiced its concerns/opposition:

According to Chrome’s documentation, to use the prompt API you must ‘acknowledge’ Google’s Generative AI Prohibited Uses Policy. Elements of this policy go beyond law. For example:

Do not engage … generating or distributing content that facilitates … Sexually explicit content
Do not engage in misinformation, misrepresentation, or misleading activities. This includes … Facilitating misleading claims related to governmental or democratic processes

This seems like a bad direction for an API on the web platform, and sets a worrying precedent for more APIs that have UA-specific rules around usage.

I have nothing to add, only that this is the sort of thing that seems worth knowing. Mat’s take-home isn’t exactly comforting because, remember, this has already shipped:

I’d like to say that something to the tune of “their whole argument hinges on ‘positive developer sentiment,’ so let’s show them that there isn’t any” — but there isn’t any; they cited places where there isn’t any. That’s not how it works for them. Google participates in the web standards process the way a bear participates in the “camping” process.

[…]

Remember this the next time Google announces an “exciting new standard” that they’re heroically championing — for you, for users, for good of the web — in language that has just a hint of inevitability about it.

The browser ecosystem has historically provided us with plenty of concerns. Alex Russell’s writing is a treasure trove of the current limits of browser choice. And things are especially murky when we need to be reminded that not all browser APIs are Web APIs.

Maybe helpful, maybe not:

More coverage, if you’d like:

“Use Gemini in Chrome” (Gemini Apps Help)
“Chrome downloads a 4GB AI file without user consent, researcher alleges” (Engadget)
“Guy finds Google Chrome is quietly installing a 4GB AI model on our devices” (Cybernews)
“Is Chrome’s 4GB “weights.bin” file spyware?” (Android Authority)

Google’s Prompt API originally handwritten and published with love on CSS-Tricks. You should really get the newsletter as well.

Making Zigzag CSS Layouts With a Grid + Transform Trick

Durgesh Rajubhai Pawar — Wed, 06 May 2026 13:50:44 +0000

Most grid layouts sit in neat rows, perfectly aligned, like soldiers in formation. But sometimes you want something with more rhythm — a layout where items cascade diagonally, like water flowing down a waterfall.

This is the zigzag layout. And building it requires a small trick that reveals something fascinating about how CSS transforms actually work.

CodePen Embed Fallback

The Strategy

Before writing a single line of CSS, let’s think about approach.

The first idea that comes to mind: set up a flex container with flex-direction: column and flex-wrap: wrap, so items flow down and then wrap into a second column. Usually we think of the flex-wrap property in terms of rows, but the nice thing about flexbox is that it works in either orientation.

Two problems make this approach awkward:

You need a fixed height. You have to tell the container “you are 500px tall” for wrapping to kick in. That’s brittle.
The tab order breaks. Items flow down the first column (i.e., 1, 2, 3), then jump to the second column (i.e., 4, 5, 6). That’s not a waterfall. That’s two buckets.

To be fair, the CSS Grid approach we’re about to build has its own hardcoded value. We’ll get to that. But it sidesteps the Tab order problem entirely, and that’s a meaningful win.

The Grid Plan

Here’s what I want to do instead:

Create a two-column grid with items sitting side by side, nothing fancy.
Select every item in the second column, the even ones.
Shift them down by half of their own height to establish the staggered layout.

That shift is where the magic happens. Let’s build it.

The Grid

We start with a wrapper and five items. Nothing in the file yet, just a blank slate.

*,
*::before,
*::after {
  box-sizing: border-box;
}

.wrapper {
  display: grid;
  grid-template-columns: 1fr 1fr;
  gap: 16px;
  max-width: 800px;
  margin: 0 auto;
}

.item {
  height: 100px;
  border: 2px solid;
}

We’re applying box-sizing: border-box globally because without it, the items aren’t actually 100px tall — they’re slightly taller once the border gets added. This will matter in a moment.

CodePen Embed Fallback

The Shift

Now the fun part. Let’s grab every even item and translate it down:

.item:nth-child(even of .item) {
  transform: translateY(50%);
}

A quick note on the selector. You might reach for .item:nth-of-type(even) here, and in this demo it would produce the same result since all the children are the same element type. But nth-of-type selects by tag name, not by class. So if you ever mix different element types inside the wrapper, it’ll match in ways you don’t expect. :nth-child(even of .item) is more precise because it explicitly filters by class, and it’s well-supported in modern browsers.

The zigzag emerges immediately. But let’s pause here, because something subtle is happening and it’s worth understanding.

CodePen Embed Fallback

Transform Percentages Are Different

Percentages in transforms work completely differently than they do anywhere else in CSS.

In flow layout, positioned layout, or really any layout mode, a percentage refers to the parent’s available space. If you write width: 50% on an element inside a wrapper, you’re saying: The container is this wide. Make me half of that.

Transforms don’t work this way. In a transform, percentages refer to the element itself. So translateY(50%) doesn’t mean “move down by half of the available space.” It means “move down by half of your own height.” If the element is 200px tall, it moves down by 100px.

This is actually the same coordinate-system behavior you see with the individual translate(), scale(), and rotate() CSS properties. All of them are applied in the element’s own coordinate space, post-layout. The browser finishes laying everything out first, including positions, sizes — basically the whole box model — and then applies the transform relative to the element itself. That’s why scale(2) grows outward from the element’s center, not from the top-left of the page.

This is exactly why the trick works. Each even item shifts down relative to its own size, not the container’s. The zigzag stays proportional no matter how tall the items are.

The result looks close. But it’s not quite right.

The Gap Problem

We can expose the imperfection by cranking the gap up to something absurd — say, 100px. When we do, the even items clearly aren’t sitting where they should. They need to travel a little further to account for the vertical space between rows.

Here’s the fix. First, let’s store the gap in a CSS custom property so we can reference it in multiple places:

.wrapper {
  --gap: 16px;

  display: grid;
  grid-template-columns: 1fr 1fr;
  gap: var(--gap);
  max-width: 800px;
  margin: 0 auto;
}

.item:nth-child(even of .item) {
  transform: translateY(calc(50% + var(--gap) / 2));
}

We translate by 50% of the element’s height plus half of the gap. We divide the gap by 2 because we only need to cover half the distance between rows — the full value would push it too far.

Set the gap to 16px, it looks great. Set it to 100px, it still looks great. The math holds regardless of the value.

CodePen Embed Fallback

The Overflow Surprise

We’ve solved the core puzzle. But there’s a hidden problem waiting to surface.

Let’s add a border to the wrapper to see its boundaries:

.wrapper {
  border: 2px solid red;
}

With five items, everything looks fine. The wrapper contains all of its children. No overflow. No issues.

Now add a sixth item:

The sixth item is even. It gets translated down. And it spills right out of the container.

CodePen Embed Fallback

Why? Because transforms don’t affect layout. As far as the browser’s layout engine is concerned, that sixth item is still sitting in its original, untranslated position. The wrapper sizes itself based on that original position. The transform shifts pixels visually, but the parent has no idea anything moved.

We surprised the browser.

The Fix: Reserve the Space

The simplest solution is to add padding-bottom (or padding-block-end) to the wrapper, enough to accommodate the overshoot. The padding needs to match the translation: half the item height plus half the gap.

Since padding percentages reference the parent’s width (not the child’s height), we can’t use the same 50% trick here. Instead, we store the item height as a variable:

.wrapper {
  --gap: 16px;
  --item-height: 100px;
  
  display: grid;
  grid-template-columns: 1fr 1fr;
  gap: var(--gap);
  margin: 0 auto;
  max-width: 800px;
  padding-bottom: calc(var(--item-height) / 2 + var(--gap) / 2);
}

.item {
  border: 2px solid;
  height: var(--item-height);
}

Now, I’ll be up front: --item-height: 100px is a hard-coded value. That’s the same kind of brittleness I flagged in the flexbox approach, where you need a fixed container height for wrapping to work. Both approaches ask you to know a dimension ahead of time. The difference here is that you’re locking down the item height rather than the container height, and the rest of the layout — column structure, gap math, source order — stays flexible. It’s a trade-off, not a deal-breaker, but it’s worth being honest about.

The wrapper now reserves exactly enough space at the bottom. No overflow. No surprises.

A Note on Accessibility

This approach keeps items in their natural source order, and that matters more than it might seem at first glance.

Screen readers are unaffected. Transforms are purely visual. The DOM order stays 1-6, and that’s exactly how assistive technology will announce them. No reordering surprises, unlike the flexbox column-wrap approach where the visual order and DOM order can diverge.

Focus order stays intact, too. When someone tabs through the items, focus follows the source order, not where the items appear visually. In our zigzag, the visual flow and source order both cascade left-right, top-down, so they naturally agree. If your layout ever gets complex enough that visual and source order start to diverge, that’s when you’d need to think more carefully about focus management.

Respect motion preferences. The zigzag itself is static — we’re not animating the transform. But if you ever decide to animate items into their staggered positions (say, on page load), wrap that animation in a prefers-reduced-motion check:

/* animates when user has no motion preference */
@media (prefers-reduced-motion: no-preference) {
  .item {
    animation: slide-in 0.3s ease-out both;
  }
}

In this case, we’ve set it up so that users who have no preference on motion are the only ones who get the animation. Typically, though, you might do the inverse of that. The layout still works either way.

The Final Demo

Once again:

CodePen Embed Fallback

Conclusion

The zigzag layout is really just three ideas stacked on top of each other:

A two-column grid gives us the foundation.
translateY(50%) creates the stagger and works because transform percentages reference the element itself, not the parent.
padding-bottom reserves space for the translated items because transforms move pixels without telling the layout engine.

Change the gap. Change the item height. Add more items. The zigzag holds.

Making Zigzag CSS Layouts With a Grid + Transform Trick originally handwritten and published with love on CSS-Tricks. You should really get the newsletter as well.

Fixed-Height Cards: More Fragile Than They Look

Kevine Nzapdi — Mon, 04 May 2026 14:01:36 +0000

Fixed-height cards often feel like a safe choice. A designer hands you a mockup where every card aligns perfectly in a grid. The titles are short, the excerpts fit neatly, and the layout looks stable across the entire page. So you implement the design exactly as specified and ship it.

Everything works until the content changes. An editor updates the copy, a translation adds longer words, and some users bump their default font size, especially those with low vision or digital eye strain, just to make things easier to read.

I ran into this while building a “Recent Articles” section for a blog. The design assumed relatively short English titles, so everything fit comfortably inside the fixed height.

The layout looked solid at first glance:

Initial design

But once the content changed, the cracks started appearing:

Translating the content to French made things worse:

Language issues

German translations pushed the layout even further:

More layout failures

What once looked like a stable component turned out to depend on a fragile assumption: that the content would always stay within a fixed height.

Here’s a demo of the layout:

CodePen Embed Fallback

Fixed-Height Layouts Look Fragile

In the design specifications, the pixel dimensions were exact, and you know that cards align more cleanly when they have the same vertical rhythm and equal size, which creates in our mind a sense of order that I and the designer kind of trusted.

So, I set:

.card__title {
  margin: 0 0 8px;
  font-size: 18px;
  line-height: 1.2;
  display: -webkit-box;
  -webkit-line-clamp: 2;
  -webkit-box-orient: vertical;
  overflow: hidden;
}

.card__excerpt {
  margin: 0 0 10px;
  font-size: 14px;
  line-height: 1.4;
  display: -webkit-box;
  -webkit-line-clamp: 3;
  -webkit-box-orient: vertical;
  overflow: hidden;
}

But surprisingly, the behavior changed as soon as the font settings changed. I increased the browser’s default text size and realized that it introduced pressure inside the cards. My text blocks grew, but the container remained the same, and elements began competing for the same space.

Normally, a block element simply grows with its content. But the moment I set that height, I broke that relationship. The browser doesn’t treat this as a problem; it just resolves the conflict the only way it can, by either letting content overflow or clipping it.

In the original version of the layout, I just bluntly hid those problems with overflow: hidden.

To make the problem visible, we can remove the safety net:

.card__title {
  display: -webkit-box;
  font-size: 18px;
  line-height: 1.2;
  margin: 0 0 8px;
  -webkit-line-clamp: 2;
  -webkit-box-orient: vertical;
  /* overflow: hidden; */
}

.card__excerpt {
  display: -webkit-box;
  font-size: 14px;
  line-height: 1.4;
  margin: 0 0 10px;
  -webkit-line-clamp: 3;
  -webkit-box-orient: vertical;
}

Without overflow: hidden, the failure is no longer subtle. The content stops clipping and starts spilling out like groceries from a torn bag. Some excerpts sit right on the tags, and everything was breaking once we stopped hiding the pressure inside the card.

Removing overflow: hidden reveals the structural tension instead of masking it.

Unfortunately, the browser has no way to reconcile those competing instructions except by letting elements collide.

Removing the Fixed Height

Removing the constraints that held this layout together reveals where the real problem lives. Fixed heights, absolute positioning, and grid alignment were all trying to control the same thing.

Absolutely Positioned Actions: Removed From Flow

Up to this point, the fixed height looks like the main culprit to me. But it isn’t acting alone; the actions at the bottom of the card were absolutely positioned:

.card__actions {
  position: absolute;
  inset: 0 14px 14px;
}

This feels like a clean solution; the actions stay pinned to the bottom of the card no matter how long the content is.

In a typical block layout, a container’s height is determined by the combined contribution of its in-flow children.

I’m sure you have seen how absolutely positioned elements behave. The browser still renders them, even though they no longer contribute to the parent’s intrinsic height. Visually, the actions belong to the card, structurally, the layout ignores them.

To compensate, we reserved space manually:

.card__body {
  padding-block-end: 14px;
}

This padding is really just an estimate. The moment the font size increases, buttons wrap, or translations make the text longer, the estimate stops being reliable.

Instead of trying to predict how much space the actions might need, we can let the browser calculate it.

Here is the same layout without absolute positioning:

CodePen Embed Fallback

The change is small, but the shift in behavior is quite noticeable. Even with the fixed height still in place, the internal tension shrinks because the layout is no longer working against itself.

This is the first structural improvement. The card still has an extrinsic height constraint, so the layout isn’t fully flexible yet.

Removing absolute positioning reduces internal layout tension, even before removing the fixed height.

There is an Illusion of Control

If fixed heights act like ceilings, line clamping acts more like a mute button. In the original component, I clamped the title and the excerpt:

.card__title {
  display: -webkit-box;
  overflow: hidden;
  -webkit-line-clamp: 2;
  -webkit-box-orient: vertical;
}

.card__excerpt {
  display: -webkit-box;
  overflow: hidden;
  -webkit-line-clamp: 4;
  -webkit-box-orient: vertical;
}

Clamping feels reassuring to me at that time because it limits drift and keeps cards visually aligned. But in practice, that flips the relationship.

To really see this more clearly, let’s remove clamping while keeping everything else the same. This version is identical to the previous demo except that I have removed all clamping from .card__title and .card__excerpt but left the overflow so that we can clearly see what happens.

Removing clamping exposes how much content the layout was suppressing.

Without clamping, the tension inside the component becomes obvious. You see how German card grows taller, and the excerpt wraps naturally. What this really shows us is that a stable layout shouldn’t rely on overflow: hidden. If a layout only works because content is being suppressed, it’s probably fragile.

Up to this point, almost every failure we’ve seen traces back to a single decision:

.card {
  height: 375px;
}

This one line may look innocent to you, but it overrides the browser’s default sizing behavior.

At some point, the simplest question becomes unavoidable: So what happens if we just… stop? Remove the height entirely and let the browser do its thing?

Let’s remove the fixed height while keeping the rest of the layout intact. Clamping can stay in place since we want to compare behaviors.

CodePen Embed Fallback

Once I restored intrinsic sizing inside the card, the alignment problem really became a grid issue, which brings us to our next refinement.

Let the Grid Handle Equal Heights

Fixed heights felt appealing. But having equal heights doesn’t actually mean fixing the heights manually. The grid can handle that alignment for us without me imposing hard boundaries on each component.

Sometimes, the fix is surprisingly small. Removing align-items: start lets the grid items stretch naturally, and switching to a more flexible column definition helps the layout adapt better across different screen sizes.

.card-grid {
  grid-template-columns: repeat(auto-fit, minmax(280px, 1fr));
}

See how the same layout uses intrinsic card heights and flexible grid tracks:

Grid normalizes alignment without imposing arbitrary height constraints.

To make the button nicely align like we had initially, instead of positioning and reserving space manually:

.card {
  padding: 14px;
  position: relative;
}

We turn the card into a vertical layout:

.card {
  display: flex;
  flex-direction: column;
  padding: 14px;
}

We’re not going to go deep on flexbox here, as Kevin Powell has a great article on exactly that. But it’s worth knowing what’s happening. Turning the card into a flex container with flex-direction: column lines everything up vertically from top to bottom.

The next step is removing the artificial space that was holding room for the actions:

.card__body {
  padding-block-end: 56px;
  padding-block-start: 10px;
}

That padding was a guess; it only worked as long as the content stayed predictable. Instead, we let the body expand naturally:

.card__body {
  display: flex;
  flex-direction: column;
  flex: 1;
  padding-block-start: 10px;
}

The flex: 1 tells the body to take up whatever space is left after the image, and the actions have taken what they need.

If the tags need a bit of breathing room, a simple margin does the job:

.card__tags {
  margin-block-end: 10px;
}

We get a card that looks just as aligned as in our original page, but now the alignment comes from layout flow, not from forcing the height.

Using `clamp()` for Fluid Typography

Fluid typography with clamp() can make titles scale more smoothly across viewport sizes:

.card__title {
  font-size: clamp(1rem, 2vw, 1.25rem);
}

If you want to know more about clamp(), Pedro Rodriguez’s article on scaling font size with CSS clamp() is a good read.

Declaring clamp(1rem, 2vw, 1.25rem) allows the title to scale with the viewport while staying within a safe range. The font size can grow or shrink with the viewport (2vw) but will never go smaller than 1rem or larger than 1.25rem.

Designing for Failure

None of the problems I mentioned earlier in this layout appeared while I was building it. The problems appeared only when some conditions changed. Sometimes an image didn’t load, which changed the vertical balance of the card. And as the viewport narrowed, the text had to wrap more aggressively.

If you want to know whether a component will hold up with real content, try putting it under extreme conditions. A few simple tweaks are enough to reveal where the layout starts to break or fall apart:

Increase the browser’s default font size to see how it behaves.
Enable text-only zoom instead of page zoom to observe the difference.
Replace a title with a single unbroken string or simulate other languages with longer words.
Simulate a missing image.
Shrink the viewport until the text starts wrapping aggressively.

Rather than explaining things abstractly, we can introduce them directly into the intrinsic-height version of the card.

Stress Test Mode

From the intrinsic-height version, we can add a simple toggle that simulates a few content stress cases.

Add this button inside the .demo-toolbar:

Add the following script, too:

const stressBtn = document.querySelector("#toggleStress");

stressBtn.addEventListener("click", () => {
  document.body.classList.toggle("stress");
});

This script simply listens for clicks on the button and adds or removes a stress class on the . That class acts as a switch that turns the stress-test styles on and off.

And add these styles:

body.stress .card:nth-child(1) .card__title::after {
  content: "ExtremelyLongUnbrokenStringWithoutAnySpacesToTestOverflowBehavior";
}

body.stress .card:nth-child(2) .card__excerpt {
  font-size: 1.1rem;
}

body.stress .card__media img {
  display: none;
}

These styles simulate a few common layout stress cases. The first card gets an unbroken string to test overflow behavior. The second increases text size to mimic larger default font settings. The rule on .card__media img hides media entirely to simulate a missing or failed image load.

CodePen Embed Fallback

This stability isn’t coming from the defensive rules I added at the end. It comes from the earlier structural decisions. Once fixed heights and out-of-flow positioning were removed, the component could adapt naturally to whatever content it receives.

Once you start relying on intrinsic sizing, you stop worrying about every possible string length or font setting. If the content gets longer or the text size changes, the browser can handle it. Most layout problems start when we take that flexibility away.

So, What Grows and What Doesn’t?

The original card failed for a simple reason: it depended on assumptions that were never stated. The title was supposed to fit in two lines, the excerpt was supposed to fit in four and buttons were supposed to stay on one line. Translations were supposed to stay “about the same length” and users were supposed to keep default text settings. None of that was enforced. They were simply guesses.

Those assumptions quietly made their way into my CSS. As long as the content stayed within those boundaries, everything kind of looked stable. But the moment it drifted, the layout started responding badly to the conflict.

When I rebuilt this component, the first thing I did was remove those hidden dependencies. There’s no fixed pixel ceiling anymore, no padding buffer that needs me to constantly tweak, and no truncation acting as a safety net to keep the layout from breaking.

Truncation can still be a deliberate design choice. But you shouldn’t truncate just to keep the layout from collapsing. When that happens, the component is already under strain.

The final demo shows that idea in practice. It loads stressed content by default, with longer translated text, wrapped tags, and a missing image, so that you can see how the component behaves under real conditions rather than ideal ones.

CodePen Embed Fallback

Each card grows as needed, and the grid keeps alignment without hiding overflow or relying on defensive spacing.

I Think Fixed Heights Are Still Useful

Working through this layout changed how I think about fixed heights. I still use them when they make sense, and I still clamp text when truncation is intentional. But whenever I find myself trying to control how content flows inside a component, it’s usually a sign that the layout needs to be reconsidered. Most of the time, letting the browser handle the sizing leads to a more resilient result.

Fixed-Height Cards: More Fragile Than They Look originally handwritten and published with love on CSS-Tricks. You should really get the newsletter as well.

What’s !important #10: HTML-in-Canvas, Hex Maps, E-ink Optimization, and More

Daniel Schwarz — Fri, 01 May 2026 13:43:26 +0000

Developers have been experimenting with HTML-in-Canvas, a hexagonal world map-analytics feature, a web-based OS for e-ink devices, replacing img srcs using content, and more. This is What’s !important #10.

HTML-in-Canvas experiments

HTML-in-Canvas, a new API that enables us to render real semantic HTML in a with visual effects, is the talk of the town right now, so let’s lead with that. Amit Sheen showed us how the HTML-in-Canvas API works, and also created some demos over at the HiC Showroom, like this one (requires Chrome 146 with the chrome://flags/#canvas-draw-element flag enabled):

CodePen Embed Fallback

Building a hexagonal world map-analytics feature

Ben Schwarz (awesome name, but no relation) talked about building a hexagonal world map-analytics feature. While it’s more of a retrospective than a developer walkthrough, it’s a really interesting read about analytics, design constraints, inspiration, engineering, and of course SVG and CSS.

Source: Calibre.

Rekindle — a web-based OS for e-ink devices

Rekindle is basically a web-based operating system for e-ink devices like Kindle, Kobo, and Boox, which are often low-powered with few features. Rekindle includes an insane number of features and apps, and is designed in black-and-white, with no animations, and no doubt with many more e-ink optimizations.

The takeaway isn’t a tutorial (unfortunately) or even some commentary (like with the world map retrospective above), it’s that we have a whole bunch of media queries that’d be so useful for e-ink devices if it weren’t for the fact that they’re shipping with low-powered, proprietary web browsers that don’t recognize them. Media Queries Level 5 can query hover capability, the precision of pointers, display update frequency, color depth, monochromatic bit-depth, color index size, dynamic range, and more, probably.

Thoughts? Is e-ink optimization likely to break out in the coming years, or is low demand for these media queries why a dedicated service like Rekindle needs to exist? It’s worth noting that the browsers and many of the media queries are in active development, so I don’t know. Watch this space, maybe?

Either way, I’d love to see a dev deep dive on Rekindle!

Replacing `img` `src`s using `content`

Jon discovered that CSS can be used to replace image sources, like this:

img {
  content: url(new-image.png) / "New alt text";
}

TIL! Who knew you could change the "src" of an #HTML using #CSS: img { content: url(whatever.png) } NO PSEUDOS! Seems to work in all current browsers too. How did I miss this?
— Jon (@scrwd.mastodon.social.ap.brid.gy) Apr 20, 2026 at 13:09

It’s really interesting to learn this about the content property, which has been Baseline for 11 years now. I experimented a bit more and discovered that this trick also works with the image-set() function:

img {
  content: image-set(
    url("image.png") 1x,
    url("image-2x.png") 2x
  );
}

So if you’re working on a website with non-responsive s and no way to change the markup, write the logic in CSS instead.

Implementing responsive images with `sizes=auto`

Having said that, if you do have access to the HTML, you’ll want to serve responsive images using the srcset and sizes HTML attributes. Mat Marquis demonstrated how the new sizes=auto attribute-value combination replaces responsive breakpoints for images that are loaded lazily.

If you’re interested, Amit Sheen also talked about building layouts (not necessarily images) without breakpoints.

New web platform features and updates

Firefox 150
- :muted and all other media-based pseudo-classes (no Chrome support)
- revert-rule (no Safari support)
- sizes=auto (no Safari support)
- light-dark() with image support (no Chrome/Safari support)
- color-mix() with the syntax for two or more colors (no Chrome/Safari support)
- ariaNotify() (no Chrome/Safari support)
Safari TP 242
- closedby
- Advanced attr() (no Firefox support)

If you’re keen for more content, here’s Wes Bos and Scott Tolinski of Syntax.fm discussing 10 new CSS and HTML APIs:

Until next time!

What’s !important #10: HTML-in-Canvas, Hex Maps, E-ink Optimization, and More originally handwritten and published with love on CSS-Tricks. You should really get the newsletter as well.

The Importance of Native Randomness in CSS

Alvaro Montoro — Thu, 30 Apr 2026 15:26:18 +0000

Recently, I published a story about the new random functions that have landed in CSS and how they work. In this article, we’ll explore the challenges of randomness in CSS, how the concept has evolved over time, and why this native feature is a big deal.

One of the first things I wanted to do when I started developing websites was create unique experiences that changed from person to person. Just little things: a random background here, random colors there… Even small micro-interactions, like confetti or falling snow, needed some level of randomness to feel natural.

And I was not alone! I soon discovered that many web developers (“webmasters,” at the time) wanted to do things like that: adding wow factors and a sense of uniqueness to their sites. But we had a problem: CSS.

CSS is a declarative and deterministic language. Two characteristics that clash with the idea of natural variation:

Declarative means that it focuses on the what, not the how. In contrast to imperative languages, developers using CSS tell the browser what the expected result is, but not how to achieve it.
Deterministic means that for a given input we will get the same output. Always the same. If you specify that a color will be red, that color will be red, not blue or yellow.

This is by design, and it’s one of the things that makes CSS predictable and reliable. If you understand how the layout engine works, you can tell which styles will be applied at any given time. Which is great… but not so great if you want to generate random content.

And so began a challenging (and sometimes tortuous) journey for designers and developers to achieve natural variation from a deterministic system.

The Long and Winding Road to Random Styles

The path to random styles in CSS is paved with multiple attempts and shortcomings. But at every step along the way, developers found new solutions that improved on the previous ones. Even if only a little.

Note: This timeline reflects logical progress more than a strict historical or chronological order.

CSS Pseudo-Randomness and Patterns

We can simulate randomness in CSS by creating patterns. But this is not truly random. The results will always be the same, and sooner or later people will notice the pattern.

One way to create this simulation is by using :nth-child() selectors or by playing with animations. The first method is easy but yields subpar results; the second may trick and impress some people.

Warning: Auto-playing media

contrast()

Gabriel Shoyombo — Wed, 29 Apr 2026 14:58:19 +0000

The CSS contrast() filter function increases or decreases the contrast of an element, either making colors pop out more or dulling them to gray. Unlike other filter functions like brightness() or saturate(), contrast() affects both saturation and lightness, keeping only the color’s hue.

.low {
  filter: contrast(50%);
}

.normal {
  filter: contrast(100%);
}

.high {
  filter: contrast(200%);
}

CodePen Embed Fallback

The contrast() function is defined in the Filter Effects Module Level 1 specification.

Syntax

The official syntax for the contrast() function is:

 = contrast( [  |  ]? )

Or simply:

filter: contrast();

The contrast() function is only compatible with the CSS filter and backdrop-filter properties.

Arguments

/* Using percentages */
filter: contrast(0%); /* Totally grayed out */
filter: contrast(50%); /* Partially grayed out */
filter: contrast(100%); /* No change */
filter: contrast(150%); /* Element is 1.5 times more defined */

/* Using numbers (0–1 range) */
filter: contrast(0); /* Totally grayed out */
filter: contrast(0.5); /* Partially grayed out */
filter: contrast(1); /* No change */
filter: contrast(1.5); /* Element is 1.5 times more defined */

/* Using percentages */
filter: contrast(0%); /* Totally grayed out */
filter: contrast(50%); /* Partially grayed out */
filter: contrast(100%); /* No change */
filter: contrast(150%); /* Element is 1.5 times more defined */

/* Using numbers (0–1 range) */
filter: contrast(0); /* Totally grayed out */
filter: contrast(0.5); /* Partially grayed out */
filter: contrast(1); /* No change */
filter: contrast(1.5); /* Element is 1.5 times more defined */

/* Works with CSS variables */
--amount: 200%;
filter: contrast(--amount);

/* No argument */
filter: contrast(); /* No change */

/* Negative value */
filter: contrast(-1.5); /* No effect */
filter: contrast(--amount);

/* No argument */
filter: contrast(); /* No change */

/* Negative value */
filter: contrast(-1.5); /* No effect */

The contrast() function takes a single argument, which can be a positive decimal or percentage value. The argument determines the new contrast for the element, where:

0 or 0% dries out all contrast from the element, resulting in a completely gray image.
1 or 100% leaves the element completely unchanged.
Values above 1 or 100% increase the contrast linearly.

Negative values aren’t allowed. But CSS variables are:

.element {
  --filter-amount: 150%;
  filter: contrast(var(--filter-amount));
}

How `contrast()` affects color

Like other filter functions, the contrast() filter operates purely on RGB math. Specifically, given an it multiplies each RGB channel by that and then adds 255 * (0.5 - 0.5 * ) to the result. In practice, this affects colors in one of two ways:

High contrast (greater than 1) makes light pixels get lighter and dark pixels get darker, so colors become more vivid.
Low contrast (smaller than 1) pulls all pixels toward a middle gray. This reduces the difference between light and dark areas, making the image look flat and muted.

Basic usage

Some background images, usually in hero sections or carousels, can make the foreground text difficult to read. Especially if it has very bright and dark colors, which compete with any text color. To solve this, we can use contrast() to reduce the difference between the image’s whites and blacks, making text more readable against the whole image.

img {
    filter: contrast(70%) brightness(60%);
}

The low contrast flattens the image, and as a plus, we can also reduce the image’s brightness to make the text pop regardless of its colors.

CodePen Embed Fallback

Demo: Making product card images pop on hover

Another useful application for contrast() is to highlight an image in a user’s interaction. For example, in a row of image cards, we could increase the image’s contrast and also scale it on hover

.card img {
  transition:
    filter 0.4s ease,
    transform 0.4s ease;
}

.card:hover img {
  filter: contrast(125%);
  transform: scale(1.05);
}

CodePen Embed Fallback

Is `contrast()` the same as `contrast-color()`?

While both CSS functions have similar names, they are not to be confused with each other.

contrast() is a filter function that makes an element more vivid by making whites lighter and blacks darker.
contrast-color() returns the text color with the highest contrast to a solid background. Its resulting color is either white or black, depending on which color contrasts most with the background. It is also not a filter function.

Browser support

The contrast() function is currently supported across all modern browsers.

contrast() originally handwritten and published with love on CSS-Tricks. You should really get the newsletter as well.

contrast-color()

Gabriel Shoyombo — Wed, 29 Apr 2026 14:57:48 +0000

The CSS contrast-color() function takes a value (as well as a variable) and returns either black or white, whichever is the most contrasting color for that value.

In other words, contrast-color() is sort of an accessibility tool for conforming to WCAG contrast requirements.

.card {
  background-color: var(--swatch);
  color: contrast-color(var(--swatch));
}

For example, on the next demo update the background color to see the text color change automatically.

CodePen Embed Fallback

The contrast-color() function is defined in the CSS Color Module Level 5 specification.

Syntax

The CSS contrast-color() function syntax is is formatted like this:

contrast-color() = contrast-color(  )

Let’s break that down with examples.

Arguments

/* Using a custom variable */
contrast-color(var(--base-background));

/* Passing a color directly */
contrast-color(#34cdf2);
contrast-color(green);

contrast-color() takes a as its only argument and resolves to white or black, depending on which has the highest contrast. If both white and black have the same contrast level, the function defaults to white.

Basic usage

The contrast-color() give us a simple alternative to defining multiple background and text colors, while also ensuring they are contrasting enough. Imagine we had the following scenario:

:root {
  --primary-text: #f1f8e9;
  --primary-bg: #2d5a27;
  --secondary-text: #311b92;
  --secondary-bg: #d1c4e9;
  --tertiary-text: #002b36;
  --tertiary-bg: #ff5722;
}

.primary {
  color: var(--primary-text);
  background-color: var(--primary-bg);
}

.secondary {
  color: var(--secondary-text);
  background-color: var(--secondary-bg);
}

.tertiary {
  color: var(--tertiary-text);
  background-color: var(--tertiary-bg);
}

We defined a text color for each background color in our variables, and if we had more than three possible backgrounds, we’d have had to define them all. Instead, using contrast-color(), we could define only the background color for each theme and let the function return the appropriate contrasting color for the texts.

:root {
  --primary: #2d5a27;
  --secondary: #d1c4e9;
  --tertiary: #ff5722;
}

.primary {
  color: contrast-color(var(--primary));
  background-color: var(--primary);
}

.secondary {
  color: contrast-color(var(--secondary));
  background-color: var(--secondary);
}

.tertiary {
  color: contrast-color(var(--tertiary-bg));
  background-color: var(--tertiary-bg);
}

It is important to note that contrast-color() is still a work in progress (at the time of this writing), and in some cases might not be appropriate from a design standpoint since it only returns black or white. Therefore, I recommend using it only in simple scenarios where either black or white make sense.

In fact, it has some shortcomings that are worth noting.

`contrast-color()` shortcomings

While contrast-color() appears to improve web accessibility, it has buts we should be aware of before using it.

It resolves to only black or white texts. Although the draft promises more control in the future, we have to stick to those two colors for now.
We’re stuck with white when using colors where neither black nor white is a sufficient contrast, or they both have the same contrast.
contrast-color() only works with colors for now. So, in cases where you’re working with text on background images or using font weights to increase contrast, you’ll have to find a different way to meet contrast requirements. And even if it can be technically used with gradients, these too can only go between black to white which might not provide enough contrast between the gradient colors.
contrast-color() doesn’t account for the font-size, which is a defining criterion, in choosing a contrast color. Hopefully, this will be accounted for in the future.

So, at the time of writing, it seems it’s better to manually define colors that are contrasting enough in our themes as contrast-color() isn’t really feasible right now.

Older syntax

Based on earlier articles, the contrast-color() function used to take multiple color arguments–the base color versus multiple contrasting color options to choose from:

contrast-color(var(--bg) vs red, lightgreen, blue)

This syntax no longer exists in the draft. It’s one color and one color only.

Specification

The contrast-color() function is defined in the CSS Color Module Level 5 specification.

Browser support

While browser support is limited at the time of this writing, it’s a good idea to include a fallback if you’re planning to use it on a project. We can use the @supports at-rule to detect if the browser understands the function:

.card {
  --bg-color: #2d5a27;
  background-color: var(--bg-color);

  /* Default Fallback */
  color: ghostwhite;
}

/* Use the function if supported */
@supports (color: contrast-color(red)) {
  .card {
    color: contrast-color(var(--bg-color));
  }
}

Approximating contrast-color() With Other CSS Features

Kevin Hamer

accessibility color contrast-color() CSS functions

Article on Jun 5, 2025

Exploring the CSS contrast-color() Function… a Second Time

Daniel Schwarz

color contrast-color() CSS functions

Link on Oct 8, 2025

The thing about contrast-color

Geoff Graham

contrast-color() originally handwritten and published with love on CSS-Tricks. You should really get the newsletter as well.

CSS-Tricks

Computing and Displaying Discounted Prices in CSS

The initial markup

Calculating the price cut

Showing the discounted price

Wrapping up

rotateX()

Syntax

Arguments

Setting up 3D transforms

Basic usage

Example: 3D Loading spinner

Example: 3D accordion

A note about transform-origin and rotateX()

Specification

Browser Support

rotateY()

Syntax

Arguments

Setting up 3D transforms

Basic usage

Example: Image carousel

Example: Page turn

Specification

Browser support

rotateZ()

Syntax

Arguments

Basic usage

Example: Isometric card

Specification

Browser support

rotate()

Syntax

Arguments

Basic usage

Example: Hamburger menu

Example: Loading icons

Example: Rotating text

Demo

Specification

Browser support

Related tricks!

Soon We Can Finally Banish JavaScript to the ShadowRealm

ShadowRealms

The shadow hasn’t fallen yet

Using CSS corner-shape For Folded Corners

Step 1: Set some CSS variables

Step 2: Establishing the fold

Step 3: Creating the flip side

Step 4: Positioning the flip side (::before)

Step 5: Sculpting the flip side

Folded corners using clip-path vs. corner-shape

A Scrollytelling Gift for Mum on Mother’s Day 2026

Try the interactive Mother’s Day card

Why I made this

Gamifying the experience of knowing my mum

How the scrollytelling Mother’s Day card works

In case you found this while Googling for a conventional Mother’s Day gift idea…

Google’s Prompt API

Making Zigzag CSS Layouts With a Grid + Transform Trick

The Strategy

The Grid Plan

The Grid

The Shift

Transform Percentages Are Different

The Gap Problem

The Overflow Surprise

The Fix: Reserve the Space

A Note on Accessibility

The Final Demo

Conclusion

Fixed-Height Cards: More Fragile Than They Look

Fixed-Height Layouts Look Fragile

Removing the Fixed Height

Absolutely Positioned Actions: Removed From Flow

There is an Illusion of Control

Let the Grid Handle Equal Heights

Using clamp() for Fluid Typography

Designing for Failure

A note about `transform-origin` and `rotateX()`

Step 4: Positioning the flip side (`::before`)

Folded corners using `clip-path` vs. `corner-shape`

Using `clamp()` for Fluid Typography

Replacing `img` `src`s using `content`

Implementing responsive images with `sizes=auto`

How `contrast()` affects color

Is `contrast()` the same as `contrast-color()`?

`contrast-color()` shortcomings