Glen Lipka wrote:
Let's start at the beginning. Let's assume (work with me here) that
autogeneration of sprites and css is the path to ruin.
Actually, I don't agree with this statement. Auto-generation get you the
sprite and positioning css, which is nice, and is useful. One of the
primary benefits though is automation -- a consistent, theoretically
error free management of the process.
It's the same reason people prefer to automate build processes. Take the
chance of tedium induced errors out of the equation.
Let's assume 100 images should be manageable in a very easy way. (When
you add new images it should take under 3 minutes to update things)
Okay.
Here a beginning...
http://www.commadot.com/jquery/hoverSprite.php
Structure is everything. When you set up a good architecture,
maintenance is easy.
So, basically we have a large grid structure with a single image in each
cell. Since the grid is statically sized, we have a fixed offset to
apply for the hover effect.
So far in the demo I have.
1. Images are variable size, currently width is variable, if height is
variable that is fine, but I would like to see the range of possible
heights/widths.
2. Some are hoverable and some not. I use the "canHover" class and the
"button" class in tandem to achieve the right selection.
This approach clearly makes the markup cleaner, and makes the hover js
simpler as well. I haven't run any performance metrics, but I'd suspect
this approach is quicker, but the difference is probably not user
noticeable, even on 100's of images.
So we now have a cleaner coded solution, but have lost the benefit of
automation, and with it incurred a larger testing effort, every time an
image is added/removed. In our case I'm not sure this is an appropriate
trade-off, given the relatively small amount of code simplification we
gained.
Look at the source and go slow. I am sure this doesn't scale for some
reason. Show me the images to add and I will show you how it scales.
I think it does scale, although at some point there's going to be an
overhead due to the 'whitespace' around the smaller images. PNG seems to
do pretty well at compressing this though, so a few k at the most.
PS. This technique works for a sprite I manage. Rows: 80, Cols: 8.
Its gigantic and super easy to manage.
Thanks for sharing your approach -- it certainly helped me think some
things through, and it's always good to bounce the idea around for a
sanity check.
Oh, and I did realize a fundamental assumption I made way early on. For
some reason I decided that the initially combined over/out sprites
needed to be separated in order to use the large sprite idea. Not true.
In fact keeping the over/out sprite combined as a single image, and
merging that image into the larger sprite would have opened another
option, of simply off-setting the initial image by the image width (or
height depending on how the over/out sprite was stacked).
~ ~ David
