The pros and cons of CSS image sprites
It’s the layout image technique all the cool kids are using. Compiling your website images into one master image, then using CSS background positioning to show the correct part and hide the rest. I won’t go into the details of implementation, if you want to learn more you can read this great in depth article on the technique. This is a marvellous idea when used under the correct circumstances, but it’s not all fast loading times and free pie. I’ll be going over some of the issues I can see here.
The Good
Reduced File Requests.
This is the main benefit cited for CSS sprites, and for good reason. When there are less individual files to request, your loading times are decreased. This is absolutely true and is enough to convince me to use sprites whenever appropriate.
Reduced Overall Filesize.
The same amount of pixels spread over ten images takes up more filesize than the same pixels in one image. Again this is a loading time benefit and combined with the lack of requests can make a huge difference depending on the scale.
Instant Image Hovers
When using a separate image file for a hover, the image is not loaded when the page loads, only when the hover is activated. This results in a small delay while the image loads with a nasty gap in your layout (that is, if you don’t use inefficient javascript fixes). Using sprites, each state of the element is loaded with the page and the transition is smooth. It is a good idea to use sprites for elements using pseudo classes for this benefit alone.
The Bad
Limited To Fixed Width Elements
The main drawback to sprites is that they require the element using the image to have a fixed width. CSS does not have the capability to specify the co-ordinates of the image you want to call, this means that fluid elements result in spillover of other parts of the sprite sheet. For example, sometimes I want to position a small image inside a larger element. Using sprites this would not be possible without adding all the extra space around it in with the image, rather than using plain old background positioning.
Tiled Images
Since there isn’t support within CSS to specify the section of the image you want tiled, what you want tiled cannot be contained in a sprite sheet. This can be worked around with a separate very long or very tall ’tiling sprite’ for both horizontal and vertical tiling. It’s not ideal but it’s still better than nothing. Horizontal and vertical tiling just isn’t doable.
Wasting Image Space
The raw idea is to place your images in a nice grid on the sprite sheet, but here in the real world images don’t fit into a grid like that. It can be like playing tetris sometimes trying to cram a bunch of different sized images into as small a place as possible, and there’s always wasted space. It’s usually negligible and more than made up for by the reduced filesize from compiling your images to begin with, but still can be a problem.
Maintenance Nightmares
Let’s not mince words, this is extra work and extra headaches for splicing a design. I’m not one to sacrifice quality to the deadline gods, but productivity is an issue. With a lot of compiled images and even with a good reference to which images are at which co-ordinates, this can get confusing fast. It is an inconvenience that I personally will take in the name of improved performance, but an invonvenience nontheless.
The Conclusion
Sprites are a fantastic idea and there are a lot of situations where using them is beneficial and convenient. For image navigation, buttons, pseudo classes and fixed elements it’s a nifty little trick and solves some issues. For layouts, if it’s a very fixed size and you’re willing to take the extra hassle then it’s worth it for the speed boost.
Most of the problems with sprites could be solved by an addition to CSS specifically for sprites: Specifying the co-ordinates of an image to call and use as if it were an image. I don’t know how feasable this is but it would certainly be useful. As with all good ideas, there’s a time and a place for it, use your judgement.