Bug Tracker

Ticket #4171 (closed feature: plugin)

Opened 6 years ago

Last modified 3 years ago

Allow animation of CSS Transform Properties

Reported by: zachstronaut Owned by:
Priority: low Milestone: 1.next
Component: effects Version: 1.6.1
Keywords: css,transform,animate,animation,1.7-discuss Cc:
Blocking: Blocked by:

Description (last modified by lrbabe) (diff)

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);

});

Change History

comment:1 Changed 6 years ago by 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.

comment:2 Changed 4 years ago by ajpiano

  • Status changed from new to closed
  • Resolution set to wontfix

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.

comment:3 Changed 4 years ago by john

  • Status changed from closed to reopened
  • Version changed from 1.3.1 to 1.6.1
  • Resolution wontfix deleted
  • Milestone changed from 1.3.2 to 1.next

Re-opening for 1.7 discussion.

comment:4 Changed 4 years ago by john

  • Keywords css,transform,animate,animation,1.7-discuss added; css,transform,animate,animation removed

Nominating ticket for 1.7 discussion.

comment:5 Changed 4 years ago by 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.

comment:6 Changed 4 years ago by rwaldron

  • Description modified (diff)

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

comment:7 Changed 4 years ago by jaubourg

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

comment:8 Changed 4 years ago by ajpiano

  • Description modified (diff)

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

comment:9 Changed 4 years ago by timmywil

  • Description modified (diff)

-1, cssHooks

comment:10 Changed 4 years ago by 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

comment:11 Changed 4 years ago by addyosmani

  • Description modified (diff)

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

comment:12 Changed 4 years ago by danheberden

  • Description modified (diff)

-1

comment:13 follow-up: ↓ 25 Changed 4 years ago by paul.irish

  • Description modified (diff)

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

comment:14 Changed 4 years ago by timmywil

  • Status changed from reopened to open

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.

comment:15 Changed 4 years ago by john

  • Description modified (diff)

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

comment:16 Changed 4 years ago by scott.gonzalez

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

comment:17 Changed 4 years ago by addyosmani

-1

comment:18 Changed 4 years ago by jzaefferer

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

comment:19 Changed 4 years ago by lrbabe

  • Description modified (diff)

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

comment:20 Changed 4 years ago by rwaldron

  • Priority changed from major to low
  • Status changed from open to closed
  • Resolution set to wontfix
  • Milestone changed from 1.next to 1.7

Closing per 1.7 roadmap meeting resolution

comment:21 Changed 4 years ago by rwaldron

  • Status changed from closed to reopened
  • Resolution wontfix deleted
  • Milestone changed from 1.7 to 1.next

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.

comment:22 Changed 4 years ago by 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 .animate(). They may prove useful here. Here's to hoping we can actually land something in 1.next for it :)

Version 0, edited 4 years ago by addyosmani (next)

comment:23 Changed 4 years ago by timmywil

  • Status changed from reopened to open

comment:24 Changed 3 years ago by john

  • Status changed from open to closed
  • Resolution set to plugin

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

comment:25 in reply to: ↑ 13 Changed 3 years ago by 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.

comment:26 Changed 3 years ago by CaptainN@…

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/

Note: See TracTickets for help on using tickets.