So, I’ve embarked on a new mini project. It is kind of inspired by image sprites.
Image sprites are a great idea, but come with a whole bunch of issues that make them a bit of a pain to work with.
Firstly, most of the time you have to use markup to create an element in html to “hold” the image you wanted to display from your sprite. This is because if you actually set a sprite as the background image for a large html element you’re likely to see other images in the sprite as well. Because of this, you actually lose useful functionality that CSS gives you, like the ability to position, repeat and scale an image. Also, the markup you’ve created to hold the image exists for style purposes, which is bad.
Secondly, sprites can be a massive ball ache to maintain. If you’ve closely packed your images in a sprite for maximum efficiency and then one of your images needs to change size, you’re either going to have to move ALL images surrounding the image you have to update (and obviously then change all background-position properties for the images you’ve moved) or leave a space and put the updated image in a new position in your sprite.
How do you know which images in a sprite are used and which ones are dead? Since your images are referenced by coordinates, this sort of clean up becomes a nightmare and is actually a bit lot of a nightmare to create image sprites in the first place.
The goals of the project are to
- Reduce the number of http requests (and their associated header traffic) to the server and hence reduce the time it takes to load all images on a website and bandwidth footprint the site requires
- Create a solution that’ll alleviate some of the problems surrounding the creation and use of image sprites
- Do something cool
The JSIO project website has a pretty good explanation of how it works so I won’t bore you with the details here. However, as a brief overview, it packages all your image data in data uri format and you reference particular images by their filename rather than their coordinates.
The site actually uses the HTML5 file api to generate your resources file for you, which makes creating and maintaining your JSIO “sprite” really really easy.
I read *somewhere* that data uri encoded images can be up to 1/3 larger than corresponding image files, however with gzip encoding they can be only 0-3% larger (or less). My thesis is that for a site with many small images, JSIO could be more efficient and easier to maintain than having separate files or even an image sprite.
…I’m yet to prove or disprove this and I’ll be conducting some tests whose results I’ll post up here (even if they do prove JSIO to be useless).
Disclaimer: This is the first ever ALPHA release of JSIO – it works on the latest Firefox and Chrome but I haven’t even checked it in IE yet. It probably won’t work in IE yet. Also, the website needs some work for optimal display on mobile devices.