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
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
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.