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

Re: Image sprites use cases

From: Alex Kaminski <activewidgets@gmail.com>
Date: Mon, 31 Aug 2009 13:28:30 +0200
Message-ID: <6328fb9a0908310428n2eac7805we2283a5cc2c6fad6@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: Brad Kemper <brad.kemper@gmail.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, www-style@w3.org
On Mon, Aug 31, 2009 at 2:49 AM, Boris Zbarsky<bzbarsky@mit.edu> wrote:
> Alex Kaminski wrote:
>> No, my concern is about how many rules you need to write,
>> not about the length of a single rule.
> Sounds like the packaging solution wouldn't help you either, then... that
> assumes you've got a bunch of separate images (of which you have somewhere
> around 200, sounds like) that you'd like to grab as a single download.  In
> your case it sounds like you'd like to not have 200 separate url()s listed.
> That said, why not?  This seems like a good job for a preprocessing
> solution, honestly...
> -Boris

We store artwork in a vector format and produce all images programmatically
with the build script (GIFs for ie6 and PNG for others) and we can easily
generate urls too (though growing stylesheet size 10 times is not nice -
current library users are very sensitive to css and js file sizes).

The real problem starts when the library user wants to customize our controls.
Currently we can say: copy our image, modify it and just add a single url
of the new image to your stylesheet. All internal sprite magic would still
work without the end user being aware of the details (as long as he does not
change the image sizes, but that is easy to explain and most users
just want to change colors).

Now, instead of adding a singe url - the library user would have to add urls
of each fragment (for example, the button has 9 parts * 5 states = 45 urls).
Does not look elegant. And we would have to explain all internal details
how this works - not an easy job.

Alex Kaminski
Received on Monday, 31 August 2009 11:29:11 UTC

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