Re: background-position-x & y

On Tue, Jan 13, 2009 at 5:12 PM, Faruk Ateš <faruk@apple.com> wrote:
>
> On Jan 13, 2009, at 2:23 PM, fantasai wrote:
>>
>> Jethro Larson wrote:
>>>
>>> On Wed, Nov 12, 2008 at 7:39 AM, Aryeh Gregor <Simetrical@gmail.com
>>> <mailto: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 sprites are a hack, but using background-position for
>> them /is/ a hack. There isn't really an alternative yet, unfortunately.
>
>
> Background-position is by far the closest approximate to how sprites were
> implemented / utilized in other, prior areas however, so even though yes,
> it's a hack, it's only really half a hack due to the lack of alternative.
>
> To counter, though: I don't think there really ought to be an alternative
> for this. The implementation of any alternative would be almost exactly like
> using background-position and the value of adding a dedicated approach seems
> really small to me.

I disagree.  Right now, frex, you can't tile a sprite unless you've
set things up so that the piece you want touches the picture edges in
the direction of tiling.  That is, if you have a collection of 20x1px
images that will be horizontally tiled, and you want to forge these
into a sprite, you *must* stack them vertically in the sprite, and
they must all be 1px in width (or generally, the same width).

A proper sprite solution would allow you to actually cut a block out
of a larger picture, and then treat it as a separate picture in all
ways.  The background-position hacks are instead impose a small
'window' over a larger image, and it's the larger image that is
actually used when considering, frex, tiling.

Another issue is that you can't have an element be larger than the
sprite, again unless the piece you want touches the picture edges in
the direction of growth (otherwise the other sections of the image
show through).  This is in the *opposite* direction of tiling, so if
you want both (rather common in my experience as an author) you can't
use background-position *at all*.  (To be explicit, I use this
commonly with gradients - I'll tile a thin gradient image and attach
it one edge, setting the background color to be equal to the
gradient's "loose edge".  Frex, "background: white url(
gradient.php?shape=vertical&height=30&start=f00&end=fff ) left top
repeat-x".  It is impossible to use a sprite to accomplish this if I
want the block to be able to grow past 30px in height.)

A true sprite solution would be very similar to the current
background-position hack, but it wouldn't be identical, or even almost
identical.

~TJ

PS: Just because I can, an easy solution would be nothing more than a
"sprite( url, xstart, xlength, ystart, ylength)" value that could be
used anywhere the url() syntax is allowed to specify a picture.  This
simple solution isn't ideal in a few ways, but it would be *as usable*
as the current hack, and add the powers that I described above which
the hacks currently lack.  Implementation would be roughly similar to
Webkit's current handling of CSS gradients.

Received on Tuesday, 13 January 2009 23:39:15 UTC