Anyway, I applied your method to simply turning on/off text and images in IE6/7 and it worked well, but I thought it was easier with the two class possibilities. (Obviously, star hack accomplishes this too, but I was looking for a more elegant and standards compliant method.) Going back now and looking at it again I see that only one is ever needed, and as you say, in a scripting disabled scenario this would be much better (my application is for a javascript required application). Long day? Senility? Was I awake? I don’t know.

Still, it did get me to check out your other work and discover OpenScripture which I look forward to looking into further.

Thanks for the feedback.

Bit surprised by the “that’s the price you pay for using an old browser”. Why not add an “else”?

I don’t see the benefit in your code over mine as far as the price of having to download the image twice if using a browser that doesn’t support data: URLs. In both of our code, the Base64 image is downloaded along with the stylesheet regardless if the browser can use it, and in both cases the non-supporting browser will have to download the fallback separately. So isn’t the result the same? And actually, I think your code results in an even more undesirable situation: it requires that the user have scripting enabled in order to see any background image at all. In mine, the only case where they wouldn’t see a background image is if they are using a non-supporting browser and they have scripting turned off. But with your code, they won’t see a background image in any browser that has scripting disabled.

Am I overlooking something? Thanks!

var data = new Image();
data.onload = data.onerror = function(){
	if(this.width != 1 || this.height != 1)
		document.documentElement.className += " no-data-uri";
	else
		document.documentElement.className += " data-uri";
}
data.src = "data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///ywAAAAAAQABAAACAUwAOw==";

And the corresponding rule update:

html.data-uri #foo {
    background-image:url("data:image/png;base64,...");
}
html.no-data-uri #foo {
    background-image:url("images/foo.png"); /* fallback */
}

Now each does what it should, and no-one is penalized (assuming the same loading behaviour as described in the post, I haven’t checked it yet).

BTW, I have found that IE, including 9, has inconsistent behaviour with data uris. If used for an image the block of data can be formatted into lines using “\”, but if used for background images the load will fail. Another browser did this too … looks like we have to make it a single line to be cross-browser; could this be the reason for IE’s small data uri length limit?

Also, I couldn’t get the smaller image mentioned in the comments to load in IE9, though it worked in Firefox; it caused onerror to trigger with strange width and height.

Nice article. Thanks. (Just what I was looking for =)

I tried to use this technique not for css specifically but in conjonction with XHR progress event in order to display a real progress bar when loading heavy images (see my post in french, but code is readable : http://jpv.typepad.com/blog/2009/11/barre-de-chargement-dune-image.html)

However due to the various limitations of the browser around the length of data you can put in an URL, you can not load huge images (around 1Mo)
So this technique really should be confined to CSS images

It’s very rare that an image will be requested only once.