the future of css sprites

In my previous article I talked about the pros and cons of sprites and how to apply them with current technology. Sadly these methods are far from perfect, so let's look ahead and try to find out what the future will bring us to improve the use of sprites. Additionally, I'll also try to work out an ideal way of handling sprites along the way.

The examples below will all assume that the sprite grid is 8x8px big, which is the value you'll see popping up in the css code examples.

method 1: improved css background-position property

a {background-position:right -8px bottom 0px;} a:hover {background-position:right 0px bottom -8px;}

If you remember the new proposition for the css background-position property, you'll know that we will be able to position css background images from all four sides in the future. We can use that to hide part of our sprite from view in all four corners of our element. While this sounds great, there are still some limitations to this method.

If you look at the image above (section 1) you'll see that I included two sprites. The upper sprite works for the upper left and lower right corner, the lower sprite for the upper right and lower left corner. Sadly there is no way around as you'll notice it is impossible to hide the upper left image in the bottom sprite from view if you want to apply it in the bottom right corner of your element. (You might want to read that sentence twice and add some arm movements if needed.)

So while the new background-position spec is definitely helpful, it's hardly perfect for good sprite use.

method 2: css background rotation

a {background-position:left -8px bottom 0px;} a:hover {background-transform:rotate(180deg);}

To reduce the unused space within the first two sprites and to make our css a bit more flexible, I came up with a different approach. Wouldn't it be cool if we could just rotate our css background? Imagine the possibilities. No more separate images for each rounded corner, you could just cut one and rotate it 90° for each successive corner.

It could also help us with our sprite problem described above. If we set the image correctly on our element we can simply rotate it 180° to show the other image. It does require some extra hassle when creating the sprite and like the first method you can't use one single sprite to cover the left and right side of your element, but the css is a little more flexible as the specific rules (ie. 8px) are reduced to one simple occurrence instead of two, which makes it easier to change your sprite afterwards.

The css syntax is taken from the good people of Safari who are currently implementing transform actions on html element, though I believe there's no word on transforms for the css background property. Still, using sprites like this is still not all too handy and too focused on what the good css people are preparing for the near future.

method 3: inventing the background-crop property

a {background-crop:0px 0px 8px 8px} a:hover {background-crop-origin:8px 0px;}

All we really need is a background crop function. A property that lets us crop a certain part of a selected images and only shows that part. If you think about it, that's exactly what you want to do with a sprite. Safari has already developed a css mask, but that only works on html elements and doesn't crop away the rest of the element.

The above css is pretty much invented nonsense but indicates what we should be able to do. You set an origin point (the upper left corner of the area you'd like to crop) which are the first two values, then you set your grid (8px along the x-axis and 8px along the y-axis), creating a rectangle of 8x8px. By doing that, if you manage your sprite well, you should only need to reposition your origin point to show the wanted image, occasionally changing the grid for bigger (or smaller) images.

This is hardly a proposed syntax but does demonstrate the idea about the crop property as far as sprite use is concerned. It would make working with sprites so much easier, to the point where you could easily turn your sprite into an actual skin. I said before that I don't like working with 2000x2000px images, but if they'd contain all graphical elements used in one single site that would surely beat having 50-60 separate images in your image folder that need to managed and named separately.

conclusion

Even though some interesting improvements are going on at the moment, there isn't really anything that will make working with sprites as flexible as should be. Since sprites are pixel based there's really only one way to go about them and that's to crop the correct part and just show that. Maybe I've overlooked something (which is definitely possible) and work is already underway on a similar feature, but if not, it would be great to have something like this in our arsenal in the (near) future.

mozilla to the rescue

I received note of a very interesting development within the Mozilla css community, where a very similar feature is already implemented, doing exactly what I was asking for. You can read up on the moz-image-region css property yourself, but it's safe to say that when it finds its way into the official css standards, sprites will be outdated and skins will be all the rage.

Thanks goes to Boris Zbarsky for notifying me.