@Alex – Excellent blog post. I had always just thought percentages were secretly laughing at me, now I see they actually make some sense. Bill Rehm beat me to the punch, mentioning how adding frames will solve the IE rounding problem.

Personally I wouldn’t even worry about using blank frames to achieve this if you’re doing an animation, why not just use the right amount of frames from the beginning when you’re thinking it out? There may be cases where you absolutely need to have 4 and only 4, but is an extra useful frame going to cause problems in 90% of the situations?

And if you’re just doing a hover image or something, then it won’t be so heavily scripted so a blank frame won’t add any extra complexity anyways.

I was desperately trying to figure out the term for this sort of effect, but only thought of it after the fact. It’s called the “parallax effect” and I originally saw it on the Silverback site. But oddly, I only stumbled across that site again after the fact. Still cool to look at in hindsight though.

I think that would be ok if it caused a general flicker or jitter in the animation, but the problem is the one pixel mis-alignment that is generated on the first loop becomes 2, 3 and 4 on each new loop. The result is the whole animation begins to slide off the top of the frame and back onto the bottom.

I don’t think it is a problem, as long as you make sure of the following points:
- round decimals properly … so 33.33 -> 33% and 66.66 -> 67%
- draw a 1px white/transparent border around the outside edge of each frame, so you will get a 2px white line between frames.

That seems to be solving the problem for me, but if you’ve got a concrete example where it isn’t working, post it and I’ll see if I can fix it!

If you’ve got a containing block that’s 500px wide and an image that’s 300px wide, that leaves 200px of white space. That is what you are divvying up.

That’s a clever way to think about it, Stevie. I like that.

The answer to the IE rounding problem? I would guess that putting white/transparent space between each of the coloured blocks would solve the problem – the block might be a pixel out when using IE compared with Ffx/Opera, but you wouldn’t get that unsightly line in the wrong colour.

I think that would be ok if it caused a general flicker or jitter in the animation, but the problem is the one pixel mis-alignment that is generated on the first loop becomes 2, 3 and 4 on each new loop. The result is the whole animation begins to slide off the top of the frame and back onto the bottom.

Unless you coded it to recalibrate on each pass (and you could) I can’t see it being viable.

If you’ve got a containing block that’s 500px wide and an image that’s 300px wide, that leaves 200px of white space. That is what you are divvying up.

If you set a value of 10%, that means 10% of the white space (=20px) will be to the left of the image (and 90% will be to the right), so the image is 20px in from the left. It’s a different calculation, but it gives you the same answer.

If you are looking at multiple sprites, think of the hidden overflow instead of the white space.

The answer to the IE rounding problem? I would guess that putting white/transparent space between each of the coloured blocks would solve the problem – the block might be a pixel out when using IE compared with Ffx/Opera, but you wouldn’t get that unsightly line in the wrong colour.

There are three viable methods available to control background-position, and you are not allowed mix and match them (i.e. background-position: top 50%;).

That was only true in css2 but css2.1 allows for keywords to be mixed and matched with percentages or pixels etc. It is prefectly valid to do this but some older browsers are still confused by it so its still best not to mix keywords into the mix. There really is no point anyway as the keywords equate exactly into eqivalent percentage sizes anyway.

There was a weird problem with the right and bottom borders; for some reason the effect of the background-position wrapped round at -100% so the background disappeared completely (unless repeat was specified for both axes but there are other reasons I didn’t want this!). I think it’s to do with the left:100% and top:100% positioning of those elements, in combination with the quirks of background positioning as described here. I worked around it by offsetting +100% instead which shifted onto the LAST sprite.

I’ve tested on IE6+7, FF, Opera9, Safari3, all fine.