Starter notes for using sprites and SmartSprites
1,525 views
Skip to first unread message
ericmic
Sep 4, 2010, 7:36:56 PM9/4/10
to SmartSprites CSS Sprite Generator Users and Developers
As I was learning how to use SmartSprites and sprites in general, I
kept notes of the things to learn. Maybe these will be useful for
some others...
Starter Notes for Using Sprites
Spriting tools lay out the images either in a row horizontally or
stacked vertically in the combined sprite image (CSI, for lack of a
better acronym).
Non-repeating background images:
If a non-repeating image fills its element, it doesn't matter whether
it's stored in a horizontal CSI or a vertical CSI. In fact, these
images could be stored in a 2d tiled CSI.
But if an image doesn't fill its element (commonly for images that are
explicitly top/right/bottom/left aligned), then you either have to (1)
store it so there are no other images next to it in the dimension that
is unfilled, or (2) leave a (transparent) space in the CSI between it
and the next image where the space is big enough to fill the unfilled
area. This second option isn't feasible for liquid layouts where you
don't know the dimensions of some elements, so perforce separate
sprite files are required with horizontal and vertical layouts.
Another variation is for right-aligned images, where by design it
overfills its element (as is done with liquid layouts, making it more
than wide enough to accomodate any screen width that comes up). Since
such images must be right-aligned, they have to be the right-most
image in a CSI. If it's not repeating, there's no problem putting it
in a vertically stacked CSI, except by nature it will likely be wide
and might therefore make the vertical CSI very wide.
Repeating background images:
Repeating images are much trickier. If a background image is to y-
repeat (repeat vertically) then the CSI can't put any other images
above or below it or those other images will appear as part of the
repetition. So a y-repeating image must be stored in a horizontally
laid out CSI. Similarly for an x-repeating image.
But it's more complicated than that. If there's any space btn the end
of a repeating image and the edge of the CSI, that empty space will be
part of the repeating image too. So the repeating image has to be
repeated WITHIN the CSI so it fills it out to the edge of the CSI, and
therefore the CSI may have to be extended to accommodate an integral
multiple of the repeating image width (if it's not just 1-wide).
Further if there are multiple such repeating images, the CSI width
must equal the LCM (lowest common multiple) of all repeating images.
E.g. suppose one y-repeating image is 2 pixels wide and another is 3
pixels wide. For neither of them to have a blank area after them in
the CSI (ie for both of them to go to the end of the CSI), the 2px
image will have to be repeated 3 times in the CSI and the 3px image
will have to be duplicated 2x, with the CSI then being 6px wide. Note
that if all the repeating images are just 1-wide (or high) then all
this isn't an issue b/c the CSI will just be 1-wide/high then.
SmartSprites automatically handles this image repeating with its
background-repeat attribute.
Non-repeating images which are shorter than the repeating ones could
be in the same file, but if they're longer, then the repeating ones
have to be duplicated to an LCM that's longer than the longest non-
repeating image. Not impossible, but maybe not worth it.
Fluid repeating images
Trickiest are repeating backgrounds for liquid layout elements. In
general, these CANNOT be sprited. Because they're repeating, they
can't have other images next to them in the repeating direction in the
CSI (as above for repeating images), but because they don't fill their
element in the non-repeating dimension (because it's a liquid layout)
they also can't have any other images next to them in the non-
repeating direction (as above for images that don't fill their
elements). So such an image could be the last image in a CSI, but
otherwise they have to be in a separate image file.
The one exception to this that I see so far is if another element
overlays the liquid part so it doesn't matter if other images within
the CSI are being drawn along with the visible part. The container
presumably will have explicit left/right/top/bottom alignment to get
the browser to properly align its image, which is presumably a border
around the interior element (a common way to do liquid layouts). For
"right" or "bottom" alignments (eg right-side or bottom borders for
liquid elements), the css background-position must be set to
"right"/"bottom" (or 100%) to get the browser to line up the right/
bottom side of the image with the right/bottom side of the element.
This has a couple of important implications:
1) there can only be 1 right-side fluid repeating image in a CSI since
with 100% you're telling the browser to line up the right edge of the
CSI with the right edge of the element and obviously there can only be
one image at the right edge of the CSI. Note that a right-side fluid
repeating image will be stored in a horizontally laid out CSI (as are
all y-repeating sprites) and will therefore be the right-most image in
the CSI. A bottom-side fluid repeating image will be stored in a
vertically laid out CSI (as are all x-repeating sprites) and will
therefore be the bottom-most image in the CSI. Note that SmartSprites
doesn't allow you to control the order of sprites in the CSI so you
may have to adjust the order of css specifications in the css file to
get the right-aligned image rightmost in the CSI.
2) the background-position attribute for such a right/bottom fluid
repeating image has to be manually modified from the SmartSprites
insert. SmartSprite sets it to a numeric pixel value and this has to
be changed to explicitly "right" or "bottom" (or 100%). In my css
file, just deleting the SmartSprite attribute line works, since the
originally set attribute is still present above it.
kept notes of the things to learn. Maybe these will be useful for
some others...
Starter Notes for Using Sprites
Spriting tools lay out the images either in a row horizontally or
stacked vertically in the combined sprite image (CSI, for lack of a
better acronym).
Non-repeating background images:
If a non-repeating image fills its element, it doesn't matter whether
it's stored in a horizontal CSI or a vertical CSI. In fact, these
images could be stored in a 2d tiled CSI.
But if an image doesn't fill its element (commonly for images that are
explicitly top/right/bottom/left aligned), then you either have to (1)
store it so there are no other images next to it in the dimension that
is unfilled, or (2) leave a (transparent) space in the CSI between it
and the next image where the space is big enough to fill the unfilled
area. This second option isn't feasible for liquid layouts where you
don't know the dimensions of some elements, so perforce separate
sprite files are required with horizontal and vertical layouts.
Another variation is for right-aligned images, where by design it
overfills its element (as is done with liquid layouts, making it more
than wide enough to accomodate any screen width that comes up). Since
such images must be right-aligned, they have to be the right-most
image in a CSI. If it's not repeating, there's no problem putting it
in a vertically stacked CSI, except by nature it will likely be wide
and might therefore make the vertical CSI very wide.
Repeating background images:
Repeating images are much trickier. If a background image is to y-
repeat (repeat vertically) then the CSI can't put any other images
above or below it or those other images will appear as part of the
repetition. So a y-repeating image must be stored in a horizontally
laid out CSI. Similarly for an x-repeating image.
But it's more complicated than that. If there's any space btn the end
of a repeating image and the edge of the CSI, that empty space will be
part of the repeating image too. So the repeating image has to be
repeated WITHIN the CSI so it fills it out to the edge of the CSI, and
therefore the CSI may have to be extended to accommodate an integral
multiple of the repeating image width (if it's not just 1-wide).
Further if there are multiple such repeating images, the CSI width
must equal the LCM (lowest common multiple) of all repeating images.
E.g. suppose one y-repeating image is 2 pixels wide and another is 3
pixels wide. For neither of them to have a blank area after them in
the CSI (ie for both of them to go to the end of the CSI), the 2px
image will have to be repeated 3 times in the CSI and the 3px image
will have to be duplicated 2x, with the CSI then being 6px wide. Note
that if all the repeating images are just 1-wide (or high) then all
this isn't an issue b/c the CSI will just be 1-wide/high then.
SmartSprites automatically handles this image repeating with its
background-repeat attribute.
Non-repeating images which are shorter than the repeating ones could
be in the same file, but if they're longer, then the repeating ones
have to be duplicated to an LCM that's longer than the longest non-
repeating image. Not impossible, but maybe not worth it.
Fluid repeating images
Trickiest are repeating backgrounds for liquid layout elements. In
general, these CANNOT be sprited. Because they're repeating, they
can't have other images next to them in the repeating direction in the
CSI (as above for repeating images), but because they don't fill their
element in the non-repeating dimension (because it's a liquid layout)
they also can't have any other images next to them in the non-
repeating direction (as above for images that don't fill their
elements). So such an image could be the last image in a CSI, but
otherwise they have to be in a separate image file.
The one exception to this that I see so far is if another element
overlays the liquid part so it doesn't matter if other images within
the CSI are being drawn along with the visible part. The container
presumably will have explicit left/right/top/bottom alignment to get
the browser to properly align its image, which is presumably a border
around the interior element (a common way to do liquid layouts). For
"right" or "bottom" alignments (eg right-side or bottom borders for
liquid elements), the css background-position must be set to
"right"/"bottom" (or 100%) to get the browser to line up the right/
bottom side of the image with the right/bottom side of the element.
This has a couple of important implications:
1) there can only be 1 right-side fluid repeating image in a CSI since
with 100% you're telling the browser to line up the right edge of the
CSI with the right edge of the element and obviously there can only be
one image at the right edge of the CSI. Note that a right-side fluid
repeating image will be stored in a horizontally laid out CSI (as are
all y-repeating sprites) and will therefore be the right-most image in
the CSI. A bottom-side fluid repeating image will be stored in a
vertically laid out CSI (as are all x-repeating sprites) and will
therefore be the bottom-most image in the CSI. Note that SmartSprites
doesn't allow you to control the order of sprites in the CSI so you
may have to adjust the order of css specifications in the css file to
get the right-aligned image rightmost in the CSI.
2) the background-position attribute for such a right/bottom fluid
repeating image has to be manually modified from the SmartSprites
insert. SmartSprite sets it to a numeric pixel value and this has to
be changed to explicitly "right" or "bottom" (or 100%). In my css
file, just deleting the SmartSprite attribute line works, since the
originally set attribute is still present above it.
Stanislaw Osinski
Sep 5, 2010, 7:41:59 AM9/5/10
to SmartSprites CSS Sprite Generator Users and Developers
Hi Eric,
Excellent notes, thanks for sharing them! I've added a link to this
thread to SmartSprites website, so that others have a chance to read
them too.
> Non-repeating images which are shorter than the repeating ones could
> be in the same file, but if they're longer, then the repeating ones
> have to be duplicated to an LCM that's longer than the longest non-
> repeating image. Not impossible, but maybe not worth it.
Actually, SmartSprites does that (https://fisheye3.atlassian.com/
browse/carrot2/labs/smartsprites/src/org/carrot2/labs/smartsprites/
SpriteImageBuilder.java?r=HEAD#l278). Otherwise, it would happen quite
frequently that a wide/tall individual image gets clipped by a pixel
or two if the same sprite contained e.g. a 3-pixels wide/tall repeated
image whose width/height happened not to be equal modulo 3 to the
width/height of the wide/tall one.
Cheers,
Staszek
Excellent notes, thanks for sharing them! I've added a link to this
thread to SmartSprites website, so that others have a chance to read
them too.
> Non-repeating images which are shorter than the repeating ones could
> be in the same file, but if they're longer, then the repeating ones
> have to be duplicated to an LCM that's longer than the longest non-
> repeating image. Not impossible, but maybe not worth it.
browse/carrot2/labs/smartsprites/src/org/carrot2/labs/smartsprites/
SpriteImageBuilder.java?r=HEAD#l278). Otherwise, it would happen quite
frequently that a wide/tall individual image gets clipped by a pixel
or two if the same sprite contained e.g. a 3-pixels wide/tall repeated
image whose width/height happened not to be equal modulo 3 to the
width/height of the wide/tall one.
Cheers,
Staszek
Reply all
Reply to author
Forward
0 new messages