CSS-Tricks

The State of CSS Centering in 2026

Temani Afif — Fri, 22 May 2026 13:44:40 +0000

What? Another article about centering?! But all we have to do is use display: flex | grid, then align-items: center. No, it’s align-content… wait… I think it’s justify-content. Well, let’s use margin: auto, this one works all the time, right?

Despite the countless number of online resources (even CSS-Tricks has a full guide on it), it’s easy to get confused when trying to center an element, whether vertically, horizontally, or both). I am sure you will find something that works by googling or trying different combinations. But do you really understand why the code you picked works? Is it the right one for your use case? Because it really does depend and require consideration!

In this article, we will do a fresh exploration of centering in CSS, and hopefully, you will learn something new by the end of it.

I already master CSS centering. Should I skip this article?

Stay with me because we will explore hidden tricks and modern features that you may not know — safe centering, text-box, centering in anchor positioning, etc.

Is centering still hard?

No, centering is not hard. Considering all the different and various ways to center an element, it’s an easy task that generally requires two or three lines of code. But, how many ways do we have to center an element? I did the count, and I was able to enumerate 100 different ways to center an element vertically and horizontally within a container.

Are you serious,100 ways?! That’s insane.

Yes, 100 is a ridiculously high number for what should be a simple task, but that number is misleading. If you check the list, you will find I marked about 60 of them in red, meaning they are hacky and not recommended. This leaves us with roughly 30 valid approaches. And within those valid options, many are basically the same, only written differently, so we can consider them redundant.

At the end of the day, the number of “unique” and “valid” ways to center an element is less than 15 (or even 10) but it was a fun exercise enumerating the different codes that can center an element. Go check the full list, you may learn something new!

Let’s look at things from a beginner’s perspective. For me, who has been writing CSS day and night for years, it’s easy to say “centering is not hard,” but what about to a newcomer who reads this and confronted with all those different ways to center stuff? Nah, it’s not easy at all. align-items, align-content, justify-content, place-self, margin: auto. What the hell?!

Too many properties for a task that everyone claims is easy! Well, let’s pick a code that works and move on. After all, if the item is in the center, then it’s fine, right? Let’s avoid making a lot of noise around this, or the CSS fanatics will shout at me.

Don’t think that way! Centering can be hard, and that’s fine. It doesn’t mean you are stupid. It simply means you need to understand how it works.

Don’t skip the important step of “learning” (like many do); otherwise you will find yourself doing a lot of copy/paste without really understanding what is going on. Sometimes it works, but sometimes it doesn’t, and it can be very frustrating.

Learn how to align before how to center

Centering is nothing but a special case of alignment in CSS, and alignment is a complex world. It’s not only left, center, right, or top, center, bottom. It’s more than that. The good news is that you can easily learn it. For this purpose, I wrote a deep dive I called “The fundamentals of alignment in CSS.”

It’s probably one of my longest writings, but believe me, it’s worth your time (and effort). I explain how alignment works in all the different CSS layout methods. It starts with understanding the alignment theory, which has two levels of alignment (“content” and “item”) and two axes (horizontal and vertical).

Identifying the “content” and the “item” in every layout is the key to understanding how everything works. I insist on “every layout” because assuming it works the same everywhere is a very common mistake.

Do yourself a favor and read that detailed article — you will thank me later! And once you understand the core concept of alignment, centering will become child’s play.

Should I use Flexbox or Grid?

I see a lot of people who always use the same method to center an element, whatever the situation. You have the CSS Grid team and the Flexbox team. While both work, I don’t advise you to think that way. Remember that the goal is to understand and avoid quick copy/paste approaches.

Study your layout and your requirements, then decide which method to use. Maybe your case requires position: absolute or a simple text-align: center. Flexbox or CSS Grid aren’t always mandatory for centering stuff, and there is no one way that’s better than another.

That said, if I have to pick something, I would consider the following codes. Each one for each type of layout.

.container { 
  display: block;
  align-content: center;
  justify-items: center; 
}
.container {
  display: grid;
  place-content: center;
}
.container {
  display: flex;
  flex-wrap: wrap;
  place-content: center;
}

Note: justify-items in the context of a block container is not supported by all the browsers. It’s Chrome-only for now, so consider using Chrome to see the following demos.

The properties are defined in one place (the container), and the methods are suitable for centering one or multiple items.

You won’t notice a difference when centering a single item. The three methods behave the same.

CodePen Embed Fallback

With multiple items, Flexbox behaves differently. It has a responsive behavior where the items are initially laid out horizontally and wrap when the container is narrowed. Resize the container and see what happens.

CodePen Embed Fallback

And with multiple items of different sizes, they all behave differently.

CodePen Embed Fallback

We started with three approaches that give us the same “visual” result when working with a single item, but upon adding more items, we can clearly see they are different. This difference is important as it shows that it’s not about picking a random code to center stuff. It’s about understanding how each code behaves in different situations, then picking the most suitable one. It’s wrong to assume that we can center the same way using Flexbox, CSS Grid, etc. All the methods are different and rely on different mechanisms, even if they give the same result in the context of one item.

This also explains why we technically have 100 ways to center stuff. We have different layout types, and each layout has its own alignment logic. But when the structure is reduced to one item inside a container, we have a lot of choices, and many methods may look identical even though they are not.

So, let me repeat myself: Study the alignment logic behind each code to know which one is suitable for your use case. Don’t blindly copy/paste a code that simply “works.”

What about centering text?

When centering “boxes,” we generally don’t have any issues if we apply the properties correctly. But once we start dealing with text, it can be tricky to perfectly center things vertically. You know the extra space above or below that you cannot really control and you have to use magic values for line-height or padding to rectify it.

We now have a new property that allows us to fix this: text-box. It trims the extra space based on your configuration.

CodePen Embed Fallback

In both boxes, I align the content in the center using a common code. Notice that the first box is not that good. The text seems to be off, even though I am using the CSS properties correctly.

It’s frustrating, right? For CSS, everything is perfectly centered, but for us, it’s not. why!?

It’s related to how the font is designed and the space reserved for each character. Adding a border around the text will make things clear.

As you can see, the “text box” is centered, but there is unwanted space inside it. I was able to remove that space using one line of code:

text-box: cap alphabetic;

Let’s try lowercase text without descenders or ascenders.

CodePen Embed Fallback

This time I am using slightly different keywords:

text-box: ex alphabetic;

…to remove the space for perfect centering

The values look strange and unintuitive, but I have created a small generator where you can easily specify which space you want to trim and get the code in no time.

And if you want more detail on that feature, check Danny Schwarz’s “Two CSS Properties for Trimming Text Box Whitespace.”

Centering with CSS Anchor Positioning

In some cases, you may need to use absolute or fixed position, which means we are dealing with an out-of-flow element and a different alignment logic; hence, another centering technique.

The common way to do that is the classic top/left combined with translate:

left: 50%;
top: 50%;
transform: translate(-50%, -50%);

It works, and everyone is happy, but it’s not the suitable code to use. In 2026, I would consider that code hacky, and worth avoiding. It’s like creating layouts using float. That a was a valid approach until we got Flexbox and CSS Grid, which were intentionally designed for this sort for thing.

It’s the same thing with absolutely-positioned elements. Today, it’s better to rely on modern CSS features like this:

inset: 0;
place-self: center;

The inset property controls the “inset modified containing block” (IMCB) and place-self (the shorthand for justify-self and align-self) aligns the element inside the IMCB. I explain all those concepts in great detail in this article.

Where is anchor positioning in all of this?

Great question! Anchor positioning relies on absolute (or fixed) elements and has its own mechanism for controlling an element’s placement relative to its anchor. We are specifically dealing with centering, so we have to talk about a new value, anchor-center.

Let’s start with the following example:

CodePen Embed Fallback

I am placing the text box above the anchor using position-area: top. You can drag the anchor, and the text box will remain stuck to the top and centered.

Let’s update the alignment and use place-self: center.

CodePen Embed Fallback

The position looks a bit off at first glance, but if you drag the anchor and look closely, you will see the box centered within the top area.

Centering is indeed not easy! It’s confusing if you don’t know in which area your element is centered. You will think that something is broken because your eyes might not see it as a centered element.

If you want to get back to the previous position, you can use this:

place-self: end anchor-center;

…or this:

align-self: end;
justify-self: anchor-center;

What’s happening here is that, vertically, we place the element at the end (the bottom), and horizontally, we consider the center of the anchor element. In other words, the anchor-center value is what makes the element follow the anchor when you drag it!

This means we have two different ways to use anchor positioning for centering: Either (1) center relative to the selected area using the center value, or (2) center relative to the anchor using the anchor-center value.

You will rarely need to use the anchor-center value in most cases because anchor positioning comes with area-specific default alignment. Setting position-area should be enough, but it’s good to know how to adjust the alignment and understand the difference between center and anchor-center.

If you want to explore alignment in anchor positioning, I have create an interactive demo that allows you to set the area, adjust the alignment, and see the result. There are 36 different positions you can set using position-area and five alignment values per axis.

Safe and unsafe centering

You are probably wondering what safety has to do with centering, right? Don’t worry, centering doesn’t present security risks, per se, but it can be a risky thing for your content!

Take the following example:

CodePen Embed Fallback

I am using CSS Grid to center a red square within a container and we have two situations. The red square is smaller than the container (a classic situation), and the red square is bigger than the container (a less common situation).

In both situations, the red square remains centered, i.e., its center point matches the container’s center point. This is an unsafe centering approach, and yet it’s the default behavior of many centering methods.

Why is it unsafe? The content inside the container is overflowing from all sides, so if you decide to hide the overflow and add a scrollbar, some parts of the content cannot be reached, which is a form of data loss. In this case, the top and left parts are lost. That’s what I mean by unsafe.

Try scrolling the second container, and you will notice that you cannot see the red square’s top and left borders.

CodePen Embed Fallback

We can fix this by using safe alignment like this:

place-content: safe center;

Now, when an overflow occurs, the browser will shift the element to a “safer” position that displays the whole content in case we need to scroll. In other words, the browser prioritizes content visibility over centering (the exact opposite of an unsafe alignment).

CodePen Embed Fallback

I know what you’re probably thinking, and you shouldn’t be thinking that! Adding safe everywhere isn’t a good idea. Sometimes the unsafe behavior is actually what we want, so only consider safewhen you’re faced with content obstruction.

Let’s get back to the anchor positioning demo:

CodePen Embed Fallback

If you drag the anchor closer to the edges, the box is stopped by those edges (the containing block) and the default alignment is lost!

In anchor positioning, the default behavior is safe alignment. If you don’t know about it, you may spend a lot of time trying to figure out why the element is not centered.

You can change that behavior using the unsafe keyword:

place-self: unsafe end unsafe anchor-center;

Or:

justify-self: unsafe anchor-center;
align-self: unsafe end;

Now, the browser allows the box to overflow the container. It will prioritize alignment over potential content loss due to the overflow.

CodePen Embed Fallback

And if you think it’s useless to work with an unsafe alignment in anchor positioning, then you are wrong. Here is one use case where I needed to switch to an unsafe alignment. We have a sticky header with a small icon next to the website title that you can hover to show a tooltip. The sticky header creates a containing block for the tooltip and, by default, prevents it from overflowing its boundary. I had to use an unsafe alignment to allow the overflow and keep the tooltip correctly placed.

CodePen Embed Fallback

I know it can be confusing, but you will rarely need to mess with safety. Keep using the default browser behavior, but remember you have the safe and unsafe values you can use to rectify a misalignment.

Conclusion

I hope that after this article you will see centering from a different angle. It’s not about picking a code that works, and you’re done. It’s about understanding how alignment works, considering your specific use case and layout, picking the appropriate code, and, more importantly, understanding why it works.

The State of CSS Centering in 2026 originally handwritten and published with love on CSS-Tricks. You should really get the newsletter as well.

Stack Overflow: When We Stop Asking

Sunkanmi Fafowora — Wed, 20 May 2026 13:51:34 +0000

Let’s play a quick game: I’ll show a graph and try to guess what it’s about.

Source: Data Stack Exchange

No, it isn’t a crypto coin crashing a few hours after being minted. And not, it is also not an oscillatory/wavy graph made with pure CSS, but a harsher truth.

I already gave it away with the title, but it still hits like a ton of bricks to know it is the steep decline in the number of questions asked on Stack Overflow. You can see its peak around 2014 with more than 200,000 questions asked in a single month. But now in 2026, it is struggling to even hit 3,000 questions a month.

We don’t have to be experts in the field to find out the culprit. You guessed, it’s AI… mostly.

While AI is painted as the Stack Overflow killer, the truth is Stack Overflow’s downfall started long before ChatGPT’s release in late 2022.

By community accounts and also from personal experience, moderation since its peak in 2014 has been (and still is) one of the leading causes for the lack of questions.

As the site grew, Stack Overflow needed a better way to moderate the hundreds of thousands of questions asked every month: the inevitable wall that forum-based communities hit when they scale beyond a certain point. There are several ways to try to solve this, but the route Stack Overflow took might not have been the best:

On Stack Overflow, we close or delete questions that can’t be answered straight away – it’s not very sociable, but it scales wonderfully.

It’s clear Stack Overflow wasn’t focusing on the quantity of the questions but rather on the quality of them, while avoiding duplicates as much as possible. This pattern was in favor of Google searches for questions that were already answered and, hence, living on pre-answered questions instead of on users making new or duplicate ones.

It wasn’t helpful either how the community seemed to close upon itself, making it harder for beginners to even ask a question. And if you’re like me, you probably want to inquire without being told you’re stupid, as if getting punished for wanting to learn.

Generative AI was the final nail in the coffin. I can’t complain about this, as AI seemingly provides the same answers without judgment (in fact, maybe too much encouragement) nor delay, so I can see why people might prefer asking an LLM instead.

However, as I dug deeper into this, my concern was no longer about just Stack Overflow, but the tech ecosystem at large. Questions like, are we still asking questions? Are we still seeking to be better? Or do we all rely on LLMs, and solely on LLMs, for advice? That kept ringing in my mind as I continued my research.

I believe that, beyond the fall of Stack Overflow, those questions linger more than ever. How AI has generally impacted our workflow, how we can use it in problem-solving, and what we can do about this as developers.

Problem-Solving and AI

Is AI a better programmer than you? What makes a programmer better than others is as subjective as it gets, but some are eager to say that AI can write code better than you. According to that research:

AlphaCode achieves human-level problem solving skills and code writing ability as shown by performance in programming competitions.

At least that’s when it was tested against Codeforce’s (an online code competition site) problems, where I admit it can and will perform better than your average programmer. But most developers don’t care about Contest problems beyond a technical interview; they know being a software developer is so much more than that.

AI writing quality code is an extremely nuanced topic and lacks a decisive conclusion. However, if you take the time to research, you’ll find that AI-generated code has lots of flagrant differences. According to the research from Cornell:

AI-generated code is generally simpler and more repetitive, yet more prone to unused constructs and hardcoded debugging, while human-written code exhibits greater structural complexity and a higher concentration of maintainability issues.

Okay, so it can generate simple code, but can it write good code? Even solve problems better than a software engineer would?

According to MIT research, AI can write good code, but it cannot possibly think and make decisions like a software engineer. AI cannot compete on that level yet, at least without running into a lot of bugs.

Drawing on both first-hand experience and feedback, if all you do is copy-and-paste AI-generated code without careful consideration, you are bound to hit serious bugs and possibly even vulnerabilities. In fact, VeraCode published an article stating that “[…] 45% of AI-generated code contains security flaws,” after testing for security vulnerabilities in 100 AI models. That’s a large percentage of code that’s flawed security-wise and would have cost implications for any user who wants to “vibe-code” without doing thorough checks.

Fun fact: GitHub released the results of its AI in software development survey in August 2024, and over 97% of its respondents have used AI outside or inside their work. That’s even aside from the companies enforcing the use of AI in your current code workflow. It’s literally everywhere; there’s almost no escaping its usage

But, does that mean it’s all bad? The answer to that, in my opinion, is no. According to research done by Harvard Business Review, AI is effective for helping solve problems (let’s not also ignore the trade-off from the study that AI workflows result in less motivation). In essence, it is perhaps best used to enhance problem-solving effectiveness.

This means that, as AI is taking over industries and being incorporated into our daily work, it still won’t replace your creativity and problem-solving approach, which you would need to tackle unique everyday challenges. It’s difficult to replicate.

Like every other tool, AI has its limits, and without human craftsmanship behind it, the tool is almost useless. A good craftsman uses all the tools at his disposal to achieve his goals, AI being just one of them.

“The effectiveness of the tool is determined by the skill of the craftsman who created it and the ingenuity with which he utilizes it.”
Craig D. Lounsbrough

The big danger is not just security vulnerabilities, but over-dependence on the tool, which I believe will lead to an eventual decline in the number of code craftsmen in the coming generation. How should newer and experienced developers go about this?

Some Advice

Here is a list of questions I ask myself when picking up AI in my development work:

Am I asking the LLM smaller, specific questions? This way, I can verify each process step-by-step rather than eyeballing the whole system code as a whole. I’m still a developer in the sense that I am not leaving the LLM to do all the work.
Am I evaluating the output when it’s finished? In other words, do I understand what it did? Would I be comfortable modifying the generated code if I know a better approach, or when I have to maintain it in the future?
Am I checking the tool’s references? This may be more geared towards research instead of straight code output. Where exactly are its answers coming from? Are those good sources? Are there others? It’s important to know the tool is not citing a fictional source, but rather, coming up with modern and tried-and-true approaches.
Have I tested the work? Did the tool understand the task and consider all edge cases? This is perhaps the most important question because knowing how people use your application is something a machine is less inclined to know than a human.

What happens when we stop asking?

Think about this: if we stop asking questions, how will AI be trained in the future? Technologies change and improve over time. What’s updated now will soon become old-fashioned. Take CSS, for example. With the recent CSS updates (nesting, view transitions, container queries, etc.), we are writing CSS vastly different than even a few short years ago. You wouldn’t want to be stuck with an outdated and clumsy solution trained from code written decades ago. If we stop asking questions and answering them, don’t you think that would make the LLMs lag behind? That’s just me speculating, but I think it’s easy to imagine that being the case.

We cannot deny Stack Overflow’s service over the years. It got us asking. It got us answering. It got us thinking. The question we should all ask ourselves is,Will LLMs do the same?

I’ll leave you with this quote from Stack Overflow co-founder Jeff Atwood:

Stack Overflow is you. This is the scary part, the great leap of faith that Stack Overflow is predicated on: trusting your fellow programmers. The programmers who choose to participate in Stack Overflow are the “secret sauce” that makes it work.

Stack Overflow: When We Stop Asking originally handwritten and published with love on CSS-Tricks. You should really get the newsletter as well.

Cross-Document View Transitions: The Gotchas Nobody Mentions

Durgesh Rajubhai Pawar — Mon, 18 May 2026 13:47:19 +0000

I wasted an entire Saturday on this.

Not a lazy Saturday either, but one of those rare, carved-out, “I’m finally going to build that thing” Saturdays. I’d seen Jake Archibald’s demos. I’d watched the Chrome Dev Summit talk. I knew cross-document view transitions were real, that you could get those slick native-feeling page transitions on plain old multi-page sites without a single framework. No React. No Astro. No client-side router pretending your multi-page application (MPA) is single-page application (SPA). Just HTML pages linking to other HTML pages, with the browser handling the animation between them. Hell yes.

So I started building. And nothing worked.

The first tutorial I found had me dropping into my . Seemed simple enough. I added it to both pages, clicked my link, and… nothing. No transition. No error. Just a normal, instant page load like it was 2004. I opened DevTools, double-checked my syntax, restarted the server, tried Chrome Canary, cleared the cache. Nothing. I did what any self-respecting developer does at that point – I copied the code character by character from the blog post and pasted it in. Still nothing.

I spent two hours convinced I was an idiot.

Turns out that tag syntax? Deprecated. Gone. Chrome shipped it, then replaced it with a CSS-based opt-in, and half the internet’s tutorials still show the old way. Those older blog posts still rank well. They look authoritative. And they’re just wrong now. Not wrong because the authors were bad – wrong because the spec moved under everyone’s feet and nobody went back to update their posts.

The other half of the tutorials I found were about same-document view transitions. SPA stuff. document.startViewTransition() called in JavaScript when you swap DOM content yourself, which is cool and useful but a completely different feature when you actually sit down to implement it. The API surface is different. The mental model is different. The gotchas are very different. And yet, Google “view transitions tutorial” and good luck figuring out which flavor you’re reading about until you’re three paragraphs deep.

So if you’re here, I’m guessing you’ve been through some version of this. You tried the meta tag. It didn’t work. You tried the JavaScript API on a real multi-page site and realized it only fires within a single document. You maybe got something half-working in a demo but it fell apart the second you added real content â€” images stretching weird, transitions hanging for seconds with no explanation, or your CSS file turning into 200 lines of view-transition-name declarations because you have a grid of 40 product cards. You blamed yourself. It wasn’t your fault. The documentation ecosystem around this feature is a mess right now, and the spec has been a moving target.

This is Part 1 of a two-part series, and it’s the article I wish existed on that Saturday. We’re going to cover the actual current way to opt in with @view-transition in CSS (not the meta tag, not JavaScript), then dig into the 4-second timeout that will silently kill your transitions on slow pages and how to debug it, then fix the aspect ratio warping that makes every image-heavy transition look like a fun house mirror, and finally get a proper handle on the pagereveal and pageswap events that give you programmatic control over the whole lifecycle.

In Part 2, we’ll tackle the scaling problem – how to handle view-transition-name across dozens or hundreds of elements without your stylesheet becoming a disaster, the difference between view-transition-name and view-transition-class, just-in-time naming patterns, and doing prefers-reduced-motion the right way.

Cross-Document View Transitions Series

The Gotchas Nobody Mentions (You are here!)
Scaling View Transitions Across Hundreds of Elements (Next Monday!)

Grab coffee. Maybe a refill. This one’s dense and I’m not going to waste your time, but there’s a lot of ground here and none of it is obvious.

The Old Way is Dead

/* THIS is the current opt-in - goes in your CSS */
@view-transition {
  navigation: auto;
}

Here’s the minimal setup. Two HTML files, one CSS rule on each. Note that, as of 2026, cross-document view transitions are supported in Chromium-based browsers and Safari 18.2+. Firefox support is in progress as I’m writing this.

CodePen Embed Fallback

That’s it. Two HTML files. One CSS rule on each. Click a link between them in a supporting browser (like modern Chromium or Safari 18.2+) and you get a smooth cross-fade. No JavaScript. No meta tags. No build step. The browser snapshots the old page, snapshots the new page, and animates between them automatically.

Now, why did the spec move from a meta tag to a CSS at-rule? It wasn’t arbitrary.

The meta tag was a blunt instrument. It was on or off for the entire page. You couldn’t say “enable transitions on desktop but not on mobile where the animations feel janky on low-end hardware.” You couldn’t conditionally opt in based on user preferences. It was just… there, or not.

The CSS approach opens all of that up:

/* Only enable transitions if the user hasn't asked for reduced motion */
@media (prefers-reduced-motion: no-preference) {
  @view-transition {
    navigation: auto;
  }
}

/* Only enable on viewports wide enough for the animation to feel good */
@media (min-width: 768px) {
  @view-transition {
    navigation: auto;
  }
}

That’s a real upgrade. You get the same conditional power you already have with every other CSS feature. Media queries, @supports, whatever scoping logic you want — it all just works because the opt-in lives where your styles live.

There’s also a subtlety that matters: the CSS rule can be different on the old page versus the new page. Both pages need to opt in for the transition to fire. If Page A has @view-transition { navigation: auto; } but Page B doesn’t, you get no transition. This is actually useful – it means your 404 page or your login redirect can skip transitions without any JavaScript coordination.

One more thing worth noting here: navigation: auto only kicks in for user-initiated, same-origin navigations. If the user clicks a regular link or hits the browser’s Back button, you get a transition. But window.location.href = "/somewhere" set programmatically, or a cross-origin link, or a form submission with a POST? No transition. The browser is intentionally conservative about when it fires, and honestly that’s the right call. You don’t want a fancy cross-fade on a POST request that’s creating a payment.

Look, if you’ve been following an outdated tutorial and your transitions just silently don’t work, this is almost certainly why. The meta tag shipped in Chrome 111, got a few months of real-world use, and then the Chrome team deprecated it in favor of the CSS at-rule starting around Chrome 126. No console warning. No error. The old syntax just quietly does nothing now. Honestly, a deprecation warning in DevTools would’ve saved me (and probably you) a lot of grief, but here we are.

Swap the meta tag for the CSS rule. That’s step one. Everything else in this article builds on it.

Your Transition Will Randomly Die, and Here’s Why

// Drop this in your pages to see what's actually happening
window.addEventListener("pagereveal", (event) => {
  if (!event.viewTransition) {
    console.log(
      "No view transition - page didn't opt in or browser skipped it",
    );
    return;
  } // This is the one that'll save your sanity

  event.viewTransition.finished
    .then(() => console.log("Transition completed ✅"))
    .catch((err) => {
      // You'll see "TimeoutError" here and nowhere else
      console.error("Transition killed:", err.name, err.message);
    });
});

Here’s the thing nobody puts in their blog post: cross-document view transitions have a hard 4-second timeout. If the new page doesn’t reach a state the browser considers “renderable” within 4 seconds of the navigation starting, the transition just… dies. No animation. No cross-fade. The new page snaps in like view transitions don’t exist. And unless you’ve got that pagereveal listener wired up and your console open, you won’t get any indication that anything went wrong.

Four seconds sounds generous, until it isn’t.

Think about what happens on a real site. Your page loads. The HTML arrives, fine, that’s fast. But maybe you’ve got a big hero image that’s render-blocking. Maybe there’s a slow API call that your server waits on before sending the response – a product page hitting an inventory service, a dashboard waiting on analytics data, anything with server-side rendering that actually does work before responding. Maybe you’re on a decent connection but the page has three web fonts loading from Google Fonts with font-display: block. Any of these can push you past that 4-second window, and the timeout doesn’t care why you’re slow. It just cuts the transition.

The really maddening part? It works perfectly on localhost. Your dev server responds in 80ms. The transition is butter. You deploy to production, your server’s cold-starting a lambda or your CDN cache missed, and suddenly users get zero transitions on the first click. You can’t reproduce it locally. You start questioning everything.

// You can also catch this on the OLD page using `pageswap`
// Useful for cleanup or logging which navigations fail
window.addEventListener("pageswap", (event) => {
  if (event.viewTransition) {
    event.viewTransition.finished.catch((err) => {
      // Log it, send it to your analytics, whatever
      console.warn("Outgoing transition aborted:", err.name);
    });
  }
});

So, what do you actually do about it?

Option one: make your page faster. I know, groundbreaking advice. But seriously – if your cross-document transition is dying, that’s a signal your page load is genuinely slow. The timeout is acting as a performance canary. Look at your Performance tab in DevTools, run a Lighthouse audit (which may not be perfect), figure out what’s blocking first render. This isn’t view-transition-specific advice, but the timeout forces you to care about it.

Option two is more interesting, and it’s the thing I wish I’d known about immediately.

CodePen Embed Fallback

This:

…tells the browser: “Don’t consider this page renderable until an element matching #hero is in the DOM.” That sounds like it would make things slower, and in a way it does – it delays first paint. But for view transitions, that’s exactly what you want: you’re telling the browser to hold the snapshot until the important content is actually there, rather than snapping a screenshot of a half-loaded page or, worse, timing out because some image in the footer is still downloading and blocking something.

It’s a trade-off. You’re choosing a slightly delayed, but smooth, transition over a fast, but-broken, one.

Honestly, the 4-second limit is probably the right call from the browser’s perspective. You don’t want a user clicking a link and staring at a frozen page for 10 seconds while the browser waits to do a fancy animation. At some point, just showing the damn page is better than a pretty transition. But I wish Chrome would surface the timeout more visibly – a DevTools warning, a performance marker, something. Right now it fails silently and that’s the whole problem.

One more thing worth knowing: the timeout clock starts when navigation begins, not when the new page’s HTML starts arriving. Network latency counts. The Time to First Byte (TTFB) Core Web Vital counts. If your server takes 2 seconds to respond and your page takes 2.5 seconds to render after that, you’re over the limit even though neither half feels slow on its own.

A debugging tip that’s saved me more than once: Chrome’s DevTools has an Animations panel (it’s under “More tools” if you don’t see it) that can actually capture view transitions in action. You can slow them down to 10% speed, replay them, and inspect the pseudo-element tree mid-animation. It’s not obvious that it works for view transitions, but it does. Between that and the pagereveal listener above, you can diagnose most timeout issues pretty quickly.

Put that pagereveal listener in early. Watch your console during testing. You’ll thank yourself later.

Why Your Images Look Like Taffy

This one’s easier to show with a same-document demo first (since you can actually run it in a single file), but the problem and the fix are identical for cross-document transitions.

CodePen Embed Fallback

Run that. Click the image. Watch the dog turn into silly putty.

The image itself has object-fit: cover on both sides. The thumbnail looks fine, the hero looks fine. But during the transition? The browser doesn’t transition your element. It takes a screenshot of the old state, takes a screenshot of the new state, and morphs between them. Those screenshots are flat raster images. Your carefully applied object-fit? Gone. The browser is just scaling a bitmap from one box size to another, and when a 150Ã—150 square gets stretched into a 600Ã—300 rectangle, you get taffy.

Here’s the fix:

/* THE FIX - target the transition pseudo-elements directly */
::view-transition-old(hero-img),
::view-transition-new(hero-img) {
  /* Treat the snapshot like an image in a container - crop, don't stretch */
  object-fit: cover;
  overflow: hidden;
}

CodePen Embed Fallback

That’s the whole thing. Two properties on two pseudo-elements.

What’s actually happening: the browser generates a tree of pseudo-elements for every named transition. For an element with view-transition-name: hero-img, you get this structure during the animation:

::view-transition
└── ::view-transition-group(hero-img)
    ├── ::view-transition-old(hero-img)
    └── ::view-transition-new(hero-img)

The ::view-transition-group smoothly animates its width and height from the old dimensions to the new ones. That’s the morphing rectangle you see. Inside it, the old and new pseudo-elements hold the actual bitmap snapshots, and by default they’re set to object-fit: fill – meaning “stretch to fill whatever box you’re in, aspect ratio be damned.”

Switching to object-fit: cover tells those snapshots to maintain their aspect ratio and crop the overflow instead. Same mental model as a background image with background-size: cover. The transition still animates the box from square to rectangle (or whatever your shapes are), but the image inside crops gracefully instead of warping.

You could also use object-fit: contain here if you’d rather see the full image with letterboxing instead of cropping. It depends on what looks right for your content. But cover is what you’ll want 90% of the time, especially for product images and hero shots.

For cross-document transitions, the CSS is identical – you just put it in both pages’ stylesheets:

/* This works cross-document. Same selectors, same fix. */
/* Put it in your shared CSS file that both pages load. */
@view-transition {
  navigation: auto;
}

::view-transition-old(hero-img),
::view-transition-new(hero-img) {
  object-fit: cover;
}

/* You can also control the animation timing on the group */
::view-transition-group(hero-img) {
  animation-duration: 0.4s;
  animation-timing-function: cubic-bezier(0.4, 0, 0.2, 1);
}

Honestly, I think object-fit: cover should be the default on these pseudo-elements instead of fill. I get why the spec chose fill – it’s predictable, it matches what object-fit defaults to on replaced elements everywhere else in CSS – but in practice, how often do you actually want a stretched bitmap during a transition? Almost never. You’ll be adding this override on basically every image transition you build.

One more variant that’s useful when the aspect ratios are wildly different – say a tall portrait thumbnail transitioning into a cinematic widescreen hero:

/* Fine-tune where the crop happens on each side of the transition */
::view-transition-group(hero-img) {
  overflow: hidden;
  border-radius: 8px; /* keep it pretty mid-flight */
}

::view-transition-old(hero-img) {
  object-fit: cover;
  object-position: center center;
}

::view-transition-new(hero-img) {
  object-fit: cover;
  object-position: center top; /* keep the top of the hero visible */
}

You can set different object-position values on old versus new, which lets you control where the crop happens on each side of the transition independently. The old thumbnail might look best cropped from center. The new hero might need to anchor to the top. Mix and match.

This took me an embarrassingly long time to figure out. The fix is two lines of CSS, but if you don’t know the pseudo-element tree exists, you don’t even know what to target. Now you do.

The Two Events That Tie it All Together

You’ve already seen pagereveal and pageswap show up in the code above, but let’s take a step back and talk about what they actually are. Understanding these two events is going to be important, because in Part 2 we’ll lean on them heavily for the just-in-time naming pattern that makes view transitions actually scale.

Cross-document view transitions happen across two pages that have no JavaScript connection to each other. Page A doesn’t know about Page B’s DOM. Since the old and new pages have no way to communicate directly, these events are your only way to coordinate the transition on both sides. Page B didn’t exist when Page A was running. So how do you coordinate anything? How do you decide which elements to name, or customize the transition based on where the user is heading?

That’s what these two events are for. They’re your hooks into the transition lifecycle, one on each side of the navigation.

pageswap fires on the outgoing page, right before it gets replaced. This is your last chance to touch the old page’s DOM before the browser snapshots it. The event gives you two key properties:

event.viewTransition: the ViewTransition object for this navigation, or null if no transition is happening.
event.activation: a NavigationActivation object that tells you where the user is going.

That activation property is the really useful one. event.activation.entry.url gives you the destination URL, and event.activation.navigationType tells you whether it’s a push, replace, traverse (back/forward), or reload. This means you can customize the outgoing side of the transition based on the destination. On a product listing page, for example, you can check which product the user clicked, find the matching card, and assign a view-transition-name to just that element right before the snapshot happens.

pagereveal fires on the incoming page, right after the page becomes active but while the transition is still running. This is your chance to set up the new side. The event gives you:

event.viewTransition: same deal, the ViewTransition object or null.

On the incoming page, you check where the user came from using navigation.activation.from.url (via the Navigation API), and you read the current URL from window.location. Between those two pieces of information, you know exactly what kind of navigation just happened and can set up the incoming page’s transition elements accordingly.

Here’s the full lifecycle in order:

User clicks a link on Page A.
pageswap fires on Page A. This is your window to name elements and customize outgoing state.
Browser snapshots the old page (capturing any named elements).
Navigation happens, new page loads.
pagereveal fires on Page B. You can name elements, customize incoming state.
Browser snapshots the new page.
Transition animates between the two snapshots.
viewTransition.finished resolves (or rejects) on both sides.

Three things to keep in mind with these events:

First, always guard with if (!event.viewTransition) return at the top of your handlers. pagereveal actually fires on every navigation – initial page load, back/forward, the works – not just view transitions. If there’s no transition happening, event.viewTransition will be null, and your handler should bail out gracefully. These handlers are transition sugar, not application logic. Never put side effects in them that you need for the page to work.

Second, pageswap only fires if the old page opted into view transitions and the navigation is same-origin. If the user middle-clicks to open in a new tab, or the navigation goes cross-origin, the event either won’t fire or event.viewTransition will be null. That’s fine, your guard clause handles it.

Third, and this is easy to overlook: both events give you access to viewTransition.finished, which is a promise that resolves when the transition completes or rejects if something goes wrong (like a timeout). Always use this for cleanup, as in removing view-transition-name values you set dynamically, resetting state, whatever. Stale names from a previous transition will ruin your next one.

We’ve been using these events lightly so far – a pagereveal listener to catch timeouts, a pageswap listener for logging. In Part 2 of this little series, they become the backbone of the whole scaling strategy. Stay tuned.

What’s Next

That covers the three gotchas that’ll bite you first: the deprecated meta tag that silently does nothing, the 4-second timeout that kills transitions without telling you, and the image distortion that turns every aspect ratio change into a fun house mirror. Plus the two events that give you hooks into the whole lifecycle.

In Part 2, we’ll tackle the scaling problem. When you’ve got a grid of 48 product cards and each one needs a unique view-transition-name, how do you keep your CSS from exploding? The answer involves view-transition-class (which is different from view-transition-name in ways that aren’t obvious), a just-in-time naming pattern using the pageswap and pagereveal events we just covered. And one critical note: we’ll cover prefers-reduced-motion in Part 2, but if you take nothing else from this series, take this: animations can literally make people physically nauseous. Always check that preference and respect it.

The gotchas are behind you. Now it’s time to make it scale.

Cross-Document View Transitions Series

The Gotchas Nobody Mentions (You are here!)
Scaling View Transitions Across Hundreds of Elements (Next Monday!)

Cross-Document View Transitions: The Gotchas Nobody Mentions originally handwritten and published with love on CSS-Tricks. You should really get the newsletter as well.

What’s !important #11: 3D Voxel Scenes, Flying Focus, CSS Syntaxes, and More

Daniel Schwarz — Fri, 15 May 2026 13:16:34 +0000

If 3D voxel scenes (that you can style), flying focus animations, or new CSS syntaxes sound like your kinda thing, then this issue of What’s !important is definitely for you.

Also featuring Polypane, scroll-driven animations, and the latest web platform updates from Chrome 148 and Safari 26.5.

Heerich.js for 3D voxel scenes

Inspired by the sculptures of Erwin Heerich, David Aerne created Heerich.js, a tiny engine for creating 3D voxel scenes. They’re rendered as SVG, and because we can use CSS variables in SVG, the scenes are basically styleable using CSS.

Polypane snippets

Polypane, widely considered to be the best browser for web development, launched a snippet store. So, if you wanted to click on a component and copy the basic HTML without all of the “bloaty crap”, the 1-Click De-crapulator is what you’d want. Fantastic name, by the way.

Animating focus with view transitions

Chris Coyier showed us how to animate focus with view transitions. He also contrasted “unnecessary motion” with WebAIM’s conditional prefers-reduced-motion implementation, which I think is the right approach, because I find it difficult to keep track of focus even when it’s really visible.

CodePen Embed Fallback

Either way, it’s a fantastic exploration of techniques. In addition, way down in the comments, Kilian Valkhof (founder of Polypane, actually) shared his CSS-only technique for floating focus (or, as Chris calls it, “flying focus”).

The `of` syntax

Paweł Grzybek mentioned that the of syntax is actually well supported (Baseline) now, but honestly, I hadn’t even heard of it.

I knew that the CSS :nth-child(n of selector) is a thing, but I didn’t know how well supported it is nowadays. Another thing I didn’t know is that I can use CSS nesting with it like in the example below. Modern CSS is incredible ❣️ developer.mozilla.org/en-US/docs/W… #css

[image or embed]
— Paweł Grzybek (@pawelgrzybek.com) 17:51 · May 5, 2026

The following selector means, “from all siblings, select the second .intro, but only if it’s a

.” It’s kind of like div:nth-of-type(2), except that can only select elements of the same type, whereas of works with any selector.

div:nth-child(2 of .intro) {
  /* ... */
}

Given that & is equivalent to the parent selector (so, .intro), the second example means “from all siblings, select the second .intro within .intro. Also, because there isn’t anything before :nth-child(), .intro can be anything this time around.

.intro {
  :nth-child(2 of &) {
    /* ... */
  }
}

There’s so much happening with CSS right now, so I find it really useful when something I’ve missed comes back around like this. Though funnily enough, as I’m typing this, I’m seeing that Preethi Sam wrote an article on the of syntax a bit over a week ago (*adds to reading list*).

Understanding the range syntax

The range syntax is a new(ish), more readable syntax with comparison operators (>, <, >=, and <=) for media queries and container queries. Ahmad Shadeed expertly explained how the range syntax works, but keep a close eye on browser support. Web browsers are still shipping container queries and the range syntax for those queries has to be shipped independently. For example, container style queries are shipping in Firefox 151 next week, but the range syntax for container style queries will ship with a flag.

It’s an easy thing to miss (don’t ask me how I know).

Understanding scroll-driven animations

Scroll-driven animations can be kinda tough (especially those with view() timelines), but Josh Comeau’s expert explanation of scroll-driven animations makes them so much easier to understand. With scroll-triggered animations on the way, I highly recommend mastering scroll-driven animations first (if you haven’t already). Again, don’t ask me how I know (*cries in CSS*).

New web platform updates

Chrome 148
- Name-only container queries (now Baseline)
- revert-rule keyword (no stable Safari support)
- at-rule() function for feature queries (no Safari or Firefox support)
- loading attribute for / (no Safari or Firefox support)
Safari 26.5
- :open pseudo-class (now Baseline)
- Updated random() function (no Chrome or Firefox support)

Inspired by this lovely comment, we’d just like to thank our authors for all of the incredible work that they do, as well as the many other educators out there that we undoubtably learn from and become inspired by. Keep on keeping on, CSS-Tricksters!

I'm not a CSS expert, but expert CSS educators are my favorite. Their design skills, ability to take full advantage of the web platform, AND general enthusiasm for building for the web is unmatched by other types of developers!
— George Rodier (@georgerodier.com) 15:42 · Apr 30, 2026

Until next time!

What’s !important #11: 3D Voxel Scenes, Flying Focus, CSS Syntaxes, and More originally handwritten and published with love on CSS-Tricks. You should really get the newsletter as well.

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

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

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

/*  in radians */
rotate(1.57rad)  /* Rotates ~90 degrees clockwise. */
rotate(-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.

CSS-Tricks

The State of CSS Centering in 2026

Is centering still hard?

Learn how to align before how to center

Should I use Flexbox or Grid?

What about centering text?

Centering with CSS Anchor Positioning

Safe and unsafe centering

Conclusion

Stack Overflow: When We Stop Asking

Problem-Solving and AI

Some Advice

What happens when we stop asking?

Cross-Document View Transitions: The Gotchas Nobody Mentions

Cross-Document View Transitions Series

The Old Way is Dead

Your Transition Will Randomly Die, and Here’s Why

Why Your Images Look Like Taffy

The Two Events That Tie it All Together

What’s Next

Cross-Document View Transitions Series

What’s !important #11: 3D Voxel Scenes, Flying Focus, CSS Syntaxes, and More

Heerich.js for 3D voxel scenes

Polypane snippets

Animating focus with view transitions

The of syntax

Understanding the range syntax

Understanding scroll-driven animations

New web platform updates

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

The `of` syntax

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