Hacker News new | past | comments | ask | show | jobs | submit login

Jammit is a Rails plugin and command-line tool that uses this technique, along with MHTML for IE 6 & 7, and compresses JavaScript as well.

http://documentcloud.github.com/jammit/

The big advantage here over spriting is not having to deal with the complexities of trying to jam repeated background patterns into sprites, and having to compute pixel offsets for your CSS rules. You can just write your CSS as you normally would, and have the plugin generate appropriate versions of your stylesheets before deploying.

If you'd like to see a demonstration of the speed difference it can make, here's a page that loads 100 small individual images:

http://jashkenas.s3.amazonaws.com/misc/jammit_example/normal...

And here's the same page, using a single CSS file with data-URIs for all the images.

http://jashkenas.s3.amazonaws.com/misc/jammit_example/jammit...




Considering CSS sprites were something that dhh mentioned as putting into Rails 3.1, maybe you should see if you can just get that moved into Rails core, before the sprites work starts.


Great suggestion. I presume they'll want to roll their own solution (hopefully taking advantage of existing gems like ruby-yui-compressor and closure-compiler). But I'll open a ticket for it.


> I presume they'll want to roll their own solution

I have yet to contribute to rails-core, but generally, they don't accept feature requests, they only accept patches. Even if you end up replacing the 'back end' of it with something else, maybe your code would give the feature a head start.


The demonstration of speed difference is bogus. Really we should be comparing Jammit vs Sprite load time. Of course 100 files will take longer to load than 1 file!!! But how about 1 extra sprite vs Jammit? Here's a demo:

http://autocomplete.s3.amazonaws.com/sprite_example.html




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: