Live data from Hacker News

Glue is a simple command line tool to generate CSS sprites

github.com

31–34 of 34 posts

Re: Glue is a simple command line tool to generate CSS sprites

#31

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 bring…

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.

Re: Glue is a simple command line tool to generate CSS sprites

#33

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 bring…

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.

Re: Glue is a simple command line tool to generate CSS sprites

#34
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.
Post reply on HN