If you no longer support IE7, I think it's time to switch to data uris inlined in your stylesheets. It's easier to maintain, you don't have to care about image sizes, offsets and other annoyances with sprites, and it's trivial to implement as a part of your build process.
With data uris, you're putting the image data in your css file. This creates two performance differences to images.
Firstly, the user will download the image data even if it isn't used on the page, an external image is only downloaded if it's element is present & visible.
Secondly & more importantly, browsers completely block rendering while CSS downloads (with the exception of Opera, which unblocks after about 3 seconds), CSS does not render progressively. A 10k CSS file with 60k of imagery will load slower than a 70k CSS file due to HTTP overhead, although it'll be perceived faster as the user sees things happening after 10k rather than looking at a blank screen until the full 70k has downloaded. Small numbers, but noticeable on flakey wi-fi and mobile connections.
In terms of image size, when you base64 encode an image you're using 8 bits of data to represent 6. Gzip deals with a lot of this, but it's still an extra ~10% per image. That's compared to separate images, with a sprite image you get further benefits by sharing a PNG palette and compression across all sprites.
Neither sprites or data uris are the "correct solution" in all situations, it should be considered on a case by case basis. Sprite Cow itself uses both techniques, the toolbar icons are in a sprite, some smaller tiling assets are data uris.
Also I'd imagine the client may download the image multiple times if it's used in multiple CSS rules. Caching can probably also be hindered since mobile devices have limits on the size of JS/CSS they will cache and stuffing images in CSS can create large files.
Gzip will take care of the duplication bloat issue.
In general, this is a process best curated manually, with a maximum on converted file sizes and hand-picking images that are "must-haves" for the initial page load.
But if you separate the two CSS files. One only containing image sprite data uri's which is loaded AFTER the site's content you would not get such delays.
Some feedback: I get a message telling me to change my browser on iOS. You should display your normal front page with whatever value proposition, features, etc you have there so I can at least learn if I want to use your site whenever I do work on a normal PC.
I agree, that's good advice for platforms/devices that won't be able to run the app. For iOS the author doesn't have to do anything but wait.
The app gave you that message because Mobile Safari doesn't have a file picker. That'll change in iOS 6, which will be released within the next few months.
Exactly. I'm growing from an iPad and got this message:
"Sorry, it isn't working out between us
It's not you, I just can't get along with your browser. Maybe if things change in the future... maybe if you bring Chrome, Firefox, Opera or even IE10 to the party... not promising anything, but give me a call.
pass <canvas> element
fail File & FileReader
pass addEventListener on elements"
However, I still up-voted this article because of all the good suggestions other people added for good sprit generators.
As much as I'm using Compass to auto-generate sprites these days, this will definitely come in handy at random times in the future. Calculating coordinates and dimensions is such tedious work, I can't believe nobody came up with something like this 5 years ago! Great idea.
If you want a spritesheet generator that works ofline, the company I work for has open sourced a crazy fancy one, which is able to do things like take an entire directory and recursivly convert it into a single image with as little space lost as possible.
I don't remember if It comes with css output, but if not it should be really easy to plug it in as it was designed for that. It does come with an ant target. (http://opensource.cego.dk/spritemapper).
While we're on the subject of sprite tools, I threw this together recently for trying out the drag-n-drop and file APIs: http://spreet.ejlevine.com/
The primary benefit of this tool is that it automatically lays out your images for you and, since it's all client side, doesn't require you to share your images with an untrusted sprite generator.
This is a fantastic site and I used to use it a lot, the problem I find though is creating the initial sprite to use.
I found the following site a lot easier if you just export all the individual icons in bulk, it then auto generates the sprite and the positions needed for your CSS:
I'm a little surprised that this doesn't work for Safari on a Mac, and that it gave me a splash screen telling me as much instead of even giving me a "well, it's your ass..." notice. Especially considering that Chrome apparently works.
Unfortunately Safari doesn't support the FileReader APIs required to get image data out of the file. http://caniuse.com/#feat=filereader - as you can see Safari is lagging behind here
Great app, I'm sure I'll be using it. However, when I clicked on Pick Background and selected a transparent area Firefox crashed! (using the example image)
Congratulations, you have managed to provide a two second delay between clicking on, for example, the Firefox icon and the resulting sprite CSS being displayed on a brand spanking new eight core, 8GiB RAM system. I hope you're proud of your abuse of my computer's resources. But, alas, I shall be having no more of this nonesense!
Christ, you act like you're doing someone a favor running this tool that was built to help you save time. Let me guess, you're the guy who bitches when the WiFi is down on the airplane.
We will no longer have to deal with all this BS once browsers implement CSS3 image values. (http://www.w3.org/TR/css3-images/) Syntax would be like: `background-image: image('sprites.png#xywh=40,0,20,20');` Share single image across your site/stylesheets. No need to set a fixed width/height. No background-repeat restrictions etc
This is great, I spent hours dicking around with CSS sprites for back/forward arrows last week. It was a pretty frustrating waste of time. Every time I wanted the element to be wider I had to go back and redo the sprites. I guess I'd still have to do that here, but it takes away a lot of the pain.
There are a bunch of tools available:
https://github.com/nzakas/cssembed
https://github.com/cloudhead/less.js/wiki/Include-Data-URI-B...
http://compass-style.org/reference/compass/helpers/inline-da...