Re: Image sprites use cases

On Aug 30, 2009, at 8:02 PM, Boris Zbarsky <bzbarsky@MIT.EDU> wrote:

> Brad Kemper wrote:
>> 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.
>
> I'm not sure what you mean by "already".  In Gecko, for example,  
> matching rules are effectively sorted by descending specificity,  
> then for any particular property you walk along the list until you  
> come to a rule that specifies that property.  Once you find one, you  
> stop.  You don't look at the rest of the rules in the list.
>
> Your proposal would require walking more of the list in various  
> situations, no?  It's not clear to me how much more given the  
> vagueness of the proposal so far...

It's still vague to me too. Just an idea that I thought might have  
merit.

> Worst-case, it would require walking the whole list in cases where  
> right now you can stop as soon as you get to the first specified  
> value.

I thought it would be not much worse that error handling. Thus, if 'url 
(#myhash)' is encountered today, it is ignored, and either a previous  
or future url() value (or none) is used. My change would store it  
instead, to combine with that previous or future url(), or to put it  
into a sort of pseudo-property.

> In practice, the "stop
> as soon as you find a value" optimization is pretty important, from  
> what I've seen.

I don't really understand that. Additional rules can override previous  
ones. And previous rules can have more specificity. So there is no  
stopping to ignore other values. Of course you know that, so I must  
not understand what you mean.

Anyway, maybe it's not practical. I can imagine using it pretty  
easily, but I'm not married to the idea.

Received on Monday, 31 August 2009 04:24:35 UTC