Where did we get those pixel values? Let’s break it down: the first value is of course the horizontal offset (from the left edge), and the second is the vertical.
Each vertical value is equal; since the master image is 400 pixels high and the after states sit in the bottom half, we’ve simply divided the height. Shifting the whole background image up by 200px requires us to apply the value as a negative number. Think of the top edge of the link as the starting point, or 0. To position the background image 200 pixels above this point, it makes sense to move the starting point -200px.
Likewise, if the left edge of each link is effectively 0, we’ll need to offset the background image horizontally by the width of all <li>s prior to the one we’re working with. So the first link doesn’t require an offset, since there are no pixels before its horizontal starting point. The second link requires an offset the width of the first, the third link requires an offset of the combined width of the first two links, and the last requires an offset of the combined width of all three previous links.
It’s a bit cumbersome to explain the process, but playing around with the values will quickly show you how the offsets work, and once you’re familiar it’s not all that hard to do.
So there you have it. Single-image CSS rollovers, degradable to a simple unordered list.

Buttons
There’s no reason why we have to leave the links touching each other, side-by-side as they were in the previous example. Image maps may be convenient in some spots, but what about separating each link into its own stand-alone button? That way we can add borders and margins, let the underlying background show through, and generally treat them as separately as we need to.
In fact, the building blocks are already in place. We really don’t need to modify our code too radically; the main change is in creating a new background image that doesn’t continue from link to link like the last example did. Since we can’t rely on the <ul> for placing the original background image, we’ll end up applying it to all <li>s instead and offsetting each the same way we offset the after states in the prior example.
With an appropriate image and a bit of spacing between each <li>, we’ve got buttons.
Note that in this example we’ve added 1px borders which, of course, count toward the final width of the links. This affects our offset values; we’ve compensated by adding 2px to the offsets where appropriate.

Irregular shapes
Up till now we’ve focused only on rectangular, non-overlapping shapes. What about the more complex image maps that image slicers like Fireworks and ImageReady export so easily? Relax, we’ve got you covered there too.
We’ll start the same way as the first example, by applying the background image to the <ul> and turning off list item bullets and setting widths and so forth. The big difference is where we position the <li>s; the goal is to surround each graphical element with a box that tightly hugs the edges.
Again, because of the ability to use absolute positioning relative to the top left corner of the <ul>, we’re able to precisely place our links exactly where we want them. Now all that’s left is to set up the hover states.
Worth noting is that in this case, a single set of before and after images wasn’t enough. Because of the overlapping objects, relying on only one after state would show pieces of surrounding objects’ after states. In fact, it would show precisely the pieces that fall within the link’s borders. (Easiest to just see it in action.)
How to avoid this? By adding a second after state, and carefully selecting which objects go where. The master image in this case has split the purple and blue objects into the first after state, and the green, orange and yellow objects into the second. This order allows boxes to be drawn around each object’s after state without including pieces of the surrounding objects. And the illusion is complete.

Benefits and pitfalls
A couple of final thoughts. Our new CSS Sprite method tests well in most modern browsers. The notable exception is Opera 6, which doesn’t apply a background image on link hover states. Why, we’re not sure, but it means that our hovers don’t work. The links still do, and if they’ve been labeled properly, the net result will be a static, but usable image map in Opera 6. We’re willing to live with that, especially now that Opera 7 has been around for a while.
The other concern is familiar to anyone who has spent time with FIR. In the rare cases in which users have turned off images in their browsers but retained CSS, a big empty hole will appear in the page where we expect our images to be placed. The links are still there and clickable, but nothing visually appears. At press time, there was no known way around this.
Then there’s file size. The natural tendency is to assume that a full double-sized image must be heavier than a similar set of sliced images, since the overall image area will usually be larger. All image formats have a certain amount of overhead though (which is why a 1px by 1px white GIF saves to around 50 bytes), and the more slices you have, the more quickly that overhead adds up. Plus, one master image requires only a single color table when using a GIF, but each slice would need its own. Preliminary tests suggest that all this indicates smaller total file sizes for CSS Sprites, or at the very least not appreciably larger sizes.
And lastly, let’s not forget that our markup is nice and clean, with all the advantages that go along with that. HTML lists degrade wonderfully, and a proper image replacement technique will leave the text links accessible to screenreaders. Replacing the sprite imagery is dead simple, since all of our dimensions and offsets are controlled in a single CSS file, and all of our imagery sits in a single image.
原文连接：http://www.alistapart.com/articles/sprites/