5 CSS Animations That Needed JavaScript Until 2026

interpolate-size and calc-size finally let a panel transition to height auto with no measuring script.
transition-behavior allow-discrete plus @starting-style animates elements both into and out of display none.
::details-content turns the native details element into a smooth disclosure with zero JavaScript.
A typed @property and the overlay property handle gradients, counters, and dialogs that used to need JS.

I already wrote about the CSS animations that quietly replaced my JavaScript libraries. This is the sequel, for the handful that were not just easier in CSS but genuinely impossible until this year. Transitioning to an unknown height. Fading an element out before it leaves the page. A smooth native accordion. A dialog that animates closed instead of vanishing. Every one of these needed a script in 2025. In 2026 the browser does them, and these are the five I now reach for first.

Transition to height: auto, At Last

This was the oldest wall in CSS. You cannot transition height from 0 to auto, so an accordion either snapped open or you measured scrollHeight in JavaScript and animated to a pixel value that broke the moment the content changed. The grid-template-rows: 0fr to 1fr trick helped but warped padding and borders along the way.


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

.panel {
  height: 0;
  overflow: clip;
  transition: height 0.3s ease;
}
.panel[data-open] {
  height: auto;
}

interpolate-size: allow-keywords opts the page into animating to intrinsic sizes like auto, min-content, and fit-content. That is the whole unlock. No measuring, no pixel target, and no resize observer when the content grows or the viewport changes. When you want finer control, calc-size(auto, size) lets you compute against the intrinsic value, so you can animate to auto plus a fixed offset, or clamp it. This single feature retired more of my layout JavaScript than anything else on the list, because nearly every expanding panel, dropdown, and FAQ section was secretly a height-measuring routine in disguise.

Two gotchas. interpolate-size inherits, so declaring it once on :root switches the behaviour on everywhere, which is what you want. And reach for overflow: clip rather than hidden during the animation, since clip will not create an accidental scroll container that fights the height change. Set the property, animate to auto, and stop thinking in pixels.

Animate In and Out of display: none

You could always animate something in. Animating it out was the trap. The instant you set display: none, the transition was cut off, so the usual workaround was a setTimeout that delayed removal long enough for a fade to finish. It worked until the timing drifted or the component unmounted early.


.toast {
  transition: opacity 0.3s, transform 0.3s, display 0.3s allow-discrete;
  opacity: 0;
  transform: translateY(8px);
}
.toast[data-show] {
  opacity: 1;
  transform: none;
}
@starting-style {
  .toast[data-show] {
    opacity: 0;
    transform: translateY(8px);
  }
}

allow-discrete lets the discrete display property take part in the transition. @starting-style supplies the pre-insertion start state, so the element animates as it appears rather than blinking into place. On the way out, display flips to none only after the transition finishes, so the fade actually plays. No timers, no orphaned nodes, and the element leaves the layout at exactly the right frame. Toasts, dropdowns, and tooltips all collapse down to this one pattern.

The ordering trips people up at first. allow-discrete has to sit on the display transition specifically, and @starting-style only applies the first time the element is styled, which is to say on insertion. If the entry animation does not play, it is almost always a missing @starting-style block. If the exit does not play, the display transition is missing its allow-discrete.

A Native, Animated Disclosure

The native and pair is the correct accordion. Keyboard toggling, screen-reader semantics, and find-in-page expansion all come free. The catch was that it popped open with no animation, so teams rebuilt it in JavaScript and lost the semantics in the process.


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

details::details-content {
  height: 0;
  overflow: hidden;
  transition: height 0.3s ease, content-visibility 0.3s allow-discrete;
}
details[open]::details-content {
  height: auto;
}

::details-content targets the revealed region, and with interpolate-size already in play it animates to its natural height. Pairing content-visibility with allow-discrete keeps the collapsed content out of the rendering and accessibility work until it is needed, which is good for both performance and screen-reader output. You get a native, animated disclosure with the correct semantics and no script. That combination of a native element plus modern CSS is the same one I leaned on in the CSS animations that already replaced my libraries.

@property Animates What Never Interpolated

A plain custom property is just a string to the browser, so it snaps between values instead of animating. Register it with @property and give it a real type, and the browser starts interpolating it. That opens up animating gradients, angles, and counters that were frozen before.


@property --angle {
  syntax: "";
  initial-value: 0deg;
  inherits: false;
}
.ring {
  background: conic-gradient(#e3fc02 var(--angle), #2a2a2c 0);
  transition: --angle 0.4s ease;
}
.ring[data-full] {
  --angle: 360deg;
}

Because --angle is typed as , the conic-gradient progress ring sweeps smoothly instead of jumping to the end. The same approach animates a rotating gradient border by driving the angle, or a counting effect by registering an and transitioning it while showing the value through a counter. I used to pull in a small animation helper for the progress ring alone. Now it is four lines of CSS and a registered property. For motion tied to scroll position, scroll-driven animations pairs naturally with this.

The one limitation to remember: only typed properties interpolate, so an unregistered --foo still snaps. If an animation mysteriously jumps straight to its end value, the missing @property registration is almost always why. Declare the type, set inherits, and the transition starts behaving like any other.

A Dialog That Animates Closed

The `element and the Popover API put content in the top layer, above everything, with backdrop and focus handling included. The missing piece was the exit. A dialog removed from the top layer used to disappear instantly, because theoverlay` property that controls top-layer membership is discrete. Now you can transition it.

dialog {
opacity: 0;
transform: scale(0.96);
transition: opacity 0.3s, transform 0.3s,
overlay 0.3s allow-discrete, display 0.3s allow-discrete;
}
dialog[open] {
opacity: 1;
transform: scale(1);
}
@starting-style {
dialog[open] { opacity: 0; transform: scale(0.96); }
}
dialog::backdrop {
background: rgb(0 0 0 / 0%);
transition: background 0.3s, overlay 0.3s allow-discrete,
display 0.3s allow-discrete;
}
dialog[open]::backdrop {
background: rgb(0 0 0 / 50%);
}
@starting-style {
dialog[open]::backdrop { background: rgb(0 0 0 / 0%); }
}

Transitioning overlay with allow-discrete keeps the dialog in the top layer until the close animation finishes, so it scales and fades out instead of blinking away. The ::backdrop fades in tandem. Popovers take the same treatment. This was the last piece of UI I still kept a script around for, and now it is style only.

Browser Support, Honestly

These five do not all sit on the same support tier, so treat them accordingly. @property is widely supported and safe to use without a second thought. @starting-style and transition-behavior: allow-discrete shipped across the major engines and are dependable in 2026. interpolate-size, calc-size(), and ::details-content are newer and Chrome-led, with the other engines catching up, and the overlay transition for dialogs is in that same newer bucket.

The rule that keeps this shippable is simple: never make the animation load-bearing. Gate the newer features behind @supports, and where a browser does not understand them, the panel still opens, the disclosure still expands, and the dialog still works. It just snaps instead of glides. Because every one of these enhances a state change that already functions on its own, the fallback is the un-animated version, which is a perfectly good experience. You are adding polish, not behaviour, so there is nothing to break.

Bottom Line

Five scripts left my projects this year. A height-measuring open and close helper, a setTimeout pattern for dismissing toasts, a disclosure plugin, a frame-by-frame progress ring, and a dialog close-animation shim. All five are CSS now, and the CSS is shorter and steadier than the code it replaced.

Two caveats keep it honest. Gate the newer features behind @supports or accept that older browsers skip the animation and still show the content, which is the right kind of progressive enhancement. And always respect motion preferences with a prefers-reduced-motion block. These were the last common cases where everyday UI still demanded JavaScript. Browse the Lab for more of them falling away.

推荐订阅源

DEV Community