Ryan, my mentor from when I was at MoCo, wrote an excellent article on spriting a few days ago. Man, I miss all the good conversations…that’s what I get for not subscribing to the webdev feed. That’s all changed now.

I have an interesting history with spriting. For both of my internships (Mozilla and Yahoo), one of my first projects was to sprite sites (AMO & Yahoo! Real Estate, respectively). AMO is still using my work (for now), and YRE long ago gave up on rounded corners, and have few icons now, so spriting is more or less useless for them now.

I guess that qualifies me to weigh in a bit. I’m not going to talk about the memory usage or anything on the client-side past delivery for two reasons. First: size in RAM has a tiny impact on page-loads compared to downloading for most users. Second: I’m horrible unqualified to talk about how web browsers load and store images in ram. Not my field.

There are some issues (many fixable) with spriting:

• In both instances of spriting I got an email a few months after I left the company asking me where my source sprite file was located. Once it was due to me not putting the file in the right place, but the fact still remains that a source sprite file is one more thing to lose, and losing it is pretty annoying.
• Not everyone knows how to compress images properly. If you do it wrong, you’ll end up with a huge PNG file that is worse than a bunch of small files.
• Spriting removes any connection between CSS styles and the images they are associated with. If I want to know what a class with a background image looks like, I have to either find a reference to it on the site, or figure out where the hell -123px -72px is. It’s more or less obfuscating your CSS.
• repeat-x or repeat-y images need to span the whole width/height of the sprite…they should have their own sprite files (if you have enough of them)
• Like Ryan said, images that are supposed to be near the left of an element (i.e. they need an arbitrary amount of space to the right of them) should be at the right side of the sprite. This makes an internationalized site that supports right-to-left text (an insanely difficult thing to achieve, and something which many MoCo sites do impressively well) much more difficult. It’s very frustrating to discover halfway through that your sprites show up wrong in RTL. Not many sites need to worry about this, but it’s annoying if you do.

With that being said, spriting can be useful when done properly. A very good example is how Yahoo Mail sprites. They group similarly-size things in a file. They have an icon file, a rounded corners file, etc. This makes things easier to manage, but still suffers from some of the above issues.

I don’t know how Yahoo’s build process works, but to make sprites worth it I would propose some kind of CSS build step. Ideally all the developer would have to do is specify which images are displayed which ways (whether there needs to be whitespace to the left, right, top, or bottom), and the system will build the sprite and generate a complied CSS file that is minimized and concatenated.

AMO’s build process got halfway there. It was originally a shell script written by yours truly, converted to python by FWenzel. The shell script is described here (the python script is essentially the same). It concatenates a bunch of files, compresses them with YUI Compressor, and creates a PHP file with the current revision numbers (to append to the URL for long expires headers). Pretty standard web build system.

I’d really love to see a system that also parses out background*: rows with comments at the end (identifying what type of spriting should be done), places them, replaces the URL, and adds a background-position. That, combined with AMO’s build process, would allow an algorithm to determine what’s best for download times vs. memory usage.

The best part: an automated system would easily allow bucket tests on load times based on different sprite files. Now wouldn’t that be useful?