Keyword Transitions

html {
  interpolate-size: allow-keywords;
}

Link to this headingContext

The CSS transition property allows us to smoothly animate between two values. For example, we can cause an element to grow on hover like this:

<style>
  .growable-button {
    width: 10rem;
    height: 3rem;
    transition: width 400ms, height 400ms;

    &:hover, &:focus-visible {
      width: 12rem;
      height: 5rem;
    }
  }
</style>

<button class="growable-button">
  Hello World
</button>

This works because we’ve defined explicit sizes for both the hover and non-hover state. The browser knows how to do the math to get from 10rem to 12rem.

But in many real-world cases, we don’t have explicit sizes for all states. Sometimes, we want to start/end on the element’s intrinsic size.

Frustratingly, that doesn’t work:

<style>
  .growable-button {
    transition: width 400ms, height 400ms;

    &:hover, &:focus-visible {
      width: 12rem;
      height: 5rem;
    }
  }
</style>

<button class="growable-button">
  Hello World
</button>

The button gets bigger on hover, but it doesn’t animate.

We run into this problem most frequently when building accordions, since they need to animate from their intrinsic size down to 0px:

This is the problem that this new CSS declaration solves. 🎉

Link to this headingSolution

By adding interpolate-size: allow-keywords; to an element, we enable it to transition between numerical values (eg. 100px) and keyword values (eg. auto).

It’s an inheritable property, which means that if we add it to the root html node, it’ll get applied automatically to every node on the page. Set it and forget it. ✨

With this property set, we can use CSS transitions to smoothly interpolate between auto and fixed values:

<style>
  html {
    /* ✨ Enable the magic ✨ */
    interpolate-size: allow-keywords;
  }

  .growable-button {
    transition: width 400ms, height 400ms;

    &:hover, &:focus-visible {
      width: 12rem;
      height: 5rem;
    }
  }
</style>

<button class="growable-button">
  Hello World
</button>

Pretty cool, right? The width and height each transition from their default value (auto) to the specified value in rems.

Link to this headingBrowser Support

As I write this in March 2025, this property is only supported in Chromium browsers like Chrome and Edge(opens in new tab). This means that it’s only available for ~2/3rds of global internet users.

This might sound like a non-starter, but I think we actually can start using this feature today, in most cases. For folks that use an unsupported browser, they won’t see the slick animation, but the UI will still function correctly. This strikes me as an ideal candidate for progressive enhancement. I write more about my philosophy in my blog post, A Framework for Evaluating Browser Support .

That said, if you do want a solution that works across all browsers, there is a way to do this using some clever trickery with CSS Grid(opens in new tab). It feels a bit hackier than the interpolate-size approach, but if you really want to ensure a consistent experience across browsers, the grid trick is the best way to do it.

Also, if you’re building an accordion component, I would recommend looking for a component or library, since there are lots of accessibility gotchas with this sort of component. For the accordion demo above, I used Radix’s Accordion component(opens in new tab). It’ll work in all browsers (since it does the height calculation in JS), and it also addresses a number of accessibility concerns.

Link to this headingCaveats

Link to this headingAccessibility

As with all significant motion, there are accessibility implications which need to be considered. Some users have motion sensitivities and have explicitly requested to disable motion.

We can check for this using a media query:

@media (prefers-reduced-motion: no-preference) {
  html {
    interpolate-size: allow-keywords;
  }
}

If someone has a motion sensitivity, this media query will not match, and this new feature will not be enabled.

You can learn more in my blog post, Accessible Animations in React. Even if you don’t use React, the first half of the blog post contains a lot of helpful context about this stuff!

Link to this headingPerformance

The width and height properties are expensive properties to animate. Whenever their value changes, the browser has to recalculate the layout (including for all affected elements, like descendants and siblings) and repaint the pixels. In an animation, it needs to do this work 60+ times a second, for every individual frame!

Now, these days, browsers are heavily optimized, and even low-end devices are fairly powerful. So it’s not as big of a problem as it used to be.

Even so, our animations will run better and appear smoother if we use transform: scale() instead of width/height. The transform property will skip the layout and paint recalculations.

It’s not always possible to use transform: scale(). If our element contains text, for example, that text would get stretched and squashed. So it’s worth knowing about both techniques, so that we can use transforms when it’s possible, and width/height when it’s not.

You can learn more in these two blog posts:

• The World of CSS Transforms
• An Interactive Guide to CSS Transitions

Link to this headingAdditional use cases

One of the cool things about this new feature is that it doesn’t only work with the auto keyword. It also works with keywords like min-content, which causes an element to shrink down to its minimum size, based on its content.

I’m still experimenting with this stuff, but I bet there are some pretty cool possibilities here!

Link to this headingContinued Reading

You can learn more in Bramus’ wonderful tutorial on the topic, Animate to “height: auto;” in CSS(opens in new tab).