I think the issue is that the images are different sizes, so putting size/location into CSS would require generating both CSS and a Sprite Sheet for each request.

With Data URIs, they can convert to Base64 ahead of time, and then just concatenate them into a JSON request as needed. This potentially saves them an HTTP request per page load because it means the CSS can be static. The decoding overhead is on the client, which in most cases should offer better user perceived performance than an extra HTTP request for a dynamically generated stylesheet, so it's just a matter of whether it's outweighed by the increase in file size.

When you have a million JPEG images, you would need to generate a sprite on-the-fly every time a random subset of those images is requested. You have to decode the images and encode the sprite each time. That sounds really slow.

Better convert them to Base64 and just concatenate the ASCII strings. Store each Base64 string text file next to the image file.

I agree however that they should use JPEG for their Base64 sprites.

>> Just include the sprite dimensional and positional info in an inline CSS stylesheet on the page and generate a sprite sheet as you would normally.

Which set of images do you generate sprite for? Take ebay search results page , for every search it displays a different set of images.How can we construct a static sprite a ahead of time? However we can generate a dynamic sprite.

I have to agree w/Sephr. No need for javascript and, if copy of image packing info is sent to image packing server at the same time, final image should be ready to serve by the time client requests it.

They're sending the Data URIs in a single JSON file, so it gives the same benefit (fewer HTTP requests) as normal CSS sprites. When you just combine multiple images into one (as you do for normal CSS sprites) you lose the information on the size/location of each sprite. An array of Data URIs keeps the images separate, so you don't need to put size/location information into CSS/Javascript/HTML.

Yes, caching is only for the exact subset.

But you could do your own little client side cache. When receiving the url/img-data pairs, just store them in the HTML5 browser storage database, as key:url/value:img-data pairs. Then you are independent from the grouping into subsets.

And before requesting your next image sprite, just check with the client side data storage what images you already have and which you need to request.

Indeed, they'd cache the [A,B,C] case as well as the [B] one separately, which does reduce the effectivity of caching if there are many common assets and combinations. However in their case the set of images is (supposedly) wildly different per page, so I guess this is not much of a problem.

The IE8 limitation is for 1 image, the JSON response which is a combination of multiple images, will not have data URIs for images greater than 32KB.