

Glue is a simple command line tool to generate CSS sprites - juanriaza
https://github.com/jorgebastida/glue

======
ryankshaw
so I am actually wondering why you would even still use a spriting based
approach. It seems as if a data-uri based approach would, for all uses I can
think of, be more flexible and better, especially if you are using something
like compass ( [http://compass-style.org/reference/compass/helpers/inline-
da...](http://compass-style.org/reference/compass/helpers/inline-data/) ). for
more info:

[http://www.nczonline.net/blog/2010/07/06/data-uris-make-
css-...](http://www.nczonline.net/blog/2010/07/06/data-uris-make-css-sprites-
obsolete/)

this stack overflow answer brings up 2 possible drawbacks of a data-uri based
approach: <http://stackoverflow.com/a/3525961/897583> but it seems like if you
are worried about your other css rules being blocked by your data-uri
background-images, either put them in a css file that loads after your
important rules, or just put them at the bottom of the css file. and it seems
like with gzip the increase in size is negligible.

~~~
chriseppstein
The number of bytes in a sprited file can be smaller than the sum of the bytes
of each file individually. So the best option might be to inline the sprite :)

~~~
ryankshaw
so chriseppstein, I would be interested in what you (as the creator of
compass), in particular, have to say about which would be better: a "Compass
Sprite" ( <http://compass-style.org/reference/compass/helpers/sprites/> )
based approach or a compass "inline-image" based approach ( [http://compass-
style.org/reference/compass/helpers/inline-da...](http://compass-
style.org/reference/compass/helpers/inline-data/) )

edit: oh, so i didn't fully grasp what your comment was saying. are you
suggesting that you would use inline-image AND a sprite to put all the images
into a sprite AND load that sprite inline with the css?

------
joshfraser
One thing to keep in mind when generating sprites is cachability and the
various paths that people will take through your site. You should consider the
probability of those sprited images being served together on a page. I've seen
people blindly sprite all their images on their site, even if only a small
percentage of those images are used on a key landing page. This can cause a
bad first impression with a slower experience than necessary. Worse still,
I've seen people create a separate sprite for each page on their site and
complete lose the benefits of local browser caching. While this might look
good on a single WebPageTest, it's terrible for your overall performance. A
good method is to identify your top landing pages, then look at which images
always appear together and might make sense to be sprited. Keep in mind, if
they are small and are included on every page, it may make sense to use a data
URI instead. You'll also want to make sure to sprite your images in the same
order vertically that they appear on the page to allow for progressive
loading.

------
splitbrain
This makes no sense to me. It assumes that I'll attach the icon to it's own
HTML element because it sets the width and height explicitly. Adding icons to
your links won't work this way.

Generating useful sprites is much harder than this guy thinks IMHO.

~~~
ceejayoz
Sprites are used for a lot more than just adding icons to links.

~~~
splitbrain
Adding icons to links was just one example. If you're coding semantic correct
HTML you very rarely have background images that are exactly the size of your
HTML element. The way that glue generates sprites makes them only useful for
when you're replacing img tags.

------
Brajeshwar
Checking it out.

This should be interesting. CSS Spriting was made way manageable with Lemon, a
Compass plugin which later became part of Compass Sprite.

The few limitations on the part of Compass Sprite, had always let me do my own
sprite, I usually like those tightly packed image sprites.

~~~
chriseppstein
You should tell us what those limitations are :)

------
baby
I don't get the sprite thing. How is it better for optimization to load every
single image of the website right away, and to reload the same picture when
the image is modified?

~~~
ceejayoz
For lots of tiny images like icons, you're often better off loading one 200kb
image than 100 2kb images. HTTP requests have significant overhead.

------
krosaen
cool! wondering how this differs from
<http://yostudios.github.com/Spritemapper>

~~~
alpb
good point, spritemapper seemed more confusing although it gives you a fine
tuning it lacks the simplicity.

------
wiradikusuma
How is it compared to <http://csssprites.org/>?

~~~
vidarh
Where Glue generates the CSS for you, csssprites seems to expect you to first
add all the sprites as backgrounds to the CSS rules you want to use, and then
annotate them with comments and then process your CSS to replace those rules
with suitable rules.

Glue on the other hand generates the CSS for you, but expect you add a CSS
class to the elements that should contain the sprites (or you can modify the
generated CSS of course).

------
zennit
sprite-factory also works with guard
<https://github.com/christopherhein/guard-sprite-factory>

------
brainsqueezer
PHP users. I'm looking for something like this in PHP. Anyone?

~~~
pavel_lishin
It doesn't seem like it would be terribly difficult to port to PHP; why not do
it yourself?

------
zennit
what about <https://github.com/jakesgordon/sprite-factory>

------
giloux
+1

------
viroide
+1

