Feature request: Animating max-height / height based on content

I’m making the suggestion here as well, as requested by Alan Cutter:

https://crbug.com/596330

When creating a disclosure widget:

<p><a href="#widget">Show Terms &amp; Conditions</a></p>
<div id="widget">
    <p>Long legal text, hidden by default.</p>
</div>

Developers used to use jQuery to display the hidden content with a height changing animation (so the content did not suddenly appear):

$('#widget').slideToggle();

More recently we have been using CSS animations:

#widget {
    overflow-y: hidden;
    max-height: 500px; /* approximate max height */
    transition-property: all;
    transition-duration: .5s;
}

#widget.closed {
    max-height: 0;
}

Where max-height has to be guessed (not too high, as the animation will be too fast, and not too small, as content will be unreadable).

So can we take the max-content suggestion for the auto-resizing iframe, and allow it to work on the max-height (or height) properties:

#widget {
    max-height: max-content;
}

This is related to the iframe and textarea resize requests:

Where I also have a working demo:

https://craigfrancis.github.io/iframe-height/additional/height-animation/

I support solving the problem of animating between lengths and keywords in general. It’s blocked on someone making a spec and getting buy-in from all the browser vendors, which involves solving all the problems with why it’s tricky to implement.

I’m probably not the best person to write a spec, do you know who would be a good contact?

Just thinking there is a lot of web developers who create widgets that effectively use the jQuery .slideToggle(), and it’s not easy to implement that in CSS at the moment, so this would help quite a few people

Someone who works on Web Animations might be a good starting point. https://w3c.github.io/web-animations/

But, looking at the editors of that spec, I know the 3 googlers are very oversubscribed. So, unfortunately, I don’t think there’s anyone on the Chrome team with the time for this right now. But I’ll at least point the right Chrome people at this thread. @tabatkins

Thanks, Alan Cutter has written up a nice explanation on: https://crbug.com/596330

In summary, animations currently work with known/fixed values, where a layout/paint is not required. So in this case, the animation would need to request a layout to get the height of the content.

The trick of animating max-height instead of height is actually a workaround for the issue related to lack of ability to animate from/to keywords like auto in CSS.

So if a better standard way to animate was going to be standardized, then it would probably make much more sense to do this in relation to height itself, not max-height.

Good point, I was supposed to change that to height, but while writing the message above, I was thinking about the way we do it now with max-height.

Unfortunately it does not look like this will be possible with the way animations work at the moment, so I’m also looking at a solution where JS can determine the height it needs to be (when currently overflow:hidden, and height:0)… far from perfect, but better than the hacks jQuery uses to make their implementation work.

This isn’t too crazy. The issue is that we need to allow keywords to show up in calc(), so that you can animate from 0px to auto and get calc(auto * .5) in the middle. That neatly wraps up the issue, which is finding a way to represent the intermediate values at computed-value time, when animations happens.

The CSSWG does plan to handle this, it’s just low-priority at the moment, especially since it will complicate the calc() data model for the object-based OM.