Wednesday, June 30th, 2010

jQuery.fn.webkitTransform: bananas on the skew-whiff

Category: CSS, JavaScript, jQuery


Franz Enzenhofer has created a nice new webkitTransform plugin that helps you manage transforms and state.

Franz tells us more:

With jQuery.css you can’t easily change the webkitTransform CSS because webkitTransform is not your average CSS.

If in one step you add .css('-webkit-transform', "rotate(20deg)") and in the next step .css('-webkit-transform', "scale(2.0)") the rotate value gets reset, as you have rewritten the complete -webkit-transform CSS value.

You could use the WebKitCSSMatrix javascript element, but it’s currently buggy, not consistently implemented and a pain to use.

Additionally you can’t just retrieve the ‘-webkit-transform’ css with .css(‘-webkit-transform’) as this just gives a matrix code.

Our goal with webkitTransform() was to fix this problem. With it, every element you assign webkit-transform css with can be edited in a simple way, without resetting every other -webkit-transform values.

Posted by Dion Almaer at 7:01 am

4 rating from 5 votes


Comments feed TrackBack URI

Could you get Franz to elaborate on bugs he’s found WebKitCSSMatrix. Specifically, it’s important that bugs are filed against WebKit on so they can be fixed!

Comment by graouts — June 30, 2010

Nice. Works perfectly in Opera.

Comment by movax — June 30, 2010

Firefox as well, except rotateX and rotateY (what the hell are those even supposed to do? Judging from past appearance, I’d guess that they are redundant secondary scaleY and scaleX properties).

Try for a better name next time ;)

Comment by hansschmucker — June 30, 2010

EXperience, not appearance :)

Comment by hansschmucker — June 30, 2010

I’ve written a plug-in that does this cross-browser (including IE) with animations.

Comment by Heygrady — June 30, 2010

For added fun (on WebKit), go into the console and run…

$(‘#banana’).css(‘-webkit-transition’,'all 1000ms’);

…before you start playing with sliders.

Comment by RwwL — June 30, 2010

Regarding the apparent difficulty of handling CSS transforms in DOM, it will almost always make more sense to just switch classNames instead. Every week or two something comes along like this where difficulty may be high but utility is so low as to make the solution questionable at best. Obviously changing transforms in the DOM has the utility of doing so explicitly on a preview (as this demonstrates), but apart from editing user content where there is no access to CSS files and the changes haven’t yet been committed, there is scarcely reason to ever do this.


RotateX and rotateY rotate on different axes (rotate is on axis Z). With a flat element, of course it does look like scaleX and scaleY (except that it flips the element after a certain point rather than ending at zero width), but with hypothetical three dimensional elements, it would allow free rotation in three dimensional space.

Comment by eyelidlessness — June 30, 2010

@hansschmucker “EXperience, not appearance”

This actually sounds like a great mantra for selling progressive enhancement to clients/management.

Comment by furf — June 30, 2010

Ah, very nice. I released a similar patch in Aug 2009 because I was also annoyed with the fact that all your transform functions are packed into a single property and they tend to blow each other away. My plugin also patches rotate and scale so they can be animated independently with jQuery.animate().

I supported rotate and scale independently, but I never did get around to adding support for the other transform functions. Now maybe I won’t have to. :)

Comment by zachstronaut — July 6, 2010

This is awesome, but I wish Chrome (or webkit) would sort out the aliasing – it’s damn ugly (especially on the reflection).

Comment by Skilldrick — July 6, 2010

Leave a comment

You must be logged in to post a comment.