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

Re: Image sprites use cases

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 3 Sep 2009 09:27:10 -0500
Message-ID: <dd0fbad0909030727i70b901f3x89b49adb623030d1@mail.gmail.com>
To: Aryeh Gregor <Simetrical+w3c@gmail.com>
Cc: Alex Kaminski <activewidgets@gmail.com>, Boris Zbarsky <bzbarsky@mit.edu>, www-style@w3.org
On Thu, Sep 3, 2009 at 8:50 AM, Aryeh Gregor<Simetrical+w3c@gmail.com> wrote:
> On Thu, Sep 3, 2009 at 7:10 AM, Alex Kaminski<activewidgets@gmail.com> wrote:
>> The package proposal is excellent and it covers very well the basic
>> usage of image sprites (to reduce the number of http requests).
>> However it still does not provide much help to the developers of web
>> applications and component libraries who also need an efficient method
>> to address many (possibly hundreds) of image fragments. Would it be
>> right thing then to target the new CSS sprites technique to this
>> advanced use case (UI components), possibly using something like
>> image-region property, assuming that the basic sprites case is covered
>> by the new packaging proposal?
> The problems with image sprites (high memory footprint, hard to author
> and maintain) would remain significant here.  It seems like your use
> case could be solved if CSS provided a way to algorithmically
> construct URLs for background images, or something of that sort.  I
> don't know what a good proposal of that kind would look like, though.
> Superficially, it seems kind of scary.  Why can't you just use a few
> hundred CSS rules?

He previously mentioned size, which is relevant here.  Given 200
selector blocks, at a conservative estimate of 50 characters each, and
you're staring down the long end of a 10k file just for the *basic*
widgeting CSS.

Of course, this stuff has such regular structure that it compresses
down wonderfully.  I just ran a basic test which I thought would be
fairly representative, generating 275 rules (11 base images * 5 states
* 5 orthogonal states).  The base file was 26k, but after the
automatic gzipping from my webserver it's only 1.6k, a compression
efficiency of over 93%.  That's pretty crazy good.

So, while the 'sticker shock' of the file is pretty high, the impact
in practice is low.

Received on Thursday, 3 September 2009 14:28:16 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:13:39 UTC