Hacker News new | past | comments | ask | show | jobs | submit login
CSS Sprites Revisited (smashingmagazine.com)
21 points by joeyespo on April 27, 2012 | hide | past | favorite | 9 comments



The comments in this post really demonstrate the widespread pain points that everyone has when dealing with CSS sprites, and the existence of 30+ solutions indicates that nobody has really figured out how to fix it yet.

The lack of attention to SVG stacks (http://simurai.com/post/20251013889/svg-stacks) is very curious to me - being a proponent of this method/movement seems analogous to being pro-PNG in the era of GIFs.


That's glorious :o I've only recently begun messing around with SVGs, but it seems the more I use them, the more amazing they become.

That said, I really do wish there was better browser support for them. Having to embed them as objects instead of images, for example, is a tad bit lame :/ And then you're still left with anything before IE9 (I think?) unable to see them. On the mobile-end, the same goes with anything before Android 3... Or weird buggy behaviour when you're applying things like hover effects to parts of the image, etc...

It's definitely promising though


The ideal sprite system is one that is automated. A script that grabs all the images in a folder and makes a sprite, recording their position and name and then replacing the Less (or Sass) variable definition for each image with the stored value.

Doing this manually is insane and probably not worth it unless you're fielding requests like Facebook, Google or Amazon and every split second spent loading is lost money.


Compass will create your sprite sheet for you and give you all the classes you need to use them.

http://compass-style.org/help/tutorials/spriting/


Why edit the less file? Isn't this order

1. Compile LESS/SASS

2. Sprite Generation

3. Minification

easier to do ?


When would you replace the background image positions? Wouldn't it be easier to do that in one place than many? You don't have the sprite positions until you generated the sprite.


The ideal sprite system is one that is automated.

I wonder if the growth of SPDY undermines the entire foundation of using CSS sprites?


I love spritifying and existing site and watching the load times drop in usage reports.

Here's a great idea that I would like to see implemented concerning css sprites and the rails asset pipeline:

In your .erb.css file you could include each background image individually, when you reference it in the css you would flag it as "spritable". Then when assets:precompile is ran some magic piece of code would build a single sprite image from all your background images and fill in the background-position. Automating the whole process.

Like most things I don't have the time/skill to do with, but nice idea nonetheless.


I use SpriteRight (Mac app) which even has some intelligence built-in (like how to align elements best), and exports CSS code as well. And it's dirt cheap. No reason to do it like it's 1999 when there's tools like that :)




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

Search: