css3 was never really made for shortening our css code, but rather with the idea that it would deliver a more flexible experience. A background color gradient used to be only achievable through the use of a background image, meaning that if the gradient needed tweaking you had to keep recutting the image over and over again. By moving this graphical effect to css it would be possible to simply define the needed colors and let the browser do all the drawing. Sounds good, right?
Now I know we are into some kind of intermediary phase, but ever since both webkit and Firefox started proprietary support for the gradient property it has made my css life completely miserable. As a front-end developer with a passion for getting to know latest techniques and methodologies I'm eager to start using the css3 way (you know, live and learn), but it's damn time and byte consuming to get things working across a range of browser. For a pretty simple fade I had to create yesterday, I came up with the following piece of code:
/* how it used to be */ background:url("...") left top repeat-y; /* using automated gradients */ background:#FEF3D1; background:-moz-linear-gradient(top, #FFF1CC, #FDF5D5); background:-webkit-gradient(linear,0 0,100% 0,from(#FFF1CC),to(#FDF5D5)); -ms-filter: "progid:DXImageTransform.Microsoft.gradient (GradientType=0, startColorstr=#FFF1CC, endColorstr=#FDF5D5)"; filter: progid:DXImageTransform.Microsoft.gradient (GradientType=0, startColorstr=#FFF1CC, endColorstr=#FDF5D5);
This makes the fade available in FF 3.6+, Safari/Chrome and IE5.5+. Opera users and IE users without filter support simply see the fall-back color. In contrast, using an image makes it available in every single browser version out there without any issues.
The problem is not so much that the css3 syntax is a little longer but that it looks like a block of css which could style half a site. And that only for one fade.
support doesn't equal quality
An image is an image. Apart from some color profile nonsense, it shows up the way it was made, consistently across all browsers. This is not true for css3 effects. It's not because a browser supports a certain css3 property that it knows how to render it properly. Firefox gradients are of sufficiently lower quality than those in other browsers. Especially light fades over large areas are known to create ugly stripes.
These artifacts are dependent on the conditions when viewing the gradient (screen settings and such), but on my home screen the difference between Safari and Firefox gradients is really striking. And this is just one example of course, I'm sure differences in rendering quality will keep popping up in the future. Gaps in quality you won't have when working with images.
One other area where css3 is seriously failing is animation. While it's neat that you can define (non-functional) animations in css, I still haven't seen one implementation that runs smoothly. And I mean smooth, not hey, for a browser this is kinda okayish. Replacing Flash with open standards is fine by me, but as long as the same level of quality can't be guaranteed I'd rather watch Flash animations to be honest. css3 animation is definitely nerdy cool, but quality-wise it's utter crap.
support doesn't mean full support
Still, all the above didn't put me off enough to stop css3 gradient experimentation. I started a new project today and pretty much the first thing I had to do was define a background gradient for my site. Not a full gradient mind, a pretty big harsh fade 3px high, which led to a slight fade of about 500px high.
It took me less than a minute to work it out in Firefox and about an hour to find out there was no (easy ?) way to accomplish it with the -webkit syntax. Apparently you can set stop-points, but only in relative measures. Why, I don't know (documentation is rather lacking on the webkit site), but the outcome is pretty obvious. No css3 gradients for me. Sigh.
The bottom line is simple. The theory behind css3 is awesome, but practical use is something entirely different. I hope this intermediary fase won't last too long and that it won't create a similar backlog of compatibility issues the way IE6 did. Public availability on pre-standards are what causing all this at the moment, so I would really advise browsers to keep their proprietary css locked away in development versions, but I'm afraid they're not really going to listen.
It's not the first time I'm complaining about this, but theoretical complaints seem to be materializing rather rapidly these past couple of months. As it stands now, I find it easier to debug sites for IE6 (with the help of the IE6 CSS Fixer) than it is to get css3 working nicely across a range of browsers and browser versions. It's a somewhat sobering thought in sharp contrast with our past dreams, but it's a reality nonetheless.