Re: Image sprites use cases

On Mon, Aug 31, 2009 at 6:28 AM, Alex Kaminski<activewidgets@gmail.com> wrote:
> 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).

Then just keep using the background-position hack.  You're dealing
with fixed-width elements, which are perfectly suited for that
technique.  *background-position will never stop working.*  The
various spriting/packaging/etc proposals are meant to address the more
general uses that can't conform to the limitations imposed by the
background-position hack.

> 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.

So, yeah, see above; the user will still be able to add a single image
if you just keep doing what you're doing.  If it's sufficient now, it
will be sufficient later, even if we never come up with a *better*
solution.

(And the button case will be *way* easier once we get border-image
support, btw.  You'll use 1 image instead of 9, and won't need all the
junk elements you're currently using for the sole purpose of carrying
an image.)

~TJ

Received on Monday, 31 August 2009 13:25:09 UTC