Transitioning To Auto Top | CSS-Methods

I do know that is one thing Chris has needed ceaselessly, so it’s no shock he’s already obtained a improbable write-up only a day after the information broke. In actual fact, I first discovered about it from his publish and was unable to dredge up any kind of announcement. So, I believed I’d jot some notes down as a result of it looks like a big growth.

The information: transitioning to auto is now a factor! Effectively, it’s going to be a factor. Chrome Canary just lately shipped help for it and that’s the one place you’ll discover it for now. And even then, we simply don’t know if the Chrome Canary implementation will discover its technique to the syntax when the characteristic turns into official.

The issue

Right here’s the scenario. You’ve a component. You’ve marked it up, plopped in contents, and utilized a bunch of types to it. Have you learnt how tall it’s? In fact not! Positive, we will ask JavaScript to judge the aspect for us, however so far as CSS is worried, the aspect’s computed dimensions are unknown.

That makes it troublesome to, say, animate that aspect from peak: 0 to peak: no matter. We have to know what “no matter” is and we will solely do this by setting a set peak on the aspect. That approach, now we have numbers to transition from zero peak to that particular peak.

.panel {
  peak: 0;
  transition: peak 0.25s ease-in;

  &.expanded {
    peak: 300px;
  }
}

However what occurs if that aspect modifications over time? Possibly the font modifications, we add padding, extra content material is inserted… something that modifications the size. We probably have to replace that peak: 300px to no matter new fastened peak works finest. This is the reason we regularly see JavaScript used to toggle issues that develop and contract in measurement, amongst different workarounds.

I say that is in regards to the peak property, however we’re additionally speaking in regards to the logical equal, block-size, in addition to width and inline-size. Or any route for that matter!

Transitioning to auto

That’s the purpose, proper? We have a tendency to succeed in for peak: auto when the peak dimension is unknown. From there, we let JavaScript calculate what that evaluates to and take issues from there.

The present Chrome implementation makes use of CSS calc() to do the heavy lifting. It acknowledges the auto key phrase and, true to its identify, calculates that quantity. In different phrases, we will do that as an alternative of the fixed-height strategy:

.panel {
  peak: 0;
  transition: peak 0.25s ease-in;

  &.expanded {
    peak: calc(auto);
  }
}

That’s actually it! In fact, calc() is able to extra advanced expressions however the truth that we will provide it with only a imprecise key phrase about a component’s peak is darn spectacular. It’s what permits us to go from a set worth to the aspect’s intrinsic measurement and again.

I needed to give it a strive. I’m positive there are a ton of use circumstances right here, however I went with a floating button in a calendar element that signifies a sure variety of pending calendar invitations. Click on the button, and a panel expands above the calendar and divulges the invitations. Click on it once more and the panel goes again to the place it got here from. JavaScript is dealing with the press interplay, triggering a category change that transitions the peak in CSS.

A video in case you don’t really feel like opening Canary:

That is the related CSS:

.invite-panel {
  peak: 0;
  overflow-y: clip;
  transition: peak 0.25s ease-in;
}

On click on, JavaScript units auto peak on the aspect as an inline model to override the CSS:

<div class="invite-panel" model="peak: calc(auto)">

The transition property in CSS lets the browser know that we plan on altering the peak property in some unspecified time in the future, and to make it easy. And, as with all transition or animation, it’s a good suggestion to account for movement sensitivities by slowing down or eradicating the movement with prefers-reduced-motion.

What about show: none?

This is likely one of the first questions that popped into my head after I learn Chris’s publish and he will get into that as nicely. Transitioning from a component from show: none to its intrinsic measurement is kind of like going from peak: 0. It would appear to be a non-displayed aspect has zero peak, but it surely really does have a computed peak or auto except a selected peak is asserted on it.

So, there’s further work to do if we need to transition from show: none in CSS. I’ll merely plop within the code Chris shared as a result of it properly demonstrates the important thing components:

.aspect {
  /* arduous mode!! */
  show: none;

  transition: peak 0.2s ease-in-out;
  transition-behavior: allow-discrete;

  peak: 0; 
  @starting-style {
    peak: 0;
  }

  &.open {
    peak: calc-size(auto);
  }
}

• The aspect begins with each show: none and peak: 0.
• There’s an .open class that units the aspect’s peak to calc(auto).

These are the 2 dots we have to join and we do it by first setting transition-behavior: allow-discrete on the aspect. That is new to me, however the spec says that transition-behavior “specifies whether or not transitions will likely be began or not for discrete properties.” And once we declare allow-discrete, “transitions will likely be began for discrete properties in addition to interpolable properties.”

Effectively, DevTools confirmed us proper there that peak: auto is a discrete property! Discover the @starting-style declaration, although. When you’re unfamiliar with it, you’re not alone. The thought is that it lets us set a mode for a transition to “begin” with. And since our aspect’s discrete peak is auto, we have to inform the transition to start out at peak: 0 as an alternative:

.aspect {
  /* and so forth. */

  @starting-style {
    peak: 0;
  }
}

Now, we will transfer from zero to auto since we’re sorta overriding the discrete peak with @starting-style. Fairly cool we will do this!

Direct Hyperlink →