When is it possible to use sprites ( and when not to)

Trying to derive a comprehensive list of when it is POSSIBLE to use sprites:

  1. Obviously, you can create a single sprite for all elements (and their states) with both fixed height AND width…
  2. or a sprite for all repeating elements with either fixed width OR fixed height , as long as teh different sprite segments are ordered on the perpendicular axis to their repeat and EQUAL the corresponding dimension of their intended element
    Can anyone suggest any more guidelines ?

You can create a single sprite, regardless of their size, by making lines of sequential graphics. One line for a type, another line for the next and so on. This way, the height won’t matter. Like this:

  • = #

_ - ~

’ " `

( ) { }

But, I guess, at some point, you need to draw the line and decide how many different types you’re going to keep in a sprite. Keeping in mind that not all graphics is going to be needed at all times.

Also, I usually opt for making several sprite files. I find that it’s more convenient to use relative positioning like left, right, top, bottom, center when I want to try different sizes for my elements and their graphics.

Using px sizes in main background declaration and in subsequent different states or sibblings CSS declarations, makes it harder to change and makes it prone to errors. So, if possible, I first try to rely on relative positioning of the graphics for sprites.


Usually I use 3 sprite versions.

a) Images that are a fixed width and height such as icons and other odd images.

These can be added to elements with fixed height and width but if you are adding them as backgrounds to existing elements then you have to make sure that the images are far enough apart so that other images are not shown.

I have see sprite images used for vertical navigation but on occasion the text in the nav has run to two lines and the next image on the sprite was shown in error (or when the text was resized). Therefore care needs to be taken when the element isn’t an exact fit for the sprite.

b) A horizontal sprite that allows for fixed width images that can be repeated on the y-axis. All need to be the same height.

c) Vertical repeating sprites for elements that have a fixed height but repeat along the x-axis. These need to have the same width.

If there are a lot of images on the page then I may split the sprites into groups to make it easier to maintain and keep track of but of course that defeats the object of the exercise in some cases so there is always some trade off in what’s best and what’s usable.

I am getting a feeling that for use as a repeating BG, efficient sprite building ( for tags that aren’t fixed height AND width) is mainly about grouping images of the same HEIGHT or images of the same width?

Yes in most cases its easier to control that way. You can use sprites with the images spaced out so that there is some leeway but if the element is fully fluid then there is a risk of overlap.

Have a look at some of the sprites on the larger sites around and you will see how they manage it.

Yes, I thought about spacing out the images in the sprites. But, since best resutls are achieved when using transparent spacing in the sprites it comes to making pngs or gifs that become rather large in file size.

I think where I was going nuts, was that I was trying to see if I could sprite horizontal or vertical tiles for dynamic elements…

As a definitive answer, you can definitely use sprites. Always.

The question is, do you need to place them all in a big sprite? No. Start making separate sprites as you need them, and keep them separate.

Then use an automated software to combine your separate sprites in bigger sprites in an easy manner. If it gets too complicated, don’t combine, keep it separate.

There is such a software, I don’t recall the name though.

I see what you mean but there is a point of diminishing returns.

  1. CSS3’s multiple background images make it difficult to work with a sprite… or at least make spites have to contain a small (2-4) images.

  2. if both the height and width of the element are variable.

  3. if you want the icon center vertically or horicontally

  4. If I have a very large PNG image and a very small PNG image for example. it seems very counter productive to merge them into a sprite as you get a lot of wasted transparent space…

But What was referring to originally was that sprites are easy to handle if you have an element that has attributes as {width:50px; height:50px;} . If I had an element that was {width:75%; height:50px;} and with the intent of adding it to a sprite I made a 50px high tile to use as a horizontally repeating background, I can only put it on a vertical sprite… which is now limited to be whatever the width of my tile was or it’s going to cause gaps

Also, In practical terms, it’s probably not a good idea to attempt to put the 2px X 200px page fade bg, and 2px x 10px “horiz drop shadow /border” on a sprite either

I see what you’re saying.

But you’re just reiterating what I’ve said:

  • Start making separate sprites as you need them, and keep them separate
  • Then use an automated software to combine your separate sprites in bigger sprites in an easy manner. If it gets too complicated, don’t combine, keep it separate

In other words, there are cases when the use of sprites it’s just not possible. By “definition” :slight_smile: What definition? A silly one: every image you have for your web page may qualify as a possible sprite. But some are dismissed from the get go.

We’re talking about the cases when the combination of different sprites is unfortunate. That means, the sprites in question, are not an abstract notion, but a reality. Those images/sprites are not singletons by nature. The focus is on their further combination “when is it possible (and when not to)”, right?

makes sense. I was just trying to make a decision outline … sort of condensed experience.

This example popped in my head. T

  1. taking care not to waste space, you can make make ONE sprite for all FIXED HEIGHT and WIDTH elements which contain ONE bg image.

  2. FIXED HEIGHT and WIDTH elements… a SINGLE sprite can be made to contain all 4 corners , but this sprite canon be combined with other sprites effectively

  3. FIXED HEIGHT OR FIXED WIDTH elements… TWO sprites need to be made to cover all 4 corners , two at a time . neither to be combined into larger sprites

  4. as stated by Paul:

b) A horizontal sprite that allows for fixed width images that can be repeated on the y-axis. All need to be the same height.

c) Vertical repeating sprites for elements that have a fixed height but repeat along the x-axis. These need to have the same width.

this works, but you have to take care about the efficiency…

for exampel if you could have had 5px X10px tile and 8px X 15px tile but now it has to be 300px 10px tile so that it matches the other 300px X 10px and 300px X 15px ( plus you are forced to use GIF or PNG to use transparency for the unused parts of the tile)… it’s becoming too much of mess to be practical.

BTW… a tangent question:
in cases when you want to just simply avoid the “flicker” and sprites are not an option… I ran into “CSS preloading” The method seem elegant and but dubious.

.button { background-image:url(on_button.png);background-image:url( button.png);}
.button:hover { background-image:url(on_button.png);}

I knew that i could overwrite a rule from the outside .class{ color:red; } then .class{ color:#000} but not from the inside. I guess I thought each CSS rule was executed at the end of the bracket. In other words if i had { color:red; color :pink; color:#000}… the UA only executes color:#000; as opposed to setting the color to red, then resetting it to pink and finally resetting it to #000. If this is the case does that mean the UA is actually doing a sever req for each image listed as a bg, and not just the final image that the bg is set to?

I think, besides a few basic rules, it’s pretty much from case to case. That’s why I advocate keeping images and sprites separate and use a software to glue them together in different ways, based on testing. That’s why I advocate to keep it simple and, when possible, use relative positioning values like top, left, center.

About the image preloading, there are html ways, css ways and js ways to do it. And been since a long time now :slight_smile:

Your example is not so good. The images should be in a sprite, and thus there is no need to preload the second one, since there is no second one. Your sprite will be loaded on the first call and be available for the second call. That’s the sprite logic and main goal.

But, for when there is a need, you can put images at the bottom of your markup, hidden. You can use redundant CSS declarations for a ghost or known element. Or you can use JS to acquire them before any use. Also at the bottom of your code/markup. So as not to hinder page rendering.

personally, I’d rather use sprites too, since it not only avoids the flicker but saves on the request but there are cases where

sprites are not an option…

.button in that case was meant to represent a ghost element, what I didnt realize is that you could use redundant calls… in another words I thought if you had 12 :over icons you had to preload, then you would need to have 12 SEPARATE and existing ghost or hidden elements to preload those images into

No that doesn’t work as the first background-image is simply overwritten by the subsequent rule and never actually gets loaded. If that was working then your stylesheets would crawl to a halt because all the images in all your stylesheet would be loaded when the stylesheet was called which could take days :). (I’m not sure if the multiple backgrounds of css3 may be an option for pre-loading images but I haven’t got around to testing that apsect yet - sounds like a job for someone with time on their hands :))

As a rule of thumb an image only gets loaded when its called for on the page (in most cases display:none won’t load an image either and possibly the off-left may not load an image either depending on how clever the browser is).

The best way to pre-load is to either use sprites or if the images are the same size and non transparent then just to stack them on top of each other. (e.g. over state goes in the parent and normal state in the anchor and then on hover make the anchor transparent. It’s quicker than sprites and there is no delay at all.)

You can find some good examples of sprites on smashing magazine or use a [URL=“http://spritegen.website-performance.org/”]sprite generator to automate the process.

Depending on the layout, on the way you manage sprites and depending on how many images you have to stack, I’d say sprites, in general, prove to be a better choice?

From a client-server point of view, individual stack images means metadata reads repeatedly. Sprites means metadata read once. If sprites file size doesn’t became so much bigger than the sum of all the individual images put in it, sprites have a clear advantage.

I, personally, don’t have neither many individual images neither one or two sprites. I keep image singletons separate, I don’t force a combination if it’s not easy to make.

Also, I make an individual sprite for images belonging to graphic effects on an element. Then, I think of ways to further combine sprites. Also, I don’t force a combination if not easy, not natural, or having drawbacks if resizing.

Preloading images: one thing I try not to use. But sometimes useful.