Re: background-position-x & y

On Wed, Nov 12, 2008 at 7:39 AM, Aryeh Gregor <Simetrical@gmail.com> wrote:
> Sprites are a terrible hack.  CSS shouldn't make any attempt to
> support them.  CSS sprites should be obviated, for preference, by
> browsers loading all images simultaneously, negating the performance
> advantage of sprites.  (Possibly only if the server requests this
> somehow, if causing server load is an issue.)  There is no possible
> justification for trying to support an interface where authors are
> supposed to manually concatenate images and manually specify offsets
> in CSS rather than treating the images as the logically separate units
> they actually are.  CSS sprites might be useful now, but that's a bad
> situation, not one that anyone should be trying to perpetuate.

Sprites are not a hack, they are an optimization that will always improve
download size, and almost always improve performance. That is why sprites
were used on games of the past and that's why they're used now (e.g. texture
mapping). Three 10px X 10px images will almost always be larger than one
30px X 10px image add to that the cost of separate http requests, and system
memory, and there's a big difference.

I don't think there's a particular cost to using sprites other than keeping
track of the positioning and only benefit. I'm not talking about taking all
the images in an image gallery and concatenating them, but skinning can be
better managed via sprites than any alternative.

No one likes their images folder to look like this:
  box_bl.gif
  box_t.gif
  box_tr.gif
  box_l.gif
  box_r.gif
  box_bl.gif
  box_b.gif
  box_br.gif

Just so they can get a custom border box. That's part of the desirability of
the [border-image](
http://www.w3.org/TR/2002/WD-css3-border-20021107/#the-border-image)
property, that we can use a simple single image and render a full box with
minimal css. I can't believe you would stand against this highly useful
technique, when we should be making it easier via a syntax for slicing.