I wonder whether anybody has found a better solution to get rounded corners and gradient background to work together on IE9 without the use of images. I have googled for the solution but the only thing that comes up is a solution with overlapping layers or with the use of SVG and I really would not want to go there.
I’m surprised you haven’t heard of the new CSS3 property ‘border-radius’.
It’s supported in IE9 and in almost every browser.
For background gradients, you can use the old slice method or the new CSS3 value ‘gradient’.
Welcome to the future, Karlis.
~TehYoyo
Hi,
I think the op was referring to the fact that the IE filters break border-radius in IE9 as they bleed right into the corners and ruin the effect. 
I did an old demo that used an inset shadow to follow the round corner and then make sure the gradient fades out before it gets into the corner. It’s not really a solution but does allow for a similar if somewhat contrived effect.
Between the compatibility issues, them making scrolling painfully slow in Gecko based browsers (like firefox), the massively bloated CSS to use them thanks to vendor prefixes, etc, etc… my advice has become…
SUCK IT UP AND USE AN IMAGE 
Though another CSS3 property can take a simple sub half-k image and do wondrous things with it so far as gradients are concerned… background-size.
You want that gradient image to stretch or shrink to fit? background-size:100% 100%;
Kind of like border-image – a great CSS3 feature for making images as if not more functional than properties like border-radius or linear-gradient, but you don’t hear people talking about them a whole lot.
Really though, is a 512 byte image REALLY going to break the bank on your design, especially since it will probably give something approximating the appearance you want all the way back to IE 5? Particularly when you’re talking 350 bytes of code or more just for linear-gradient and all it’s vendor-specific cousins. Starts to sound kind-of silly at that point.
Yes, I have to agree and I never use the linear gradients in real sites simply because of the mess of code you have to insert and the fact that I can do it quicker with a real image. Also the fact that linear gradients slow Firefox to a crawl (just like fixed positioning used to) and make it unusable.
Here’s what I use with Compass
.widget {
@include background(linear-gradient(top, #fff, #eee));
}
I haven’t experienced the crawl when I’ve used them either.
The only thing has been large box-shadow’s… I’ve found them quite easy to implement, time saving & offers heaps that images don’t.
Yes that is certainly easier (and how it should be) but I tend not to use any of those sorts of tools. I still prefer to do it all myself
I haven’t experienced the crawl when I’ve used them either.
The only thing has been large box-shadow’s… I’ve found them quite easy to implement, time saving & offers heaps that images don’t.
It depends on the layout and what else is going on but the latest versions of Firefox are better. FF3.6 was very slow.
Thanks, so…
My solution 1: combine this
SUCK IT UP AND USE AN IMAGE
and this
You want that gradient image to stretch or shrink to fit? background-size:100% 100%;
My solution 2:
I could use no gradient at all on IE9, those concerned about style and details such as gradients and shadows (designers, artists and people with a taste) do not use IE browser anyways, the rest do not care if there is a gradient or not.
“My solution 2” is the option I would go for, as a rule I don’t use IE filters.
Oh, and don’t let my post mislead you on option 2… While I lean towards option 1 because generated gradients mess up FF so badly (and watch the memory use when on them – yikes!) – we’re talking about subtle visual effects that to be frank, if certain versions of less capable browsers don’t get them… OH WELL.
I’m ESPECIALLY in favor of option 2 in regards to border-radius. Oh noes, IE8 and lower don’t get rounded corners. BIG DEAL! It’s a minor visual effect that has nothing to do with delivering content to the user. It’s actually part of what the whole ‘graceful degradation’ thing is about… less capable browsers lose the fancy effect that have little if any real benefit to the user other than ‘ooh, pretty’.
But when it comes to gradients, it’s so close on the file-sizes and it’s actually LESS effort in their current state to get them working with images, so really why bother with the CSS3 for it… and even if you do use it, IE8/lower doesn’t get it, OH WELL…
Oh, and you said IE9… if you use the -ms prefix, they will work there, it’s only IE8/lower that’s a worry with them… so… oh well.
If you are talking about gradients then that’s not correct as they are not supported in ie9 even with the ms prefix. They are supposed to work in ie10 with the ms prefix though.
How big is this problem? It is something new to my hearing… I was just starting to like this feature and use it a lot at least on surfaces without rounded corners.
Set background gradient on BODY, make the page long enough to want to scroll, open up task manager, watch the CPU use when you try to scroll up and down… my i7 870 and i7 920 machines assuming nothing else is running can handle it, but hit 80% on one core when scrolling… If I have something like uTorrent or Filezilla going in the background, forget it, there’s not enough CPU to scroll without tearing/jerkiness. My T9500 powered laptop (dual core 2.4ghz) is actually taxed just by attempting to scroll, to the point it’s as jerky and painful as trying to scroll the old myspace pages people used to make that had the dithered transparency backgrounds.
FF sees similar issues with text-shadow and box-shadow if you try to use them for hover effects – you’ll get a second or two delay even on a i7 as it tries to draw the hover – making it as bad if not worse than the old javascript/css swaps without pre-caching.
… now picture that on an Atom powered netbook, or one of these $400 or less sub-1.5ghz AMD laptops that are the only thing flying off shelves at places like Staples and Best Buy.
Though I suspect it’s another reason Chrome and it’s kine are still seeing growth while FF has remained pretty flat.
I am with DS60 (nice new avatar,btw!) on this. A well optimized gradient can in the end be more efficient than 4 or 5 lines of vendor specific code ( in some cases per element). It’s only two real advantages ( which were not mentioned above) is saving you an HTTP request and scaling. If you plan to reuse the gradient, or mix and match I would recommend going with the bg img, it’s really not a bad method and provides great backward compatibility. if you are only targeting CSS3 complaint browsers, a good compromise solution might be border image and/or multiple bg images/repeats/scales ( again mind your HTTP requests …)
I haven’t tested to see border image doesn’t play well with border radius. I will post on that later.
BUT ONCE MORE am with DS60, minor aesthetic differences between browsers should really not be an issue to lose sleep over.
The biggest advantage with CSS gradients is being able to change the image easily in the code without having to create images.
Yeah, those are the advantages (can change colour and lenght of gradients with code, one less HTTP request, scales). I used a linear gradient on a page I’m redoing on my site, but unfortunately Mozilla sneaked an update on me so I can no longer test with FF3.6 
I had 7, 9 and 10 and they were fine (though in general FF is a CPU and memory hog, every time I do a top Firefox is sitting right at the top with a huge load, every time. Not that this is new…)
Scrolling however went swimmingly. And with the css gradients, you could use background-image to state the gradients, which lets you have an image as a backup if you want… so only those who can’t let background-image (somegradient) override will do the HTTP request for teh image.
Ah luvz mah vim:
hit p (paste) and then one or two multiline-substitutions like
:.,lastLineOfVendorPrefixess/#oldcolour/#newcolour/g
love is in the air
vendor prefixes flowing everywhere
…
This is why they generally don’t bother me to write. They bother me to read. But there, syntax-highlighting to the rescue: give all the ones I don’t want to see dark colours and leave the non-prefixed one bright.
Hell, they won’t even realise they are missing a gradient.
Normally I’d agree with that - code over image; but does it really take that long to go “pick colors, floodfill, save”? I mean we’re talking a 1px by whatever other length image here… Not exactly a big deal to change. Just choose gradient for color, foreground to background as the type, opacity to 100% and tolerance to 100%… poof, floodfill gradient. Most of that is my default floodfill state anyways. (talking in PSP terms, shouldn’t be that different in Photoshop, Gimp, whatever).
That and colorstops are a PITA… one of the few things I’d prefer to do in a paint program.
Well I disagree. ( Guess I am agreeing with DS60 again) Is there some sort of Photoshop fear amongst coders? Aside from saving the HTTP request, the main advantages is the dynamic nature of UA generated gradients. In other words they can stretch with the element, you can use EMs as measurements , do quite a few neat placement tricks… etc. However, as it has been mention before , this is putting quite a load on the browser. So it is key not to slap around css3 gradients merely because you ‘can’ if a few 600byte gradients could do the job. But if for some unfortunate reason you end up needing two dozen gradients … or gradients which must adjust to content… then I’d start leaning towards generated gradients.
I actually implemented an interesting solution for this. I was building a site which had lots of gradients of various colors. All together if I did it with images it would have added probably 50KB+ to the overall load (in lots of separate files because I couldn’t do a sprite sheet).
So, CSS gradients were really the only way to handle this.
I have a custom CSS processor thing which lets me do a couple fancy things and then cache it to my server. One of the things it can do is let me define custom property replacements (similar to what markbrown was talking about), though I can write them as a normal property.
So, in my CSS, I would do this:
background: linear-gradient(blah blah)
and the processor would add all the vendor-specific versions. It would also add a background image, which was a dynamically generated SVG file for the gradient (for IE9). All together, we ended up with support for IE7+ and all the other browsers (the gradients don’t seem to have any noticeable impact on any of the FF versions either).
The part I like about this is that as we drop support for browsers, I don’t have to go edit all my CSS, I just change the function’s code to drop them, until we are eventually (in the year 2152) just left with the one. =p
You have enough to add up that much, I’d think there was something wrong with the design… you need more than five or six separate 1k images the layout would have to be really unusually inconsistent or something… especially if you leverage background-size.
Also, if you have enough of them to add up to that much, I shudder to think how painful that would be to view in Firefox.