Ticket #4214 (closed feature: wontfix)
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: | |
| Blocking: | Blocked by: |
Description
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
Change History
comment:1 Changed 4 years ago by dantman
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.
comment:2 Changed 3 years ago by zachstronaut
dantman:
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?
comment:3 Changed 3 years ago by SlexAxton
- Priority changed from minor to low
- Status changed from new to open
- Component changed from core to css
- Milestone changed from 1.4 to 1.5
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.
comment:4 Changed 3 years ago by addyosmani
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.
comment:5 Changed 2 years ago by john
- Status changed from open to closed
- Resolution set to wontfix
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. https://github.com/brandonaaron/jquery-cssHooks
Please follow the bug reporting guidlines and use jsFiddle when providing test cases and demonstrations instead of pasting the code in the ticket.

