Re: Image sprites use cases

On Aug 30, 2009, at 6:07 PM, "Tab Atkins Jr." <jackalmage@gmail.com>  
wrote:

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

Kind of. It use the image fragment notation that you mentioned  
earlier, but when the hash part is used by itself, it assumes  
something similar to a BASE url value, which would be implied by the  
url() without the hash (since the form of 'url(#hashvalue)' is not too  
useful by itself for specifying images otherwise). So not that weird  
given the existance of the BASE tag in HTML. But new for CSS.

> 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 so much. If I specify 'url(image.png), there is an 'invisible'  
value that tells you the path to that file (it resolves to the path to  
the CSS file being prepended to this file name). What I am suggesting  
is that when a path and/or filename is provided already, that it be  
used to resolve any naked hash value, in a similar manner.

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

I was thinking of that as a feature, not a problem, but maybe not.

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

It would allow you to generalize the meaning of the hash part of the  
document fragments idea you brought up, to apply it to other images  
interchangeably. It takes that same idea and makes it mire flexible.

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

I don't know about that. I've created button-styled links by hand,  
with hover states, dimmed states, small versions, etc. That were all  
in a style to match the site style. I did that all by hand.

Received on Monday, 31 August 2009 02:42:00 UTC