I agree that animating width/height auto should probably work "out of the box," but I am not quite sure that this patch will do that job - or if any patch could do that job accurately.

Ditto. In fact, CSS Transitions currently are pretty shit when going from 'auto' to a value or vice versa.

This should work.. but its tricky to.

The patch here won't cut it.

But I'd like this feature fo sho

Ater talking with Paul a bit about this I've come up with a slightly different version of my proposed patch. Instead of appending the cloned element to the body I insert it before itself.

if ( val === "auto" && ( name === "height" || name === "width" ) ){
     var $temp = jQuery(self).clone().css(name,"auto").insertBefore(self);
     val = $temp.css(prop);
     $temp.remove();
}

I think this is a pretty solid solution. Again, it's open to criticism if someone can find the flaw in obtaining the intended CSS attributes value this way.

Thoughts?

An example of the implementation in a separate function, not in the core as proposed: http://jsfiddle.net/darcyclarke/JNRpK/21/

This seems like a cool feature/enhancement, but it really seems like one of those that you'll need to take the reigns on and create a pull request along with several unit tests showing it works.

I'm a little worried about a flash of weird content, or an accidental rerunning of script elements (by injecting them again), or more commonly just performance hits.

I'd love to see it work though.

Using jQuery 1.5.2. Not only does animating the height/width of an element to "auto" not work, but it causes a JavaScript error in IE 7 and IE 8. I don't mind that it doesn't work (I'm really just passing it through as a dummy value), but it'd be nice if it didn't throw an error.

Could it work? It doesn't seem like it'd be too hard to figure out what the, e.g., height of an element would be if no styles were applied to it modifying its height, which is exactly what the "auto" property is. Am I wrong?

patch and unit tests here: https://github.com/jquery/jquery/pull/408

From the pull:

'Correct me if I'm wrong, but won't this only work if there are uncomputed styles set that we can fall back to? For instance, the default value of width is "auto" and unless a width is set somewhere in the user css that isn't auto, we still can't do the animation.'

The main issue I see is that even the best browsers will return "auto" sometimes for _computed_ styles, so I'm not sure we can fully support animating auto.

''(sorry, I just noticed your comment after answering on Github)''

The problem of the "auto" value returned for computed style is also present in other part of the effects code, see how jQuery.fx.cur() deals with it.

This didn't prevent us from writing the effect component ;-)

Having ''almost complete'' support for "auto" and "" is better than no support at all.

Tabling for 1.8 discussion. Some of the team, including myself, still have concerns about adding support for these values.

The PR is now here: https://github.com/jquery/jquery/pull/515

additional info on why this patch is harmless has been included

-1, This requires a bit more than the patch implies, no? Animating to auto width would mean the cloned element can't just be appended to the body as the patch implies. I could be persuaded if there was a simple enough way to do this.

+0, If there is an easy, short way, then do it. Else, document it and move on.

+0, If this doesn't take a lot of bytes I'm fer it, otherwise I'm agin' it. Animating things set to auto naturally raises a flag with me, sorry that some people expect it to work somehow.

-1

-1

@mikesherov My current patch has nothing to do with the code posted when the bug was opened. It doesn't involve cloning elements anymore, see https://github.com/jquery/jquery/pull/515

@jaubourg The proposed patch adds exactly 58B to jquery minified and compressed

It saddens me to see some "-1" without any explanation. I wish I could understand and maybe answer your concerns.