Re: Image sprites use cases

Brad Kemper wrote:
> It's still vague to me too. Just an idea that I thought might have merit.

I thought about this some more, and there is in fact a problem here if 
you want to use the url() syntax: the base URI can't exactly depend on 
the URI being resolved.  So the base URI for url(#foo) and url(bar#foo) 
needs to be the same

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

Error handling happens by parsing declarations, rules, etc at parse 
time.  That's a one-time-per-page operation, usually.

What you're suggesting is adding time and complexity to specified style 
computation.  That's a thousands-to-millions-of-times-per-page operation.

You're also suggesting

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

Did you miss the "sort the rules by decreasing specificity" part?

In any case, I've been thinking about this some more and it's not clear 
to me why we're bending over backwards to address this use case at all. 
  If the only thing we're trying to address here is people using sprites 
because they want to coalesce loads, then a solution more along the 
lines of http://limi.net/articles/resource-packages seems like a better 
approach to me than the current spriting hack.  The latter has serious 
costs in terms of correctness (weird edge behavior) and memory usage 
(sprited images commonly take 2-10x more memory than the unsprited 
versions; in practice that's tens to hundreds of megabytes of wasted 
memory).

I understand that people use spriting now for lack of anything better, 
but if we're going to be adding features and complexity to web browsers, 
we should think hard about what the goal is.  Is it to make spriting 
more effective and easier, or to solve the problem of multiple HTTP 
requests in a more effective and simpler way?

-Boris

Received on Monday, 31 August 2009 12:14:08 UTC