Not sure exactly what you mean, but it should work the same way as it works in Safari, as they are both based on the WebKit rendering engine.

Mikeyyy,

Oh, good question, I sure hope, but very hard to tell at this moment.

I agree, you do need to adapt to your context needs, there’s no solution fits all.

However, it should only be used if your website has a lot of images. Because it is useful to devide images into different files, and because semantically, background-image was only intended for backgrounds.

I’m not defending the size and number of superfluous functions in JavaScript libraries at all, and I agree they’re overused.

However, this research is performed by a lot of people working for the highest trafficked web sites on the Internet, and it is common knowledge that a huge number of HTTP Requests affects performance poorly.

Regarding images: if you want even better performance there, base64-encode your images, resulting in no extra request and the possibility to gzip the output as well.

The biggest problems with HTTP Requests isn’t header size, it’s about latency and limited number of concurrent downloads in web browsers.

200 OK

The concept of HTTP headers was created for a purpose, it wasn’t created to slow things down.

Lets take a simple real-world case where headers can help speed things up:
A user might tell a browser not to load an image if its bigger than, say 10kb. Or even, a browser might prioritize its requests differently and load the bigger images last. The browser will need the Content-Length header to know what the image size is in order to make these decisions.

The size of the HTTP headers above is 339 bytes. 339 bytes people!
Lets compare it to something useless that I see on most webpages today; redundant jQuery functions. e.g. .animate(). You don’t always use .animate() in your project, but you always include it. Why? because its comfortable to know its there when you need it, because its hard to build your own custom version of jQuery. Who pays the price? Your users.

That function is about 1.9kb in size, uncompressed, unpacked. I have no idea how much space it actually takes on the compressed and packed version of jQuery, but I’m sure its much more than a few bytes.

Conclusion — Before you run off into the sunset with some “genius” from Yahoo/Google, do your own research, use logic. You want to speed up your website? There is plenty of bad coding in things like JS libraries that you can tweak before you decide it’s time to break/cheat the browsers’ function.

<food-for-thought>

If you know about the radial gradient in IE, please let me know!

Regarding the number of HTTP requests, lots and extensive research by, for instance, performance guru Steve Souders (formerly of Yahoo!, now with Google) and by Yahoo!, described in Best Practices for Speeding Up Your Web Site, shows that too many HTTP requests is one of the biggest performance problem on the web. It’s about superfluous header data, latency etc.

Also, quit whining in the comments people! These CSS properties are EXPIRAMENTAL (exculuding IEs old stuff of course). They are still drafts on w3.org, meaning they are still even subject to change. browsers that did implement them already used a prefix for the purpose of marking them as expiramental.
And its a good thing too, because if they hadn’t a lot of websites will be broken when CSS3 would actually be finished, just because you guys only read misinforming blog posts for information instead of the offical specification/browser release notes.

And another thing, whats wrong with multiple HTTP requests? How is it a bad thing to devide content into different files that load individually, giving the user the option to stop, block, and or manipulate certain downloads in a page? Do you think a few bytes of HTTP headers are going to slow down your page loading time considerably? I guarantee you that your favorite JS library, that has functions you never use — and still load on every page, does a lot more damage to your loading time than than a few HTTP requests.

Really? Can’t check right now, but if that’s the case, it’s not good.

hope FF will do something for that soon.

Yes, it was an unfortunate word choice.

Nice, thanks for the tip!

Well, it is going in the direction of being standardized with just one single CSS approach. Unfortunately, that’s far away at the moment, and this is our option for now (CSS-wise).

Remy,

That’s kind of a huge discussion, but I’d say design (e.g. gradients) is extremely useful in teems of creating a better user experience, proven by Apple with a lot of their products.

With IE and performance on filters, absolutely, it’s a valid question and in the end it comes down to testing and evaluating the experience for your specific use case.

And yes, I’d love test cases deeply evaluating filters performance in IE as well.