Re: Image sprites use cases

On Thu, Aug 27, 2009 at 3:04 PM, Alex Kaminski<activewidgets@gmail.com> wrote:
> Hello,
>
> After reading recent discussions related to image sprites I would like
> to offer some typical usage cases, which, I am afraid, are not
> addressed by the current proposals. These usage cases are very common
> for the web components/web applications developers but probably
> different from what you will find on a 'normal' website.
>
> Let's look at the typical custom button or checkbox (see the composite
> image below) -
>
> http://www.activewidgets.com/runtime/2.5/styles/mono/checkbox.png
...[snip]...
> I should probably emphasize that this is kind of 'component developer'
> view, not the typical website designer view. Hope that it may help
> anyway.

Actually, this was really helpful.  It's a reminder of a different
use-case than what is currently being addressed through the sprite
proposals.

(I'll note quickly that my favorite, and I think generally the best
solution, is the one being created by the Media Fragments WG where
they're defining one form of hash on links to image files.  Using frex
"image.png#xywh=0,40,20,20" would select a 20x20 region, starting on
the left edge, 40px from the top.  My second favorite, Jorrit's
@sprite proposal, is not materially different in actual use.  In this
message I'll be pretending that the MFWG proposal is the one being
used.)

Your message points to a fundamental lack in CSS - the cascade only
operates on properties, not values.  In CSS we build around this by
breaking complex properties into subproperties that address a portion
of the original value at a time.  The current sprite practice benefits
from a lucky coincidence, that the pieces of its values are already
split apart into properties (namely background-image and
background-position).  That's why you can, frex, just add a single
rule swapping out the image and automagically get support for radio
buttons as well as checkboxes.  Splitting background-position apart
would make it slightly easier to do this, yes, but not significantly
so - you'd have 8 base rules rather than 13, and 9 for the radio+check
case rather than 14.  Once you've committed to providing 8 rules,
providing 5 more isn't that much of a burden.

Using the new sprite practice from the MFWG would be 12 rules for just
checkbox, and 24 when you add radio - one per type/state/interaction
combo.  This is more verbose, but it's necessary for a general
solution.  Current practice only allows sprites on backgrounds, and
only if you accept certain limitations (the width and/or height of the
box must be fixed and equal to the width/height of the sprite).  We'd
like to be able to use sprites *everywhere* there can be an image
(list-style-image, border-image, content, <img>?) and without those
restrictions.  It simply wouldn't make sense to spam a -position
subproperty onto all of these, let alone a pair of -position-x and
-position-y properties.  I hope you agree that
list-style-image-position-x is kinda ridiculous.  ^_^

So, unfortunately, we're kinda stuck.  We can't split out the
properties everywhere we want to use sprites.  We can't use the
cascade without splitting out those properties.  So we just plain
can't do what you're asking in a general solution.

However, there is hope.  Just keep doing what you're doing.  Use
background-image and background-position when you can accept the
limited use and restrictions.  It's easy, it's well-known, and it
won't ever stop working.  And then, when you want to use sprites
somewhere else, use the # to simple select a subregion of an image.
Slightly more verbose, but it works great.

So, in other words, I think we're fine.  ^_^

Received on Saturday, 29 August 2009 22:08:30 UTC