Re: Image sprites use cases

On 8/31/2009 7:15 AM, Boris Zbarsky wrote:
> Patrick Garies wrote:
>> Yeah, it would be nice to have a compression package that carries a
>> batch of images and allows you to address them individually in a form
>> like "images.zip#image1.png"; that way, you get another layer of
>> compression, one request, and you don't have to calculate or specify
>> region information.
>
> Actually, the proposal would be a package with a manifest, then you
> address the images normally and they get loaded from the package in
> browsers that support it (and one by one from the web server in ones
> that don't). That way it's even backwards compatible and can be rolled
> out as soon as desired. See http://limi.net/articles/resource-packages
> for a very initial proposal draft; comments welcome.

I think that that proposal would indeed be better since it doesn't 
require a different addressing method and falls back well.

However:

* I'm a bit curious why it lists the MIME type as application/x-gzip; 
apparently, that's the MIME type for GZIP with a file extension of *.gz 
whereas the MIME type for ZIP is application/zip or multipart/mixed 
(although I don't know how up-to-date those ZIP types are since the IANA 
and IETF sources are from '93 and '96, respectively). Even if browsers 
don't support those types yet (which is the case if I'm reading the 
draft spec correctly), presumably support for that could be added though.

* I'm also curious if a format like *.7z would also work since it 
compresses way better than ZIP does. Unfortunately, I don't know if you 
can read and extract individual files from that format.

* I'm not sure how "already supported by browsers" is a "very desirable 
trait". Can browsers actually open ZIP files or are these just passed to 
another application? Even if so, how does that make it better than any 
other format aside from decreasing implementation effort (or is this the 
key trait)? Since the technique is completely transparent to other 
browsers, "already supported" doesn't serve any backward-compatibility 
purposes.

* Does "so you can put CSS and Javascript first in the file, and they 
will unpacked and made available first" mean that these files need to 
come first alphabetically via file names? Or is there a way to manually 
specify order?

* Of course, there's also the million dollar question: What is the 
likelihood that a browser vendor would implement such a thing?

Received on Tuesday, 1 September 2009 04:41:02 UTC