No sooner had I added Dave Shea's (of CSS Zen Garden and mezzoblue fame) excellent (if somewhat dated) CSS Sprites ALA article to my CSS resources category, then what does he go and do?
Too Late Again
You guessed it, he publishes a follow-up article. The reason I went looking for it in the first place, or rather found it to be the best write-up on the topic, was not so much the how, but the why of using this technique. But he kind of missed the point. Sure, he explains the ins and outs and a bit of the history of sprites, but for my money the single best reason to consider using the technique is a huge reduction in the number of HTTP requests you serve up when storing a bunch of similar iconic images from one master file. Better still, once the browser downloads the aggregate file and caches it, it's a simple matter of some integer offset math to display only that portion you need as a background image in your documents.
Sprites in a Nutshell
Basically, the technique involves creating one or more fixed-sized, block-level elements with ids or classes to be used as selectors in your stylesheet, set the display property to absolute, but relative to some other containing element, say a <ul> with <li> descendants, and then use the top, right, bottom and left values of the background-position property as needed to offset that portion of the image you want revealed. Kind of like a peephole onto a larger canvas. The nice thing is you can move the canvas (the parent element) around with margins or other positioning methods, and the child elements follow right along like a duck and her little ducklings.
CSS Sprites Redux
The latest version of the article takes the technique a step further by introducing some animation effects via John Resig's outstanding jQuery JavaScript library. But Dave misses the original point again, which I found ironic after he warns his audience that using jQuery imparts a certain overhead when downloading the library for the first time.
Ajax Libraries API
However, I did learn something very interesting—Google Code is now hosting jQuery as part of their Ajax Libraries API project—allowing you to link to the library without having to host it yourself. This has two benefits: it saves you a little bandwidth, but more importantly, if enough developers are doing this then chances are your visitors already have a copy of jQuery cached locally. You can also take advantage of the Google CDN if you're using Prototype, script.aculo.us, MooTools/moo.fx, or Dojo. It would be really sweet if Google started hosting some of the more popular jQuery plugins.
google.load()
Personally, I don't understand the advantage of using the google.load() method unless your project involves using their Maps, Search, or Ajax Feed APIs. Why not just load the library and start using jQuery (or whatever) like you normally would?
<script type="text/javascript"
src="http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js"></script>
<script type="text/javascript">
// when the DOM is ready
$(function() {
// fire away
$('#selector').method({
// ...
});
// ...
});
</script>
Related Reading