Glue is a simple command line tool to generate CSS sprites

by juanriaza • 15 years ago

163 32 15 years ago

Brajeshwar• 15 years ago

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.

chriseppstein2• 15 years ago

You should tell us what those limitations are :)

viroide• 15 years ago

wiradikusuma• 15 years ago

How is it compared to http://csssprites.org/?

splitbrain3• 15 years ago

csssprites is much more complicated to use but will take image alignments into account which makes it the more useful tool.

vidarh• 15 years ago

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).

giloux• 15 years ago

splitbrain3• 15 years ago

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.

ceejayoz2• 15 years ago

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

splitbrain3• 15 years ago

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.

krosaen• 15 years ago

cool! wondering how this differs from http://yostudios.github.com/Spritemapper

alpb• 15 years ago

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

zennit2• 15 years ago

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

zennit2• 15 years ago

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

baby• 15 years ago

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?

ceejayoz2• 15 years ago

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.

ryankshaw5• 15 years ago

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... ). for more info:

http://www.nczonline.net/blog/2010/07/06/data-uris-make-css-...

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.

afhof• 15 years ago

Caching is probably a good reason for using the sprite approach. Sprites are probably less dynamic than the HTML being generated, so the client will likely be able to just pull up the sprite from Cache.

ryankshaw5• 15 years ago

I am not suggesting putting data-uri's in the html, i am suggesting doing it in a css file. which would cache just as well as any sprite you may be using

tomjen3• 15 years ago

You limit the number of connections necessary to download the sprites, you avoid having the client 'hickup' in when you show a new button and you only have to have on cache-hit.

ryankshaw5• 15 years ago

again, I am not suggesting doing data-uri's inline in the html. I suggest doing it in a special css file. if done right, in which case the 'hickup' and and extra http requests would not happen.

justinph• 15 years ago

IE7 doesn't support data-URIs. If you still support IE7 (it's not dead yet), sprites are still your friend. Not to mention, data in the css can get kind of unwieldy if you're encoding many or large images. Keeping it in a sprite keeps it tidy.

ryankshaw5• 15 years ago

you can use mhtml for ie7, see: http://documentcloud.github.com/jammit/#embedding and search for "mhtml" in http://www.nczonline.net/blog/2010/07/06/data-uris-make-css-...

as far as keeping it simple, the sass file that I would write would look like:

  .icon {
    height: 16px;
    width: 16px;
    display: inline-block;
  }
  .checkmark-icon {
    @extend .icon;
    background-image: inline-image('path/to/checkmark.png');
    &:hover { background-image: inline-image('path/to/checkmark-hover.png'); }
  }
  .error-icon {
    @extend .icon;
    background-image: inline-image('path/to/error.png');
    &:hover { background-image: inline-image('path/to/error-hover.png'); }
  }

so you'd never have to manually update the sass file if the image changes and then you can just do some magic to get it to work with ie7 with mhtml if you are going to support it.

chriseppstein2• 15 years ago

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 :)

ryankshaw5• 15 years ago

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... )

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?

StavrosK• 15 years ago

I came here to say this. It seems that data URIs in CSS files is inherently more flexible, performs better and is easier to use (many libraries just handle it automatically for you).

I'm not sure about the slightly larger filesize, but it's worth it for the other benefits.

seanalltogether• 15 years ago

I don't think there is much gzip can do on the base64 representation of a png file, the data is already highly variable. So now all you've done is increase the load time as well as the cpu decompression time for all your sprites.

joshfraser2• 15 years ago

One of the things to consider when moving your images to CSS data URI's is that unlike images, CSS blocks the rendering of the page. While it's smart to move small images (think 4kb or less) to data URI's, bigger images should be kept separate. That way you aren't blocking the display of text or other elements on the page, while those larger images are being downloaded.

brainsqueezer• 15 years ago

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

pavel_lishin• 15 years ago

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

alexchamberlain• 15 years ago

Why? Would it not be simpler to do this before hand?

joshfraser2• 15 years ago

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.

Glue is a simple command line tool to generate CSS sprites

Related Stories