Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP


linear-gradient vendor-prefixing should fix angle statements #43

ampaze opened this Issue · 6 comments

2 participants


When working with angles in a linear-gradient statement, one cannot just add vendor prefixes but also has to adjust the value of the angle (+180°) for the vendor prefixed versions.

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 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.

For example

background: linear-gradient(315deg, transparent 15px, #ffffff 1px);

needs to become

background: -moz-linear-gradient(135deg, transparent 15px, #ffffff 1px);

You're right. Though it looks like a -90° rather than +180° adjustment is required to switch east to north.


Just tested it without prefix in IE 10 and Firefox 18 and both need +180°. Chrome 24 doesn't support without prefix yet so could not check.

On another note, you should also remove -ms-linear-gradient from auto vendorprefixing, as IE 10 supports linear-gradient and -ms-linear-gradient was only ever supported in IE 10 pre-release versions.


I've fiddled this to demonstrate:

I also tested in Win 8 pro and it looks like IE 10 final supports both prefixed and un-prefixed versions of linear-gradient for backwards compatability. Keeping the -ms- prefixed version keeps gradients in IE 10 for developers still using the old syntax.


This is more like my specific case seems it is not that easy to get the correct value.

What old syntax for IE10 do you mean? When Developers use -ms-linear-gradient themselves then it has nothing to do with css-crush and when they use the non-prefixed version why should css-crush generate code that will never be used as IE10 will use the non prefixed version anyway. Was just a suggestion though.


Got it. The old gradient syntax angles move in an anti-clockwise direction, so the following is required to convert a new gradient angle to an old one:

(n+90) - (n*2)

I'll get this fix in soon. Thanks for your help :)


Awesome! CSS Crush for the win. :+1:

@peteboere peteboere referenced this issue from a commit
@peteboere linear-gradient functions with angles specified in degrees now conver…
…t child vendor aliases to match (#43)
@peteboere peteboere referenced this issue from a commit
@peteboere linear-gradient functions with angles specified in degrees now conver…
…t child vendor aliases to match (#43).

Updated changelog.
@peteboere peteboere closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.