While I agree that SVG is a great approach (and you can even base64 the SVG and inline it in the CSS, if you fancy), an alternative to handle gradients (as well as other vendor-extended css properties) is SASS, LESS or, my favorite, Stylus (http://learnboost.github.com/stylus/).
First is a fallback for older browsers: It generates a PNG with the gradient, and inlines the base64 representation. Then it creates rules for webkit, moz and css3.
With Stylus' transparent mixins and nib's vendor mixins, I can write `border-radius: 5px` and get support for all browsers. It's really convenient.
You're missing a huge point of the article, though, and he's right - CSS3 gradients are limited to a subset of their real potential.
With SVG (and/or Canvas, debatably), you can do much more complex filters and combinations, and then still use it within your code. It's not just about the browser-vendor-prefix mess.
Actually, the author of the article is missing the point of CSS gradients. They are not for sophisticated shapes or "anything useful like that". That's exactly what SVG or raster images are for.
Someone could as well write a post entitled "Farewell to border-style" and use very similar reasoning.
1. Patchy support. If you stick to the most common parts of the spec its ok, but there is no comprehensive test suite, and only Microsoft seems to be interested in test coverage. Import stuff that Inkscape can render to a browser and you may get issues. Opera is better than Firefox and Webkit.
2. No CSS transitions on SVG properties, so it is back to Javascript for animation.
3. No support in Android 2.x. Or WebOS.
4. Server side rendering of a fallback image (especially if you use css styling) is a pain. Maybe there are good solutions I havent found yet.
5. It is a big spec, I feel that some better learning resources would help.
This. And on basic stuff too, especially in Webkit: flexible canvas size is broken (fantastic for a vector format), events handling is bonkers, looks vary drastically from one browser to the next, all methods of serving an SVG are shitty in different ways (and forget about using an SVG background, not going to happen), etc...
Tried to make a basic interactive SVG map (not much interaction too, big rectangular active surfaces), ended up scrapping everything and going with canvas. It looks like either nobody gives a shit about SVG on the browser side or the spec is either retarded or not implementable.
OK I admit I never tried SMIL, but I believe the browser support is terrible.
The CSS support works in principle, but in fact almost none of the SVG properties can be transitioned in any current browser. I think some of the shared properties like color can be though, but I couldn't get anything useful to work without javascript (and d3.js has nice javascript transition support...)
Still Javascript transitions only, its better supported only because it is a small subset of SVG which is known to work.
And it has other issues, like the Raphael commands are a separate language, and then the DOM will be different.
For some basic use cases it is a good way to use SVG that gives you IE support (but not eg Android 2.x). It is not a complete answer... also you get to like SVG when you start using it, being able to directly browse the DOM is great, with Raphael it is indirected through a translation layer.
This is the first post I've seen that makes it clear how to use SVG graphics for something useful and attractive in web design. I need to look further into the syntax. Thanks for the post.
Comparing CSS3 gradients with SVG is like comparing MS Paint with Adobe Photoshop, of course it seems like SVG is good at gradients but it is overkill.
Also, SVG XMLish syntax vs CSS3 gradients syntax, no need to compare them, both are bad, but I'd prefer the later at any time.
I've been struggling to come up with a good cross-browser(ish) solution for gradients that doesn't require external images or extra markup, and indeed SVG + CSS3 + IE's filter is the best I've found. It means IE9 (via SVG) renders the page exactly like Chrome, which is great. For IE8 (which has a larger market share than IE9 in our userbase) I had to use IE's filter property in a separate conditional rule so as to not mess with IE9 (for which it breaks border-radius).
Unfortunately, I'd rather not request 10+ svg images, so I chose to embed them in css. That means around 512 bytes per gradient, so around 1K for a button with a mouseover effect. But it's something I can live with (and compress). If you're willing to load external images for linear gradients and don't want the hassle of creating each image by hand, you could build a lightweight server side script to generate the SVG based on url paramters.
There's several IE behaviours out there, of which I found CSS3Pie to be the most complete. It implements border-radius, linear-gradient and more for IE6+. All that warrants a Keanu Reeves-like WOAH, but there's a catch: it's VERY slow.
All in all, unless your userbase is using ancient browsers, go ahead and use CSS3 while make sure older browsers show a degraded, but still useable version. The days CSS advancements were unuseable due IE6 and such being the dominant browsers are pretty much over.
Slightly offtopic, but here's a snippet that I found on last.fm and was blown away by (although it's obvious, I just never thought of doing it):
No offense intended... but I don't understand you, or people like you. The upgraded version is better in every imaginable way. It's like you have a dirty old Honda Civic in your driveway, and someone is offering you a brand new 3 series BMW, for free, with zero effort (and they will even transfer your change out of the driver's console, and swap your radio stations for you).
Is it just laziness, or distrust of "new" code, or something I haven't thought of yet? If you stumbled on a website that required a recent browser, would you actually leave instead of upgrade?
Someone is offering you the BMW for free, but it has different control placement (cruise control is in a different place, climate controls work totally differently, and so forth), and requires more expensive gas. Oh, and you have no money to pay for the gas, and you do a _lot_ of driving and don't want the distraction of learning the new controls on the road. And for your current usage, the Civic works fine.
Some extensions haven't been updated to support newer versions of Firefox. Some people just don't want to sink time into upgrading their software, or risk that something that once worked now doesn't.
If you're a web developer, you have to keep in mind that not everyone is using the latest and greatest all the time.
I use several plugins for development and research that were not working in 4 or 6 and I also really needed the statusbar.
Fortunately I found alternatives and fixes and workaround to get it all back to where I wanted, but it took a whole weekend of searching and fine-tuning (and still some things aren't quite right).
If I had jumped onto 4.0 it would have been a nightmare.
I've also never re-formated and re-installed Windows XP since day one (even upgrading from Windows2000 only after XP was EOL'ed). I have better things to do with my time and I have it running/tuned to my specific desired. Some people reformat like every other month and start from scratch which would be a massive waste of my time and energy.
Many times older is better because it's better documented, as long as it's not buggy.
For the majority of people who aren't in tech or early adapters, we've reached the point of 'good enough'. Upgrading to 'marginally better' has little to no (perceived) utility.
As an aside, that's one of the most beneficial aspects of Chrome and Firefox's CI/incremental update models - normal users don't have to think about upgrading anymore, it just gets done in background. As long as it doesn't kill any addons/extensions (which normal users aren't power users of anyway), it's a great way to keep the web up to date. I don't know if MS, Apple, and Opera are going that way too, but hopefully they will.
Dude needs to google SASS or Stylus if he's considering this a problem. So many other CSS features are only supported by a limited subset of browsers. You have to start treating them like "extras" for the most up-to-date users and gracefully degrade for those who aren't.
The problem is solved with creating great designs and mark-up from the beginning with browser limitations in mind, not addressing limitations during development with some hack.
With Stylus and nib (https://github.com/visionmedia/nib) I can write:
and get: First is a fallback for older browsers: It generates a PNG with the gradient, and inlines the base64 representation. Then it creates rules for webkit, moz and css3.With Stylus' transparent mixins and nib's vendor mixins, I can write `border-radius: 5px` and get support for all browsers. It's really convenient.