Different syntax for different rendering engines

Mozilla (Firefox, Flock, etc)

Mozilla's syntax (more detail here) is like this:

-moz-linear-gradient([<point> || <angle>,]? <stop>, <stop> [, <stop>])

The simplest way to declare a gradient is to just list a comma separated list of colors. That will start at the top and gradient to the bottom with equidistant color stops for each color. In the demo code above, we use a point and an angle (90deg) to it go bottom-to-top instead. For radial gradients: -moz-radial-gradient

WebKit (Safari, Chrome, etc)

WebKit's syntax (more detail here) for Chrome 1-9 and Safari 4-5 is like this:

-webkit-gradient(<type>, <point> [, <radius>]?, <point> [, <radius>]? [, <stop>]*)

They have now dropped the old syntax and moved toward something simpler. As of Chrome 10 and Safari 5.1 it's now like this:

background-image: -webkit-linear-gradient([<point> || <angle>,]? <stop>, <stop> [, <stop>]); /* Chrome 10+, Saf5.1+ */

Opera

As of Opera 11.10, Opera supports CSS3 gradients in the same format as Mozilla and the latest WebKit.

background-image: -o-linear-gradient([<point> || <angle>,]? <stop>, <stop> [, <stop>]); /* Opera 11.10+ */

Trident (IE)

Trident's syntax (not really CSS3... more detail here) is like this:

filter: progid:DXImageTransform.Microsoft.gradient(GradientType=0, startColorstr=#1471da, endColorstr=#1C85FB);
-ms-filter: "progid:DXImageTransform.Microsoft.gradient (GradientType=0, startColorstr=#1471da, endColorstr=#1C85FB)";

"filter" should work in IE6-IE8 (haven't tested IE9), but it's not "valid" code. "-ms-filter" is valid, but only works in IE8+.

Unfortunately, we can't invite IE to the party! Using these filter properties does indeed work, and it would allow us to programmatically declare gradients which is cool. But, instead of using the filter first and the image as a fallback, declaring a background-image overrides the filter and it uses that. Since we definitely still need image fallbacks, we might as well not use this at all.

"Stops"

The WebKit and Mozilla syntax for gradients both incorporate "stops". A stop is an optional additional declaration that includes a point and a color. This means the gradient wont just start at one color and end at the other, it will fade to the stop color first, and that stop color will fade to the end color. More than one stop can also be used.

Saving HTTP requests

Using Firebug and looking in the Net tab to see all the resources used by the page, we can see the advantage.

The above screenshot is Firefox 3.6. We can see that the gradient fallback images are NOT loaded, which saves an HTTP request.

However using Firefox 3.5.8, the fallbacks are loaded.

We don't save any HTTP Requests in olders version of Firefox (This is 3.5.8 on Vista). The gradient fallback images are still being loaded (and used).

It gets a little more iffy in WebKit browsers.

WebKit browsers WILL use the CSS3 property to render the gradient, but at the same time, still load the fallback images, so no HTTP requests are saved. The only advantage is the programatic declaration of color.

UPDATE (August 9th, 2010)
As of this date, Safari 5.0.1 is still loading the fallback images, but Chrome 6.0.472.25 dev now joins the party of browsers that (awesomely) don't load the fallback image.

UPDATE (April 1st, 2011)
Safari is at 5.0.4 and is still loading fallback images. Opera 11.10 does the right thing out of the gate by not loading fallbacks.

Doing it by the numbers

The speed gained by losing an HTTP request, to me, is the biggest advantage. The more I learn about web performance it seems to me keeping those down is the #1 way to improve page load time. However there is another advantage to using CSS3 gradients, and that is that these gradients are created programmatically through numbers. Need to adjust some colors? Just adjust some numbers. No need to bring a big image editing program into the picture. This makes maintaining the site easier, as well as opens up doors for adjusting values on-the-fly. I imagine JavaScript libraries will begin to get the ability to animate these values soon enough, which will be pretty darn cool.

Ooooh Stretchy

When using an image for a gradient, it is declared as a CSS background-image and then repeated (you can often get away with a 1px slice, which is very efficient, size wise). The result though is that a static portion of the background is gradientized, and any overflow to that is flat color. Sometimes that works perfectly. Sometimes though it would be cool if the gradient stretched the entire height or width of the box. That is another thing CSS3 gradients can possibly be useful for:

So the big question is... is it really worth doing right now?

My answer on March 2nd, 2010: I'm thinking it's pretty darn close. If the numeric representation is a big deal to you, then I say yes you should start using them. If the speed is the only reason you would, then just realize that the only browser that it will help in is Firefox 3.6+, so you might wanna wait a bit on that.

My answer on April 1st, 2011: Pretty much yes, go for it, especially linear gradients. Linear gradients are more solid cross browser and browsers that don't support them are dropping in usage relatively quickly. Of course it depends on the exact use case, but typically a gradient is a visual nicety and thus a fallback of a solid color or image isn't such a big deal.

Additional Resources

• Latest syntax of WebKit gradients from the WebKit blog.
• Mozilla docs for linear gradients, repeating liner gradient, radial gradient, and repeating linear gradient.
• CSS3Please - latest syntax on gradients and many other CSS3 things.
• Lea Verou with clever and practical background techniques. Also see Lea's automatic gradients syntax converter thingy.
• Opera's introductory blog post on linear gradient support.