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

CSS
1

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/

2

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.

3

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 :slight_smile:

4

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

5

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.

6

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.

7

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.

8

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.

1 Like