I remember in the old-school gaming days of SNES and Sega Genesis when graphics were limited to sprites and pixels. 3-D graphics are wonderful, of course, but I do miss the artistic aspects of the old days. I didn’t know much about the technical jazz behind all that until I read this article by Smashing Magazine, “The Mystery of CSS Sprites: Techniques, Tools and Tutorials:”

The term “sprite” (similar to “spirit,” “goblin,” or “elf”) has its origins in computer graphics, in which it described a graphic object blended with a 2-D or 3-D scene through graphics hardware. Because the complexity of video games has continually increased, there was a need for smart techniques that could deal with detailed graphic objects while keeping game-play flowing. One of the techniques developed saw sprites being plugged into a master grid (see the image below), then later pulled out as needed by code that mapped the position of each individual graphic and selectively painted it on the screen.

Sprites were displayed over a static or dynamic background image, and the positioning of the sprite was controlled simply by the hardware controllers. The term was coined because the sprites seemed to “haunt” the display and didn’t really exist in the graphic memory.

That’s pretty cool, and makes a lot of sense. Programmers back then were working with a very limited amount of resources, so having one big sprite map to save memory is pretty ingenious.

The article goes on to state that sprites continue to be used today in web design. It mostly came out of the need for an easier and more efficient alternative to Javascript rollover menus:

In 2004, Dave Shea suggested a simple CSS-based approach to CSS sprites based on the practice established by those legendary video games. In this case, multiple images used throughout a website would be combined into the so-called “master image.” To display a single image from the master image, one would use the background-position property in CSS, defining the exact position of the image to be displayed. Any hover, active or focus effects would be implemented using the simple definition of the background-position property for the displayed element.

When the page is loaded, it would not load single images one by one (nor hover-state images per request), but would rather load the whole master image at once. It may not sound like a significant improvement, but it actually was: the main disadvantage of the onMouse effects is that JavaScript-based hover effects require two HTTP requests for each image, which takes time and creates that unpleasant “flickering” of images. Because the master image is loaded with the whole page only once with CSS sprites, no additional HTTP requests are needed for hover, active or focus effects (because the image is already loaded), and no “flickering” effect occurs.

Consequence: CSS sprites reduce HTTP requests and the loading time of pages. This is the main reason why CSS sprites are often used on websites with heavy traffic, where millions of page impressions would need “only” a tiny fraction of what could otherwise be 30,000,000. Hence, CSS sprites are commonly used, particularly for navigation (such as for hover effects), icons and buttons.

This is way easier to implement and saves much overhead on the servers when serving millions and millions of views.

It then shows the sprite maps of some of the big web sites like Amazon, Google, and Apple. It is a very interesting look at the behind-the-scenes tricks of the trade of web design.

You can easily see how Apple uses this sprite map for its rollover navigation menu.

While Google’s sprite map may seem small and simplistic; really think about how many times those stars and other graphics are used on the site.

Using sprites comes down to using the background-position property of CSS. Instead of explicitly stating an <img> object, you would create a block-level element and its background-image and background-position CSS attributes. I decided to give it a whirl and implement it.

Nice little spirte map, huh? I pasted together my avatar images into one using GIMP. After a couple of hours of fiddling around with the CSS, I came up with this:

Here’s the HTML code:

<ul id="sprite">
    <li id="spritepanelA"><a href="#1"></a></li>
    <li id="spritepanelB"><a href="#2"></a></li>
</ul>

And the CSS:

#sprite { position: relative; }
#sprite li { padding:0; list-style:none; position:relative; top:0;}
#sprite li, #sprite li a { height:50px; width:50px; display:block; float:left; margin-right:10px;}
li#spritepanelA a { background:url(/wp-content/avatar_spritemap.png); background-position:0px 0px; }
li#spritepanelB a { background:url(/wp-content/avatar_spritemap.png); background-position:170px 0px; }
li#spritepanelA a:hover { background:url(/wp-content/avatar_spritemap.png); background-position:110px 0px; }
li#spritepanelB a:hover { background:url(/wp-content/avatar_spritemap.png); background-position:50px 0px; }

What really confused me was the second panel. I had to reverse the background-position of the regular link and hover aspect. I really couldn’t figure out why that was happening. Maybe I’ll discover it later. But in the end I got the effect I was going for. The hover links are all calling the same sprite map, and thus making a call to the server once instead of four times (two for the each link and the two more for each hover image.)

CSS spriting is a great little tool for web designers. It takes a little bit getting used to in order to figure out exact pixel positions on the maps, but in the end you get a way to effectively load pages just that much quicker.