Css -webkit-transistion, transition not set under Chrome

[nathan.patry@…]

When setting transition using a litteral object such as :

var style = {
    "-webkit-transition": "-webkit-transform 1200ms ease",
    "transition": "transform 1200ms ease"
};

$('#test').css(style);

And animating it, with a transformation such as :

var rotation = {
    "-webkit-transform": "rotate3d(0, 1, 0, 45deg)",
    "transform": "rotate3d(0, 1, 0, 45deg)"
}

$('#test').css(style).css(rotation);

The animation actually occurs under Firefox (v. 27.0.1), but there is no animation (but the div is correctly rotated) under Chrome (version 33.0.1750.117 m).

See a JSFiddle example ​here.

It worked with jQuery 2.0.3, but I can't tell for further versions.

[anonymous]

The actual jQuery version is 2.1.0

[nathan.patry@…]

I made a mistake, the problem occurs on jQuery 2.1.0, not 1.11

[dmethvin]

It seems like transform doesn't work but all does: ​http://jsfiddle.net/dmethvin/7F9zR/5/

Something definitely changed though, it used to work: ​http://jsfiddle.net/dmethvin/7F9zR/6/

BTW, Chrome no longer requires prefixing, but caniuse.com says it does. That may be a clue? Maybe our auto-prefix algorithm is doing something wrong. ​http://caniuse.com/#search=transform ​http://jsfiddle.net/dmethvin/7F9zR/4/

[m_gol]

Chrome doesn't require prefixing transition but does require prefixing transform. I'll look into that.

[m_gol]

OK, it'll be a hard one. Normally, the operation goes as follows:

1. The "-webkit-transition": "-webkit-transform 1200ms ease" rule gets set normally
2. The "transition": "transform 1200ms ease" rule gets applied twice: first prefixed as "-webkit-transition": "transform 1200ms ease" and then unprefixed. In both those cases the rule gets discarded by Chrome via the regular CSS cascade as Chrome doesn't recognize unprefixed transform.

This commit:
​https://github.com/jquery/jquery/commit/24e587929f62428e1959b10aace6dc4fd65ab397
introduced resetting the style property to an empty string before setting it to the final value. Unfortunately, this makes the above mechanism fail.

[m_gol]

We could check if the style is not empty after assigning; then it means the browser didn't accept the rule and we should fall back to the previous one.

PR incoming.

[m_gol]

PR: ​https://github.com/jquery/jquery/pull/1532

[Michał Gołębiowski]

Css: Revert 24e587929f62428e1959b10aace6dc4fd65ab397

The workaround to be able to change !important styles broke the browser keeping the old CSS value if the new one was rejected. Patching it would involve a significant perf hit (~33%) so the initial patch needs to be reverted instead.

Tests by m_gol & gibson042.

Fixes #14836 Closes gh-1532

Changeset: 2c180ef938201f1213b5c43c8212856d0282e1f0