Why did Firefox 16 change the direction of my linear gradients?

Question

Sample CSS:

background-image: -moz-linear-gradient(90deg, #e8f0ff, #ffffff);
background-image: -ms-linear-gradient(90deg, #e8f0ff, #ffffff);
background-image: -o-linear-gradient(90deg, #e8f0ff, #ffffff);
background-image: -webkit-linear-gradient(90deg, #e8f0ff, #ffffff);
background-image: linear-gradient(90deg, #e8f0ff, #ffffff);

This used to result in a linear gradient going from #e8f0ff at the bottom, to #fff at the top.

Post-Firefox 16 (released a few days ago), the gradient now goes from #e8f0ff at the left, to #fff at the right.

When I remove the vendor-specific CSS and leave just:

background-image: linear-gradient(90deg, #e8f0ff, #ffffff);

Nothing happens. But when I delete that line and leave just the vendor-specific styles:

background-image: -moz-linear-gradient(90deg, #e8f0ff, #ffffff);
background-image: -ms-linear-gradient(90deg, #e8f0ff, #ffffff);
background-image: -o-linear-gradient(90deg, #e8f0ff, #ffffff);
background-image: -webkit-linear-gradient(90deg, #e8f0ff, #ffffff);

It corrects the problem.

So what's happening here that's new in FF16? Are the Xdeg values starting from a new direction, are they being added together only in certain situations? I can't figure out why it would do 180deg with both or with only general, but only 90deg if it's only vendor.

The question is, what are the specifics of this new behavior from Firefox, and what's the broadest, most standards-compliant solution for websites that now have their gradients going the wrong way in FF16?

Answer 1

The standard dictates that angles are measured clockwise starting from 0° = upward.

using angles

For the purpose of this argument, ‘0deg’ points upward, and positive angles represent clockwise rotation, so ‘90deg’ point [sic] toward the right.

-moz-linear-gradient, on the other hand, uses polar coordinates (emphasis mine):

A last semantic curiosity still exists between the prefixed variants and the unprefixed proposal. Following the initial Apple proposal, the prefixed variants of the syntax all uses the an <angle> defined like polar angles, that is with 0deg representing the East. To be coherent with the rest of CSS, the specification defines an angle with 0deg representing the North. To prevent sites using prefixed version of the property to get suddenly broken, even when adapting to the otherwise forward-compatible final syntax, they keep the original angle definition (0deg = East). They will switch to the correct spec when unprefixing the property. Also, as they aren't incompatible, Gecko supports, prefixed, both the syntax with the to keyword and without. Here again, the syntax without the keyword will be dropped when unprefixing.