Confirming the issue as this is a feature request.

Waiting for further inputs on this.

craig.francis@gmail.com, Meanwhile can you please provide a sample test case to debug the issue from test team end.

As far as I can tell this is a request to be able to animate from {max-height: 0} to {max-height: max-content}. This is currently not possible as there is no spec for animating between lengths and keywords.

I recommend suggesting this capability for the web platform here: https://discourse.wicg.io/

I can confirm this is a feature request (as per the title).

The github.com link (above) demonstrates this is a common problem that developers currently fix with JavaScript, or by guessing at a max-height (which often goes wrong).

This "Issue" has been raised on other browsers bug reporters, prompting them to implement this feature, and for the W3C to eventually standardise it.

The discussion has currently halted on the `www-style@w3.org` mailing list:

https://lists.w3.org/Archives/Public/www-style/2016Mar/0198.html

For a working demo (also attached), please see:

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

Deleted: index.html 4.2 KB

index.html 4.2 KB View Download

Deleted: toggle.js 1.6 KB

toggle.js 1.6 KB View Download

Thanks for providing the additional spec discussion context.

From the perspective of animation code this feature is blocked on CSS syntax and layout being able to accept something like calc(40px + 0.3 * max-content) as length values.
Someone familiar with layout may be able to explain why this a difficult problem for spec editors and implementers.

Good point, that keyword might make this case harder (originally it came as a suggestion for the iframe resizing problem).

Maybe a different keyword would help?

The intention is for it to just represent the computed height of the content, irrespective of padding/margin/etc.

I was also intending for this to only be implemented on the height property (I think it would be confusing if it's applied to width/borders/etc), and maybe we add a restriction to not allow its use in a calc()?

That way we are breaking the implementation into 2 phases (where phase 1 should cover most use cases, and is hopefully much easier to do).

> maybe we add a restriction to not allow its use in a calc()?

I mention calc(40px + 0.3 * max-content) as an example value as that is how it would probably work with the way CSS animations are currently specced.

CSS Animations and Transitions evaluate their animated values prior to any layout algorithms (max-content is unknown) because these animations feed into the evaluation of layout and paint. It's highly unlikely for a spec to require that animation depend on layout computation because it introduces cyclic data dependencies that in general have no cheap resolution methods.

To illustrate this when you animate max-height from 80px to 60% at half way you'll see calc(40px + 30%) in getComputedStyle(): https://jsfiddle.net/kkmp40c8/
The animation has no idea what 30% resolves to as a pixel value because as that requires layout so it defers the combination of pixels and percentages for the layout system to resolve later.

The other reason I mention calc() is for getComputedStyle(). We need to be able to return a representative value from getComputedStyle(target).maxHeight that is legal CSS syntax.


The Javascript solution (jQuery) has the advantage of being able to decide the arbitrary point in time at which to snapshot the element's absolute height. It becomes the gate keeper for data flowing from layout to animation and can be reasoned about in constrained settings to ensure cyclic craziness won't occur.

Thanks for the detailed reply Alan, I really appreciate it.

I must confess I don't spend much time doing animations. I'm more of a system developer, where the users are lucky when I do more than toggle `display: none/block`. I do know how useful it is to show where the content came from, but I try to avoid animations because its an extra level of complexity that can go wrong (both the jQuery and max-height methods are buggy).

So, just to confirm, from the browsers point of view an animation is setup by changing one or more properties, from one known/fixed value to another, where those values are currently not returned from the document (aka using layout information).

Taking the second example at:

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

Where `max-height` changes from 0 to (the badly chosen) 90px, it means that it does not need to force a layout/paint to get that 90px.

I can certainly see how that makes animations much easier to implement, I'm just wondering if there is any way we could cheat, or provide a different solution?

---

On a bit of a tangent, am I missing something obvious when I set `overflow-y: hidden; height: 0;` and want to find out (with JavaScript) what the new height should be?

Just realising that the toggling of the `closed` class will probably need to be done with JavaScript, so the correct height could be set to a computed value during the animation, with it being changed to `height: auto` after the animation (just in case the content/viewport/text-size was to change).

I realise the jQuery approach is perhaps more complicated than it needs to be, where it effectively sets it to `display: block`, to get the height with their getWidthOrHeight() function, changes the height to 1px (hoping the browser does not render), then creates a tween to the just displayed height - which seems excessive for quite a common feature.

Can't we get the height of the overflowed content?

I'm afraid I don't know of a nice way to get the overflowed content height in the general case currently. I think web APIs are lacking when it comes to measurement of content resulting in layout gymnastics like what you described jQuery doing.

This is probably an area of specification that Houdini fragments should be able to improve upon: https://drafts.css-houdini.org/box-tree-api/

It will be interesting to see what the fragments spec can be used for (not sure it will help with this case though, as the short description implies that fragments are smaller than boxes, and I'm assuming a div will be considered a box).

In the mean time, I'll continue to use the jQuery approach (or something like it), and hope that I'll find a use for animations in the future (my websites really don't need pretty animations, a simple show/hide is about it).