Allow animation of CSS Transform Properties

[zachstronaut]

WebKit/Safari and Firefox 3.1+ support CSS Transformations including skew, rotate, and scale. The following jQuery animation code does not work as expected in Safari:

$('p').click(function () {

$(this).animate({WebkitTransform: 'rotate(15deg)'}, 1000);

});

For Firefox 3.1+ the property is actually MozTransform instead. Ideally, jQuery would internally make the distinction between WebkitTransform and MozTransform and animating these CSS properties could simply be invoked with code such as:

$('p').click(function () {

$(this).animate({transform: 'rotate(15deg)'}, 1000);

});

[dantman]

jQuery won't add support for this since it doesn't work cross browser.

I have plans to improve jQuery to support extension of .css(); after I code that I'll be making an extension to add borderRadius support, and potentially transform support. I'll probably also end up setting up support for transform animation.

Note that transform isn't something very easy to animate, there are a number of possible transformation types (matrix: rotate, translate, scale, skew) and just like in matrix transformations these build on top of each other in complex ways.

Animating 'rotate(25deg)' to something like 'transform(25px,25px) rotate(50deg)' might not be to simple. I'll have to do some testing.

[ajpiano]

This canm now be accomplished with a plugin that leverages jQuery's new cssHooks implementation. That is how jQuery plans to support CSS3 going forward, rather than inclusion in core.

[john]

Re-opening for 1.7 discussion.

[john]

Nominating ticket for 1.7 discussion.

[dmethvin]

+0, Needs to be part of an overall .animate() rewrite with CSS3 animations in mind. Not sure if this is the right time to do it.

[Rick Waldron]

+0, Seems like a lot of code. Could this begin life as a plugin?

[jaubourg]

+0, I think we should simply cssHook these properties (without the transform key, let's use "rotate" and "scale" directly)

[ajpiano]

-1, Should use cssHooks - moreover, how does it even make sense to "animate" the property that defines a CSS transform...

[timmywil]

-1, cssHooks

[zachstronaut]

Why does animating the CSS 'width' property belong in jQuery core but animating the CSS 'transform' property should be cssHooks? This sounds completely arbitrary to me. It also seems very shortsighted. CSS Transforms are now supported by IE9+, Opera, Firefox 3.5+, Chrome, and Safari, and they are exactly the kind of thing that cutting edge web developers and designers are going to want to include and to animate in their designs.

Also, CSS Transitions and Animations will soon make redundant all of jQuery's animation functionality. If you're going to exclude support for some CSS properties in jQuery core, maybe all of jQuery animation should be removed from core and stand alone as a plugin to reduce the weight of jQuery.

The demand for CSS Transform support is going to grow exponentially, so it is hard to argue for it being excluded from jQuery core on grounds that it is too niche. If you want to argue that it is acceptable for people to include it as a plugin, then why not make all of jQuery animate a plugin for those of us who don't need any of the animate functionality on some projects.

@ajpiano How does it not make sense to animate a CSS transform? I do it all the time with my jQuery patch that enables this: ​http://www.zachstronaut.com/posts/2009/08/07/jquery-animate-css-rotate-scale.html

[addyosmani]

-1, only because as per dmethvin this should probably be done as part of a wider re-write of .animate() to use CSS3 transitions, whether addressed on this roadmap or the next.

[danheberden]

-1

[paul.irish]

+0, I really want this functionality and want it in jQuery.. but it's a poor choice to use DOM based animation on transforms. They should always be animated with transitions.

Dunno if there's a ticket for moving animate() to transitions but that's the one that needs to happen.

[timmywil]

I agree with paul and adam that DOM based animation shouldn't be used on transforms, but I don't think it will be possible to convert animate to transitions. IMHO, javascript animations should be done with javascript, hence the existence of requestAnimationFrame. They will always be needed in every browser even if not in every situation.

I foresee far too many collisions, as well as supremely bloated code, if we tried to do css transitions for the situations where it would work. The only benefit I see in adding css transitions with javascript is so you don't have to worry about all of the different prefixes, but I think that's really more a job for scss, sass, a plugin, or a separate function from animate. Not a good enough reason to switch.

[john]

+0, I think most of this can be handled by plugins (although, I admit, it would be nice to have some of this API integrated into our own).

[scottgonzalez]

-1, This should be possible, but outside of core. I actually plan on tackling this in jQuery UI.

[addyosmani]

-1

[jzaefferer]

-1, eventually jQuery should support CSS transforms, but not this way

[lrbabe]

For the record, we already have a cssHooks that works fairly well: ​https://github.com/louisremi/jquery.transform.js

[Rick Waldron]

Closing per 1.7 roadmap meeting resolution

[Rick Waldron]

Yehuda just gave a compelling presentation at TXJS that addressed the hope that jQuery might take this on. I'm re-opening for 1.next discussion.

[addyosmani]

I previously wrote about this in the pre-vote version of the roadmap spreadsheet, but I would seriously consider reviewing lrbabe's work on transforms (and transitions) with .animate(). They may prove useful here. Here's to hoping we can actually land something in 1.next for it :)

[john]

This isn't something that we're going to fix, per discussion in the jQuery 1.7 roadmap meeting: ​http://docs.jquery.com/Won%27t_Fix

[zachstronaut]

Of course, you're right Paul. The irony is that all the browsers that support CSS transitions/animations will also support things like querySelectorAll(), addEventListener(), etc. and are across the board much more uniform. Much of jQuery suddenly could be paired down into many, many fewer lines of code... and some of the jQuery APIs become obsolete entirely. Looking towards future compatibility, here's where I see the real JS library needs:

-object/class management (things like $.extend or other patterns) -dynamic animations (although in many, many cases this should be being done with CSS transitions and animations that are triggered by toggling classes) -simple selecting and modifying attributes and classes on DOM nodes (see above) -custom event firing and listening -UI widgets (with preference towards widgets that are smart enough to work on desktop and mobile i.e. they use transforms, transitions, and animations and have different styles depending on css media queries against screen size)

Zach

Replying to paul.irish:

+0, I really want this functionality and want it in jQuery.. but it's a poor choice to use DOM based animation on transforms. They should always be animated with transitions.

Dunno if there's a ticket for moving animate() to transitions but that's the one that needs to happen.

[[email protected]…]

There is already an implementation that I didn't see noted in this thread - it answers the quesion of whether it can be done in a plugin:

​http://playground.benbarnett.net/jquery-animate-enhanced/