The interpolate-size property is a great example of progressive enhancement

I was listening to the latest Shoptalk Show episode and interpolate-size was mentioned, which triggered me to think “I wonder what’s going on with that now”.

Not much, it seems. We’re still looking way-off from it being in all browsers, but that’s fine because we’ve got progressive enhancement available to us.

What is interpolate-size?permalink

Why re-explain it when Bramus has already done an excellent job of that, over on the Chrome for developers blog?

An often requested CSS feature is the ability to animate to height: auto. A slight variation of that request is to transition the width property instead of the height, or to transition to any of the other intrinsic sizes represented by keywords like min-content, max-content, and fit-content.

We’ve been asking for this since before I even started writing CSS [checks notes] nearly 18 years ago [sobs].

I noticed in Bramus’ <details> demo — the exact use case of animating to auto height that sprang to my mind — is wrapping stuff in @supports.

@supports (interpolate-size: allow-keywords) {
  :root {
    interpolate-size: allow-keywords;
  }

  details {
    transition: height 0.5s ease;
    height: 2.5rem;

    &[open] {
      height: auto;
      overflow: clip;
    }
  }
}

Here it is in action.

You probably don’t need to do thatpermalink

One of my favourite CSS features is that if your browser doesn’t yet understand a property it’ll effectively be ignored. That’s a really good feature!

Advert

Let me show you how I’d approach the same problem and give you a nice easy to copy snippet.

First up, doing the same as Bramus, let’s pop the interpolate-size declaration up in the :root.

:root {
  interpolate-size: allow-keywords;
}

Let’s add the rest of the CSS code and then I’ll break it down for you.

details {
  --calculated-details-padding: var(--details-padding, 1em);

  transition: height var(--details-transition-speed, 150ms) linear;
  height: calc(1lh + (var(--calculated-details-padding) * 2));
  padding: var(--calculated-details-padding);
  background: var(--details-bg, white);
  color: var(--details-color, currentColor);
}

details[open] {
  height: auto;
  overflow: clip;
}

Instead of setting a fixed height, we’re going to calculate it. We already have a useful value to get the height of our text — the lh unit. That’s the computed line height value: perfect.

With that, we need to account for padding too, so we create a configurable custom property: --calculated-details-padding.

If --details-padding is defined, that value will be honoured and if not --calculated-details-padding will be 1em.

Next, we define a linear transition (great for movement like this) which is nice a snappy. We don’t want slow transitions here. Then, we define the padding — using the same custom property as before.

Lastly, our <details> open state sets the height to auto and the overflow to clip which you can read about here.

This setup works with multiple <details> in an accordion group context too.

All you have to do is set a matching name attribute on the <details> to get that behaviour. Similar to how we deal with related <input type="radio" /> elements.

Where’s the animation in old browsers though?permalink

It’s not there yet! This is progressive enhancement in action. We’re leaning into our browsers to deliver the right experience for them. When the other browsers like Firefox and Safari catch up, our CSS will just work.

People viewing on an older browser will get a standard snappy experience — a minimum viable experience — and importantly, it won’t be broken and we’re not loading in heavy assets to polyfill for us.

CSS always has been and always will be incredibly powerful with a progressive enhancement mindset. It’s up to us to make those choices to deliver better experiences for our users.

Advert