3 ms·

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,

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-data/ http://compass-style.org/reference/compass/helpers/inline-da... ). for more info: http://www.nczonline.net/blog/2010/07/06/data-uris-make-css-sprites-obsolete/ 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 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 15y 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.
- ryankshaw 15y 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 15y 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.
- ryankshaw 15y 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 15y 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.
- ryankshaw 15y ago
  you can use mhtml for ie7, see: http://documentcloud.github.com/jammit/#embedding http://documentcloud.github.com/jammit/#embedding and search for "mhtml" in http://www.nczonline.net/blog/2010/07/06/data-uris-make-css-sprites-obsolete/ 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.
chriseppstein 15y 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 :)
- ryankshaw 15y 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/ 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-data/ 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?
- deleted 15y ago
  [deleted]
StavrosK 15y 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 15y 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.
joshfraser 15y 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.

afhof 15y 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.

ryankshaw 15y 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 15y 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.

ryankshaw 15y 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 15y 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.

ryankshaw 15y ago
you can use mhtml for ie7, see: http://documentcloud.github.com/jammit/#embedding http://documentcloud.github.com/jammit/#embedding and search for "mhtml" in http://www.nczonline.net/blog/2010/07/06/data-uris-make-css-sprites-obsolete/ 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.

chriseppstein 15y 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 :)

ryankshaw 15y 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/ 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-data/ 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?
deleted 15y ago
[deleted]

StavrosK 15y 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 15y 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.

joshfraser 15y 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.