W3C home > Mailing lists > Public > www-style@w3.org > September 2009

Re: Image sprites use cases

From: Alex Kaminski <activewidgets@gmail.com>
Date: Thu, 3 Sep 2009 18:11:01 +0200
Message-ID: <6328fb9a0909030911h42fad070pbc4e1c4938db0258@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: www-style@w3.org
On Thu, Sep 3, 2009 at 4:23 PM, Boris Zbarsky<bzbarsky@mit.edu> wrote:
> Alex Kaminski wrote:
>> Is it really so? I can imagine that using background-position for sprites
>> does indeed have memory impact, but if the spite is specified with
>> image-region then I guess the browser can easily optimize memory usage.
> The whole point of using sprites is that the single image is decoded all at
> once, no?  That's sort of how image formats work; they tend to not be
> amenable to only decoding part of an image.

So what? Can't you just discard the composite image and release memory
after extracting the sprite region? And how this is different from keeping the
set of separate images in a .zip package?

> Sprite techniques make the total size of the image much bigger than the sum
> of the sizes of the sprite images.  See
> http://blog.vlad1.com/2009/06/22/to-sprite-or-not-to-sprite/ for some
> discussion.

This example refers to the _current_ sprite technique (using background-position
hack) and specifically its limitation that it does not allow using
and background-size for the sprite fragments. Because of this
limitation authors make
the images very wide or very tall to compensate for the absence of
At this is exactly what causes excessive memory usage.

I don't see any reasons why the sprite technique based on 'image-region' should
have the same problems. If we could use background-repeat and background-size
for the sprite images, then authors will start making sprite fragments
1px wide/tall
and repeat them, and thus memory usage and composite image sizes will be
much lower.

>> Yes, we can. But for the person who is trying to customize/modify the
>> components it is not very convenient and much harder to explain.
> Is the solution more complexity in CSS or better authoring tools for working
> with your components?

Well, that is not about _our_ components. I was using our components just as
an extreme example. Sorry if I sounded like I am pushing something for our
own benefit. Please excuse my English :-)

I believe that this is a very common problem that all web application
developers are struggling with, regardless if they are using third-party
components or their own. Whether it is important enough to warrant
additional complexity in CSS - I think so, but at the end this is your call.

Alex Kaminski
Received on Thursday, 3 September 2009 16:11:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:39 UTC