write jQuery.fn.transition - support for hw accelerated css transitions

[paulirish]

This is basically an alternate version of $.fn.animate but it uses CSS3 transitions where available. This gives it the major benefit of hardware acceleration which is key for high performance.

The API will probably match the api for css transitions pretty closely.

Users would use transition() instead of animate() when possible to get added performance and animation fidelity.

There are a few similar implementations that should be considered as inspiration:

• http://developer.yahoo.com/yui/3/transition/
• http://scripty2.com/hardware-acceleration/ https://github.com/madrobby/scripty2/blob/master/src/effects/css_transitions.js
• https://github.com/sproutcore/sproutcore/tree/master/frameworks/animation/

John Resig has said this is a no-brainer for jQuery Mobile, and he's welcoming patches. It should probably go into jQuery core as well.

---

edit 2012.02: link to addy's post about it: http://addyosmani.com/blog/css3transitions-jquery/

[paulirish]

hah. it looks like jQtouch has something similar. http://code.google.com/p/jqtouch/source/browse/trunk/jqtouch/jqtouch.transitions.js

[jakearchibald]

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

Interestingly uses transform to animate top/left etc, then swaps in the real CSS values and clears the transform once the animation is complete. Some browsers allow sub-pixel positioning (like Flash) with transform, so the animation is a lot smoother, not to mention the HW acceleration.

[gblazex]

@paul - Unfortunately it uses browser sniffing ($.browser.safari).

[paulirish]

browser sniffing is kind of okay (assuming it'd be done right).. there is no way to feature detect hardware acceleration. I've asked the FF and Chrome engineers about this myself. It can't be done. :)

[gblazex]

You don't need to test hardware acceleration, only CSS transitions, because this is what the code is essentially doing (with UA sniffing). Serving some content to a browser based on what it tells about itself is like the bank paying me 1000$ because I swear I'm Bill Gates. A decent application should behave like a bank in real life: "Prove it, or gtfo" XD

[jakearchibald]

It's worth considering just enhancing animate() rather than making a separate function.

On the downside, the user needs to understand of combinations of params prevent CSS transitions being used (certain easing functions, step etc). However, it means users could drop the new version of jQuery on existing sites and see an improvement straight away.

[paulirish]

@jake,
Yeah definitely. This is the approach that Sproutcore took. It's a lot more code but there is huge user benefit.

Adding a new method is similar to what we did with delegate() .. trying to fix the limitations of live().

[paulirish]

remy sharp did a $.fn.tween built on transitions:
https://gist.github.com/349069

[louisremi]

I'm working on a patch allowing jQuery to use transition in its animation mechanism.

It is built in $.fn.animate and $.fn.stop (just like jQuery-animate-enhanced) but it is not just a complete rewrite of $.fn.animate and $.fn.stop (unlike jQuery-animate-enhanced).
Special care has been taken in minimizing impact on performance for browsers not supporting transitions.

This patch is intended to be proposed for merge into jQuery core. Since more testing needs to be done and I'm looking for feedback before opening a pull request, it's currently only available as a plugin: https://github.com/lrbabe/jquery.transition.js

I hope you'll like it,

Louis-Rémi

[cbosco]

While I see a use for enhancing to CSS3 transitions where supported, I think a plugin like this would provide incentive to keep states and animations in JavaScript when they should really live in CSS. I think I see this paradigm shift as equal or more important than the performance gain we're also seeing from CSS transitions

[paulirish]

@cbosco what are you suggesting.. code/API-wise?

[cbosco]

@paulirish: unfortunately I basically pointed out a problem without a solution (in my opinion)

I like keeping the separation because I think the future is CSS3 transitions, and would rather try and adopt the CSS approach as early as possible, rather than using a plugin that would wrap modern/legacy in a legacy approach.

It's sort of analogous to IE CSS hacks, where I've grown to really like the html5boilerplate approach in using conditional IE comments/class names to isolate backward compatibility for pruning in the future.

But I'm interested to see where this goes because the more I think about it this could be great for a pretty common use case where you do navigation transitions that are dependent on window dimension/callbacks/app logic, because those are pretty much coupled to the app's scripts anyway, and the performance benefit could be huge

Curious if what galambalazs is suggesting doesn't accomplish this over browser detect. I guess supporting CSS transitions don't necessarily mean you support HW acceleration?

[gblazex]

@cbosco - Of course it doesn't. It's not required by the CSS3 specification.

[louisremi]

@cbosco: this paradigm shift is important indeed, but there are some cases where you'll need to use some logic to create your transition.

I might want to calculate the duration of my transition or use a random one, same goes for the timing-function and delay.

[rstacruz]

I wrote a plugin that does the exact thing described here: http://ricostacruz.com/jquery.transit . I know this is a dead thread, but is there anywhere on the web where this jQuery feature request is being tracked?

It's worth considering just enhancing animate() rather than making a separate function.

One thing to consider here is that CSS transitions will not work exactly like $.fn.animate() 100%. Custom easing will not work, for instance. Also, I don't think there'd be a way to stop CSS transitions for $.fn.stop(). I think it'd be "leaky" abstraction to override $.fn.animate() to be CSS-transitions-compatible.