Cross-browser jQuery transition animation?

Question

Are there any jQuery 1.3 animation-transitions that work in both Firefox 3 and IE7?

I have a table with multiple table rows (25 or more), with some of the rows starting hidden (these rows all share a common class; in this example, it's ".hidden"). In the table header is a "Show more" link which is bound via .click() to a function that will show the hidden rows, and then change the "Show more" to "Show less" and change the .click() to a function that does the opposite.

In each .click() function, there is a line like

$(this).parents("tbody").children("tr.hidden").show();

with .show() replaced with .hide() for the "Show less" function.

However, if I try to replace the .show()/.hide() with .fadeIn()/.fadeOut(), IE renders it as almost identical to .show()/.hide() except it takes a minute for .hide() to take effect. No real animation there. Inferior in IE, although it works great Firefox.

If I try to use .slideDown()/.slideUp(), it is similarly janky in IE, being almost identical to .show()/.hide() except with a weird pulsing effect just after completing the transition. Firefox 3 chokes on it as well, apparently just forgetting the row width of the table rows being shown and making the whole thing look terrible.

So do animations just suck in IE7? Is there any way to have a graceful and smooth transition in this case that will work in both browsers?

Answer 1

According to jQuery's compatibility page this sort of thing is a bug and should be reported.

Answer 2

Often times having multiple, concurrent animations can be hard for IE. The Javascript engine just isn't anywhere near Safari or Firefox or Chrome. This goes for IE6 and IE7. I have not worked with IE8 yet.

One thing that can help a little, is having static heights set on the elements you're trying to animate. From a CSS/layout perspective, this usually isn't ideal, but... this allows jQuery to skip the task of having to first compute the height of each element before it animates the element's height.

In general, you might approach animations the same way you would a SLR camera. (Stick with me here). If you're trying to take rapid-fire shots of a sporting event, any photographer would recommend setting up the focus, ISO, and shutter speed ahead of time. This way the camera doesn't have to compute all this stuff between each shot and you can just hold down the shutter button and click-click-click-click. A-Team style.

Anyway, when it comes to animations, try thinking of things the javascript needs to compute for the animation to happen. Opacity, height, computed height (element width + border + padding), screen position, are all good places to start.

Often times, you can actually see what jQuery is adding into the DOM as animations start (using Firebug). Like, on an opacity animation, you can see the style="opacity:1;" being added right before the count down to 0 begins.

Answer 3

I wouldn't be overly explicit when speaking about performances across browsers. Quite frankly, I've seen some heavy JS animations that will make webkit cry, while FF and IE handle it pretty well.

You'll just have to consider that browsers have different CSS and JS implementations that sometime make it hard to point a finger at the culprit behind your sluggish performances.

Take IE. If you have a block level element 4000x4000 and a 2x2 transparent gif set to repeat, each time you'd, god forbid, move the element IE will redraw the 2x2 gif and calculate the alpha for each one, 2000 times over. FF either caches the background or has a dramatically different redraw, in either case the performances are incomparable. It didn't say that in the manual, you just have to be careful how and what your doing.