CSS gradient syntax: comparison of Mozilla and WebKit

Warning This article was written over six months ago, and may contain outdated information.

Update: I wrote this arti­cle in 2009. In ear­ly 2011 WebKit decid­ed to change their syn­tax to match that used in Fire­fox (and the W3C spec­i­fi­ca­tion). The syn­tax con­tained in these arti­cles will be main­tained for rea­sons of back­wards-com­pat­i­bil­i­ty, but you should use the new syn­tax for the future.

CSS Gra­di­ents were orig­i­nal­ly pro­posed by the WebKit team in April 2008, mod­i­fied from the syn­tax pro­posed for the Can­vas ele­ment of HTML5. In August of this year, Mozil­la announced that an imple­men­ta­tion slight­ly mod­i­fied from that of WebKit would be in the next ver­sion of Fire­fox (3.6).

Since then, how­ev­er, the CSS WG have dis­cussed a dif­fer­ent syn­tax, and a res­o­lu­tion was passed to add this to the Image Val­ues mod­ule. Mozil­la have decid­ed to imple­ment the new syn­tax, which is sim­pler than WebKit’s but less flexible.

In this arti­cle, which will be split into at least two parts, I’m going to com­pare the two syntaxes.

Through­out both parts, I will be refer­ring to the fol­low­ing demo page; you’ll need to be using Safari 4, Chrome, or Fire­fox 3.6beta3+ in order to see it working:

CSS Gra­di­ents com­par­i­son: Mozil­la & WebKit.

The first and most notice¬≠able dif¬≠fer¬≠ence is that the Mozil¬≠la imple¬≠men¬≠ta¬≠tion uses two prop¬≠er¬≠ties ‚Äď -moz-linear-gradient and -moz-radial-gradient ‚Äď where¬≠as WebKit use only a sin¬≠gle prop¬≠er¬≠ty ‚Äď -webkit-gradient ‚Äď with two type val¬≠ues: linear and radial. That should become clear¬≠er as I progress.

Please note that I‚Äôve tried to use the sim¬≠plest syn¬≠tax pos¬≠si¬≠ble for all exam¬≠ples, but there may be occa¬≠sions where I‚Äôve slipped up. Feel free to cor¬≠rect me.

Linear gradients

The Mozil­la syn­tax accepts three dif­fer­ent prop­er­ties: start point, angle of direc­tion, and colour stops. WebKit’s also takes three (exclud­ing type: lin­ear, as men­tioned pre­vi­ous­ly): start point, end point, and colour stops.

So a sim­ple left-right gra­di­ent change (Lin­ear 1) between two colours in Mozilla:

-moz-linear-gradient (left, green, yellow);

The left val­ue sets the default posi­tion to the mid­dle of the left-hand side (0deg, 0 50% or left cen­ter does the same); the line then goes hor­i­zon­tal­ly out pass­ing from green to yel­low in equal proportion.

To get the same pat­tern in WebKit:

-webkit-gradient (linear, left center, right center, from(green), to(yellow));

The start point is at left cen­ter (I could use unit val­ues or per­cent­ages as Mozil­la does, but not an angle), the end point at right cen­ter, and it also pass­es from green to yel­low in equal proportion.

We can tweak those val­ues slight­ly to get a diag­o­nal gra­di­ent from the bot­tom left cor­ner (Lin­ear 2); for Mozil­la I spec­i­fy an angle, for WebKit I set new start and end points:

-webkit-gradient(linear,left bottom,right top,from(green),to(yellow));

I’ll tweak those val­ues again to make a bot­tom-top gra­di­ent with an extra colour (Lin­ear 3):

-webkit-gradient(linear,center bottom,center top,from(green),color-stop(0.5, yellow),to(blue));

The big dif¬≠fer¬≠ence here is that Mozil¬≠la dis¬≠trib¬≠utes the three colours pro¬≠por¬≠tion¬≠al¬≠ly, where¬≠as WebKit‚Äôs color-stop func¬≠tion requires that I set a stop point ‚ÄĒ I‚Äôve used 0.5 here, although I could have used 50%. The from and to func¬≠tions are short¬≠hand for color-stop val¬≠ues 0 and 1 (or 100%), respec¬≠tive¬≠ly.

I don’t have to dis­trib­ute the colours even­ly, how­ev­er; by chang­ing the val­ue in the colour stop I can choose my own ratio. In the final exam­ple (Lin­ear 4) I’ve set the yel­low to begin 25% along the length of the gradient:

-moz-linear-gradient(90deg,green,yellow 25%,blue);
-webkit-gradient(linear,center bottom,center top,from(green),color-stop(25%, yellow),to(blue));

For Webkit I only have to update the color-stop val¬≠ue; for Mozil¬≠la, I have to spec¬≠i¬≠fy it.


There are a few dif­fer­ences in the syn­tax­es for lin­ear gra­di­ents, but they’re not major; Mozil­la use an angle val­ue, where WebKit use a point-to-point sys­tem. I’d say Mozil­la’s is the eas­i­er to grasp pure­ly because of its brevi­ty, but it’s not that impor­tant. In the sec­ond part of this arti­cle I’ll talk about radi­al gra­di­ents, and it’s there that the dif­fer­ences in imple­men­ta­tion become more pronounced.

Update: Part 2 of this arti­cle, about Radi­al Gra­di­ents, is now avail­able.

14 comments on
“CSS gradient syntax: comparison of Mozilla and WebKit”

  1. Social com¬≠ments and ana¬≠lyt¬≠ics for this post‚Ķ

    This post was men­tioned on Twit­ter by stop­sat­green: New blog post: CSS gra­di­ent syn­tax: com­par­i­son of Mozil­la and WebKit http://bit.ly/6tyBAL/…

  2. [‚Ķ] CSS gra¬≠di¬≠ent syn¬≠tax: com¬≠par¬≠i¬≠son of Mozil¬≠la and WebKit [‚Ķ]

  3. I retract my pre¬≠vi¬≠ous com¬≠plaint ‚ÄĒ most¬≠ly. I can get it ‚Äúgood enough‚ÄĚ with an angle in my case. Inter¬≠est¬≠ing approach.

  4. Here’s a major issue I have with Webkit’s syntax.

    I have the fol­low­ing on my website:
    back¬≠ground-image: url(images/background.jpeg), ‚ÄĎmoz-linear-gradient(#92dbd6, #077582 1152px, #022228);

    The intent of this is to pro¬≠vide a gra¬≠di¬≠ent from #92dbd6 to #077582 while a 1152px back¬≠ground image loads, and con¬≠tin¬≠ue from the #077582 final colour on the back¬≠groudn image down to #022228 to offer a seam¬≠less shad¬≠ing to dark.

    This is, as far as I can tell, impos­si­ble in the webkit syntax.
    It is a shame since this is a real world exam¬≠ple I could use imme¬≠di¬≠ate¬≠ly. In Safari or IE, you sim¬≠ply see the back¬≠ground colour of #077582 so the image seems to shade to that on long pages.

    In the¬≠o¬≠ry I can use back¬≠ground-posi¬≠tion and only:
    ‚ÄĎwebkit-gradient(linear, left, left bot¬≠tom, from(#077582),to(#022228))
    That would offer noth­ing while the image loads, but at least offer a gradient.

    *how¬≠ev¬≠er* webkit has ditched ‚ÄĎwebkit-back¬≠ground-posi¬≠tion and ‚ÄĎwebkit-back¬≠ground-posi¬≠tion‚ÄĎx

    So if I did that I’d screw up fire­fox, which seems quite unfair.

    I also tried:
    back¬≠ground: url(images/background.jpeg) top left repeat‚ÄĎx, ‚ÄĎwebkit-gradient(linear,left top, left bot¬≠tom, from(#077582), to(#022228)) 1152px left repeat‚ÄĎx / 100% 100%;

    Which seems to me to be how the CSS3 spec exam¬≠ple says to do a com¬≠bined back¬≠ground ‚ÄĒ my the¬≠o¬≠ry was fire¬≠fox and oth¬≠er browsers would sim¬≠ply throw out this rule due to the ‚ÄĎwebkit

    How¬≠ev¬≠er webkit ignores this rule too.

    So, my site remains lin­ear-gra­di­ent free in webkit.

    Basi­cal­ly it boils down to the webkit syn­tax only sup­port­ing per­cent­ages in stops, and not sup­port­ing pix­els for the begin/end (I could do left 1152px, left bot­tom otherwise)

    The Fire­fox syn­tax is far more flex­i­ble, I hope it becomes standard.

    Same in radi­al gra­di­ents as I hope you dis­cov­ered, with vari­able size box­es. I had to ditch webkit radi­al gra­di­ants on vari­able box­es ’cause they were also unusable.

  5. BTW, your stylesheet specifies:

    #com¬≠ment¬≠form input[type=‚Äútext‚ÄĚ]:focus, #com¬≠ment¬≠form textarea:focus {

    with¬≠out spec¬≠i¬≠fy¬≠ing a colour, so I get almost unread¬≠able grey text on a pink¬≠ish back¬≠ground with my dark sys¬≠tem theme.

    For sites I vis¬≠it a great deal I over¬≠ride bad behav¬≠iour in styl¬≠ish, but it‚Äôd be nice if you fixed it.

  6. Thanks for the feed­back, nemo. TBH my com­ments form needs to be prop­er­ly re-designed, but I’ve added the col­or into the stylesheet to fix the prob­lem you mentioned.

    You‚Äôre right about the WebKit syn¬≠tax, it only allows a dec¬≠i¬≠mal or per¬≠cent¬≠age value.

    Accord­ing to this bug report the WebKit team are look­ing at the new syn­tax but have one or two concerns.

  7. Aye. I chat­ted with him. He was of opin­ion the new pro­pos­al was too restric­tive, but fact is, every­thing he chal­lenged me to do w/ Fire­fox syn­tax I did w/ only a few min­utes effort.

    And, yes, it requires using things like mul­ti­ple back­ground-images, back­ground-size, back­ground-posi­tion, back­ground-clip etc.

    I see no prob­lem w/ that. Hav­ing a gra­di­ent syn­tax that repeats things you can already do w/ oth­er parts of back­ground-* seems rather redundant.

    Any­way. What­ev­er their con­cerns are, hope­ful­ly they don’t change the core of the syn­tax. We’ve been find­ing the new pro­pos­al way way more use­ful than the old syntax.

  8. […] are two great arti­cles on this top­ic, delver deep­er into the syn­tax dif­fer­ences: CSS gra­di­ent syn­tax: com­par­i­son of Mozil­la and WebKit and CSS gra­di­ent syn­tax: com­par­i­son of Mozil­la and WebKit (Part […]

  9. [‚Ķ] la syn¬≠taxe des gra¬≠di¬≠ents pour Fire¬≠fox et Webkit, je vous con¬≠seille cet excel¬≠lent post sur le blog Bro¬≠ken-links. Post√© dans CSS3 | Tags : CSS3, [‚Ķ]

  10. FWIW, the col¬≠or prob¬≠lem report¬≠ed above still seems to exist.

  11. In the future this Prob­lem is going to be solved.

  12. @Type-Style: Yes, I’ll update this post to reflect the change of syntax.

  13. [‚Ķ] a handy com¬≠par¬≠i¬≠son of Mozilla‚Äôs and WebKit‚Äôs gra¬≠di¬≠ent for¬≠mats, and [‚Ķ]

  14. [‚Ķ] la syn¬≠taxe des gra¬≠di¬≠ents pour Fire¬≠fox et Webkit, je vous con¬≠seille cet excel¬≠lent post sur le blog Bro¬≠ken-links. Post¬≠ed in: Css Tags: [‚Ķ]