03-30-2008, 07:34 AM
|
|
|
Registered User
Join Date: Feb 2008
Posts: 31
|
Quote:
Originally Posted by testpie
Firstly, I wouldn't advocate that approach because of the problem of interoperability between different browsers of displaying elements in a relative way - from previous experience, having to work around IE's stupid box model was hellish enough, so why would I want to, as a designer, introduce more pain for myself?
As well as that, surely this concatenated image is simply going to be the size of all the sprites added together - but what if everyone only wants to use one sprite at, say, 130 bytes per sprite? For instance, your site has a total of 100 x 130 byte sprites for the user to choose from, making this concatenated image around 13 KB. Now, say 100 people load a thread page with 5 posts in, with each post having just 1 sprite - so each pageload, in sprite terms, causes 5 x 13 bytes = 65 bytes per user of bandwidth, which with 100 people's pageloads, causes around 6.34 KB of sprite bandwidth in total - verses one pageload from one user with the concatenated sprite causing over double that amount of 13 KB; 100 users pageloads with the concatenated sprite image would cause bandwidth to rocket to 100 x 13 = 1.26 MB.
As the above was just a small example, I'm sure it's easy enough to see how this idea scales poorly when more than 100 pageloads are concerned. Not to mention, of course, you said that most browsers don't cache properly; so why would they magically not cache the 130 byte sprite, but suddenly decide to cache the 13 KB concatenated sprite? They wouldn't - so each consequent pageload by the same user would require yet another request for a 13 KB image, which is going to be slower than a few requests for a 130 byte image.
And now to wait to be proven wrong - as always in life.
|
This is pure plain CSS, nothing special. It has been possible in all browsers since the existence of CSS.
display:inline;width:100px;height:100px;background :...
That's it.
|
|
|