Repository navigation
[css-transitions] Transition to height (or width) "auto" #626
Description
(Edited: current resolved-on proposal is at #626 (comment))
https://drafts.csswg.org/css-transitions/#animtype-rect
It would be incredibly useful to be able to transition to (or from) height: auto. As it stands now, you need to jump through a bunch of hoops in JavaScript to simulate it. This is used frequently for transitioning in alert boxes, opening accordions, etc, but it seems silly that JavaScript is required.
I’m sure there must be discussion about this in the old mailing list, but I’d love to be privy to it here.
Reacted by Kevin Yank, Ilya Streltsyn, Chris Rebert, Nicolas Hoffmann, Stephen Sorensen, Ricky Patel, Amelia Bellamy-Royds, Brad Frost, Una Kravets, Carson Shold and 415 more
Reacted by chpio
Reacted by Michael Black Ritter, Sahand Nayebaziz, Mike Foulk, Kuba Niewiarowski, Alisa Sireneva, Meteor0id, mengel9, Tim James, Sean Davey, Boghyon Hoffmann and 16 more
Reacted by Una Kravets, nilssolanki, Florens Verschelde, Steve Thomson, Hjalmar Sköldefors, Iacami Gevaerd, Kyle Poole, Johannes Ewald, Michael Black Ritter, Emrah Bilbay and 68 more
Reacted by ⁂ Tommi
Reacted by ⁂ Tommi
Activity
AmeliaBR commentedon Oct 20, 2016
Adding here what I replied to @keithjgrant via Twitter:
In order to interpolate to/from an
autoor other keyword value, you need to have a way of describing the intermediary state. For lengths, intermediary states can usually be described via acalc()function. 10% of the transition from 50px to 20em iscalc(0.9*50px + 0.1*20em). So the most generic approach to supporting transitions with keywords would be to allow the keywords to be used incalc(), with a real-time substitution of the current computed value that the keyword would create.Sure, there are edge cases where the performance would inevitably be horrible (e.g., if you are transitioning to/from
autoat the same time you are also changing things that would cause the current computed value ofautoto change), but that shouldn't be reason to prevent its use in more sensible cases.nico3333fr commentedon Oct 21, 2016
@keithjgrant yes, this is a real problem.
For the moment, we set up transitions on max-height value (using magic numbers for values, max-height = enough_and_pray_the_content_is_not_that_tall), and if you want to do it including accessibility pov, you have to transition on visibility (as display is not possible, cf this accordion https://a11y.nicolas-hoffmann.net/accordion/?animated=1 ) with a delay... really complicated for something that should be simple. :)
rickyp-ms commentedon Nov 3, 2016
Looking around the web, you can easily see that this is a constant problem for developers. Velocity.js even notes this specific missing feature in its first paragraph of why it exists (https://fabric.io/blog/introducing-the-velocityreact-library). I can probably give a ton of references (on request) of developers rendering an element, measuring it, setting it's height to 0 then animating to that specific height. Even JQueryUI does a similar measurement technique just to get this to work and it's been around for almost a decade now.
What can we do as the larger software development community to petition this change and make sure it gets in on the next iteration?
Do we need to have more people come here and upvote this bug? Do we need to email a specific individual? Let us know so we can let you know what we need most.
k2snowman69 commentedon Dec 5, 2016
I too am curious what we (the web programming community in general) can do to petition a change in the spec... I've got a few issues I know I could get quite a few people backing.
birtles commentedon Dec 5, 2016
I caught up with @dbaron about this recently and it seems a likely way forward is to make 'auto' into a computed value. As well as enabling animation with
auto, that would also make it possible to write expressions likecalc(auto + 10px). While that might not be trivial to implement, since there is interest from authors' and, I believe, browser vendors, it seems promising.(One way to push this forward would be to submit a patch to one of the open-source browsers for this. Once you've proven the technical feasibility of this, it's easier to argue for it to be added to the spec.)
dbaron commentedon Dec 5, 2016
autois already a computed value; the thing that needs to happen is adding support forautotocalc().k2snowman69 commentedon Dec 6, 2016
Awesome I'll start looking into it using Firefox since I think theirs would be the easiest source code to get a hold of. That said, it may take me a while due to lack of cpu resources (my computer is a 2 core 2.4ghz processor... it's going to take a while to build).
nilssolanki commentedon Dec 13, 2016
Thank you very much for bringing this up. We currently work around this by reading out an elements
scrollHeightand transitioning to that height, only to revert the element height toautoontransitionend. So making this a platform feature would be fantastic.craigfrancis commentedon Dec 13, 2016
It has been suggested that we use
max-height: max-content.But trying to get the browsers to implement either has been very difficult, as the CSS animations are typically done between 2 known values, which is why animation usually needs to be done with something like
max-height: 500em.As an aside (and for some of the background on this), I've been trying to get browsers to support auto-height
<iframes>and<textarea>s, which will work in pretty much the same way:https://github.com/craigfrancis/iframe-height
https://discourse.wicg.io/t/feature-request-animating-max-height-height-based-on-content/1403
Jakobud commentedon Dec 13, 2016
+1. Not being able to transition on
height: autoanddisplay: <anything!>(You can't even do atransition-delayondisplay) has always been a big pain.k2snowman69 commentedon Dec 14, 2016
Just FYI I'm currently out of the country and I'm also checking with my legal department to see if this is something I'm allowed to do due to where I work (non-compete and helping competitor issues). I'll be back in town on the 20th.
@nilssolanki That's the same trick we're using and it's just annoying.
@Jakobud I would say animating display is a bit out of the bounds of this request and may also have a few edge cases that would be interesting (animating inline to block?).
k2snowman69 commentedon Jan 13, 2017
My legal department has come back to me informing me that I'm unable to currently work on this request due to non-compete legal stuff. That said, I'll have to (frustratingly) recuse myself of any code writing for this feature.
Just to note, I also asked a google groups question here if anyone is interested in taking this up. It should give a basic guide to how I was planning on tackling the problem.
https://groups.google.com/forum/#!searchin/mozilla.dev.tech.layout/auto%7Csort:relevance/mozilla.dev.tech.layout/fFuJqwXvu2I/6_mt7HmhDAAJ
danegraphics commentedon Jun 26, 2017
Just want to make sure this is still happening.
This is actually rather important because, yes, we can precalculate a value for height and other properties using javascript and things like
document.getElementById(elementID).scrollHeight+'px', but sometimes we need the property to have an auto value after the animation/transition so that we can make changes inside and around the element that the element will respond to appropriately.For example, I have an element that transitions from a height of 0 to a height of 'auto'. After the transition is completed I want the height of the element to be able to adjust correctly to the changing elements inside of it without me having to recalculate it myself.
So if it really is just adding
autocompatibility to thecalc()function, as @dbaron has mentioned, is someone working on that, and if not, how would one do so?k2snowman69 commentedon Jun 26, 2017
To my knowledge no one has picked up this work and I'm still barred due to legal constraints. But if you download the source code and read the conversation here:
https://groups.google.com/forum/#!searchin/mozilla.dev.tech.layout/auto%7Csort:relevance/mozilla.dev.tech.layout/fFuJqwXvu2I/6_mt7HmhDAAJ
It should give you a few locations to pinpoint where you would need to make the changes you need. Not sure if those are all of them but it should give you a starting point for learning the code base.
Good luck, I hope you do take this up because it would be an amazing addition!
184 remaining items
martinthomson commentedon May 20, 2024
Can you do
calc( ( calc-size(min-content) + calc-size(max-content) ) / 2 )? Why not?dbaron commentedon May 21, 2024
No.
In terms of the spec (defining that you can't do it), you can't because
calc-size()is not defined to be a math function that's valid inside ofcalc(). It's defined as a separate toplevel production (<calc-size>) that needs to be specifically allowed by each property that accepts it. The only other place that accepts it is that it is accepted recursively as the basis (but not as the calculation).In terms of rationale (why shouldn't it be allowed), it's because many layout algorithms in CSS depend not just on the mathematical values of these properties but also have conditionals that branch on what are essentially type checks on the value. This alternative is a bit less general than allowing full
calc()math on intrinsic sizing keywords, but avoids the need to go and rewrite a bunch of existing layout algorithms (tables, flex, grid, and I think also multicol) to avoid branches. This rationale is discussed a bit in the section on Allowing intrinsic sizing keywords inside of calc() in the explainer (a subsection of "Considered alternatives"), and also the following paragraph from earlier in the explainer:LeaVerou commentedon May 21, 2024
I wonder if it would be more web-compatible to only transition between these values when a
width/heighttransition is explicitly requested, rather than when implicitly included viaall(either explicit or omitted).dbaron commentedon Jul 17, 2024
So looking at the sites that were problematic at the time (today there would likely be new sites showing up as problematic in addition to old ones dropping off the list):
transition-property: width, height. Today the site has been redesigned and no longer has the part that had the problem.transition-property: heighttransition-property: paddingwhich wouldn't have triggered the problem in the first place. I can't get an appropriately-aged site in https://web.archive.org/ to load.transition-property: allSo I don't think that helps sufficiently. (Remember also that this is from a sample of loading homepages without any user interaction, which in general doesn't trigger that much animation compared to the animation that results from user interactions.)
dbaron commentedon Jul 23, 2024
I've been looking at making
calc-size()andinterpolate-sizework forgrid-template-rowsandgrid-template-columns(in the places where they accept sizing keywords). One thing I've been looking at is the grid layout algorithm: in particular, whether track sizes are considered in the Initialize Track Sizes step or whether they're considered in the Resolve Intrinsic Track Sizes step (in particular, the Size tracks to fit non-spanning items and Increase sizes to accommodate spanning items crossing content-sized tracks substeps).My current understanding of the algorithm is (when adding support for these new things) the base sizes set up in the "Initialize Track Sizes" step don't really matter, and there's no need to adjust what happens in which step beyond being clear that
calc-size(min-content, ...)is handled in the same place asmin-content. I think the only thing that needs to be adjusted is that the full expression needs to be handled in the substeps of the "Resolve Intrinsic Track Sizes" step. But I don't think anything needs to be moved around.I'd appreciate if someone who knows grid could double-check this, though.
Edit: I realize the above is wrong because it doesn't consider tracks that have no items! So I think "Initialize Track Sizes" does need to be adjusted.
Add calc-size to productions for width/height and min/max-width/height.
[css-sizing] Add calc-size to productions for width/height and min/ma…
bramus commentedon Feb 4, 2025
Closing, as this is covered by https://drafts.csswg.org/css-values-5/#interpolate-size and https://drafts.csswg.org/css-values-5/#calc-size