Re: Image sprites use cases

Patrick Garies wrote:
> On 8/31/2009 7:15 AM, Boris Zbarsky wrote:
>> 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 agree. The MIME type is obviously incorrect for ZIP archive.

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

I agree that "already supported by browsers" does not count that much
because although some browsers have native ZIP archive support (through
jar: URL scheme) they still would not support the resource-package
specification without changes.

Major issues with ZIP (listed in the article as well):
 * no way to specify content-type (incl. charset)
 * no resource specific expiry time

The article also mentions that ZIP archives have the index at the end of
the file which I believe is correct. If you cannot access the end of the
file, you cannot extract any given file inside it. As a result, no
incremental downloads from inside the resource package.

The proposal still has really nice idea behind it and I'd suggest doing
it - just replace the ZIP packaging with compressed TAR archive. GZIP
compression would result in high performance decompression, BZIP2
compression would result in smaller packages. Both formats would allow
incremental downloads. I'm not sure if TAR format allows including MIME
type or expiry time per file - if not, then use some other format instead.

-- 
Mikko