Re: Image sprites use cases

On Sun, Aug 30, 2009 at 6:54 PM, Brad Kemper<brad.kemper@gmail.com> wrote:
>
> On Aug 30, 2009, at 2:10 PM, Alex Kaminski wrote:
>
>> Now using your syntax we would need 192 rules like these -
>>
>> .xp .checkbox.true.normal .small {background-image:
>> url(xp/checkbox/small.png#0,0,10,10)}
>> .xp .checkbox.false.normal .small {background-image:
>> url(xp/checkbox/small.png#25,0,10,10)}
>
> No, I think you misunderstood. I am saying that the file part only be
> specified once, and that the hash part changes which portion of the image is
> shown. Just as an HTML file is loaded once, and a hash Anchor (<A> tag) does
> not reload the file but just scrolls to a different portion.
>
> So the above would be written this way:
>
> .xp .checkbox.normal.small { background-image:
> url(xp/checkbox/small.png#xywh=0,0,10,10); }
> .true{ background-image: url(#xywh=25,0,10,10); }
>
> That is, the hash part (#xywh=25,0,10,10) only changes the area within the
> image, it does not change which file is loaded from the server.

So it relies on grabbing the value from the cascade and modifying it?
Interesting.  I probably wouldn't reuse url() for this - I'd make up
something new like hash() that explicitly had this behavior.

This is sort of weird, though - it essentially uses the cascade on
values, which as I mentioned above isn't done at all currently.  You
would first cascade a normal image as the value of background-image,
and in addition cascade a hash value as a *second, independent* value
for background-image, which gets combined into it at used-value time.
This produces something entirely new and different that has never
before existed in CSS.  It's like defining a special invisible
property for everything that accepts urls.

Not saying this is necessarily bad, mind you.  Just... weird.  I
wouldn't have any idea how easy/difficult this would be to implement.
Unless there's a good reason you'd need this outside of images,
though, it would probably be better to make this a *real* property in
all the appropriate places, like Alex's suggestion of a set of
"-region" properties.

Note, though, that doing so *still* isn't backwards-compatible.  A
legacy browser would see the normal url(), ignore the
background-image-region property.

All in all, I'm not sure that CSS is the right place to handle this.
The only benefit you're looking for that we can't easily squeeze out
is brevity, but that's really not that important here.  These rules
have a *very* regular structure that can be churned out by a nested
loop with any competent language.  Considering the originator of the
use-case (widget libraries), it's not an unreasonable assumption that
they'll be able to do this.  It's *not* a situation that a normal
author hand-crafting rules, or even a normal author using a CMS, will
encounter.  The cost of those 192 rules (or more, depending)
on-the-wire isn't much, a few kb uncompressed (and the regular
structure will aid in compression).  Since any decent solution,
especially a backwards-compatible one, would require relatively
substantial changes, and possibly even changes in the processing model
of CSS, I'm fine with just recommending that you generate that section
programmatically.

(And I swear, Boris, I was going to suggest this before your message.
I just interrupted myself halfway through composing to go mow the lawn
- I would have beat you had I written this straight through.  ^_^)

~TJ

Received on Monday, 31 August 2009 01:08:22 UTC