Skip to main content

Bug Tracker

Side navigation

#4214 closed feature (wontfix)

Opened February 23, 2009 01:43AM UTC

Closed April 16, 2011 09:26PM UTC

Last modified March 14, 2012 03:27PM UTC

Normalize support for CSS Transforms via css() method

Reported by: zachstronaut Owned by:
Priority: low Milestone:
Component: css Version: 1.3.2
Keywords: css,transform Cc:
Blocked by: Blocking:

jQuery normalizes CSS opacity across browsers, I thought it could also normalize support for CSS Transforms so that the end user didn't have to make css() calls for both WebkitTransform and MozTransform properties.

Specificically, rather than calling for example:

$('#foo').css('MozTransform', 'rotate(45deg)');

$('#foo').css('WebkitTransform', 'rotate(45deg)');

The user could simply call:

$('#foo').css('transform', 'rotate(45deg)');

Implementing these change was relatively easy using jQuery.props and a function to discover the correct property. It is also forward compatible for when 'transform' is no longer a CSS3 draft property.

jQuery.attr() -- which is called from jQuery.prototype.css() -- already uses jQuery.props to map some properties to other values.

jQuery.curCSS() on the other hand manually does some mapping with 'float' but doesn't use jQuery.props. If we do *not* change jQuery.curCSS() to also use jQuery.props the same way jQuery.attr() does, then the side effect is that CSS Transforms can be *set* cross-browsers with jQuery.prototype.css() but you would not be able to *get* them.

I've attached a patch against jquery.js 1.3.2

Attachments (1)
  • jquery.diff (1.7 KB) - added by zachstronaut February 23, 2009 01:43AM UTC.
Change History (5)

Changed March 08, 2009 10:44AM UTC by dantman comment:1

jQuery doesn't accept additions that don't work in 100% of the browsers it supports. My suggestion to support similar support for borderRadius and the moz/webkit versions was rejected for that same reason.

I have plans to write a an improvement to jQuery that lets plugins extend jQuery to support obscure css properties like these. That improvement is waiting on John's refactoring of the $.curCSS and $.attr functions.

Once that's in jQuery and I would be happy to include support for transform. However, I won't be using that patch, the way it uses a loop all the time isn't that great in comparison to the .support checks I am using in my borderRadius code.

At the same time, a side note. But IE supports transformations as well using filter. I wouldn't say that is enough to say full compatibility can be made (Opera doesn't have support, and -moz-transform is only FF3.1 and not public yet.) As well it would take a considerable amount of parsing to support transform to filter compatibility. But it is something that a plugin could go ahead and support once my .css extensibility is added.

Changed November 08, 2010 02:49AM UTC by zachstronaut comment:2


Is this new "cssHooks" thing in 1.4.3 being used to do the cross browser opacity what you were referring to when you mentioned John's refactoring of $.curCSS and $.attr?

Looking at this code I'm thinking I could use cssHooks to add custom support for transforms instead of monkey patching it in?

Changed November 10, 2010 04:37PM UTC by SlexAxton comment:3

component: corecss
milestone: 1.41.5
priority: minorlow
status: newopen

I think cross-browser css3 support is something that jQuery should eventually address specifically. (much like scripty2, etc). I think it's a good feature request.

Changed November 19, 2010 07:38PM UTC by addyosmani comment:4

I agree that this is a good feature request, but would echo previous comments in saying that cssHooks is probably the best place to start in terms of looking at ready-implementations that could be part-considered for integration into core rather than re-writing this from scratch.

Changed April 16, 2011 09:26PM UTC by john comment:5

resolution: → wontfix
status: openclosed

This isn't something that we're going to do in jQuery core, although there are already plugins that do it, using the new CSS Hooks.