Encoding the images into the HTML file together with the rest of the game allows you to redistribute the entire thing pretty easily.

But I guess, the actual answer is the same as to why would you implement a game only in HTML and CSS: because you can.

It's done all the time, mostly to reduce the number of requests needed. It's similar to spriting, but can be even faster depending on the images you need.

Yes, there are fewer requests that way, but the cost is an increase in the total data size. Using a single sprite sheet for all the images would probably be faster in most cases. However, there is the matter of convenience (it's nice being able to have just a single file with no dependencies).

It depends on what you're doing with the image. You can't always tile a sprited image for example, which is a nice advantage for base64 encoding. Size wise they're pretty similar once you count gzipping, though you do have more overhead on base64 since each will have its own set of image headers vs just one for the sprite.

The best is a single sprite sheet encoded into the source file (I believe this is what the Cappuccino framework does for some of the images that make up some UI elements).

gzipped base64-encoded data is about the same size as the original data, though. It only requires more processing to be done.

... Why not? They'll be cached in the stylesheet or whatever source you're providing them from.

And when you change the stylesheet, you'll invalidate the cache on all your images.

If the game starts right away, maybe it's the best way to guarantee all images are loaded.

Why? So that you don't have the overhead of a http request and image download as each image is used.

I'm guessing sprites waste memory?