W3C home > Mailing lists > Public > www-style@w3.org > September 2009

Re: Image sprites use cases

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Tue, 01 Sep 2009 08:42:47 -0400
Message-ID: <4A9D16C7.3060400@mit.edu>
To: Mikko Rantalainen <mikko.rantalainen@peda.net>
CC: www-style@w3.org
Mikko Rantalainen wrote:
> 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.

Yes, indeed.

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

Right.  On the other hand, I believe every off-the-shelf archiving 
format other than multipart MIME types has the former problem, and every 
single one has the latter problem, right?

For the image use case, I should note, the type thing is a non-issue: 
browsers don't use any part of the Content-Type header for images (MIME 
type is sniffed, and charset is not relevant).  For CSS and script it's 
a problem, as the proposal notes; it's not clear whether it's enough of 
one to matter.  In practice, authors almost never set the charset on 
such resources anyway, especially in the case of scripts.  For CSS 
there's @charset.  For all cases, there is the possibility of a bit of 
additional complexity in the form of a manifest file with metainformation...

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

I believe the index is at the end of the file but the file separators 
are well defined.  So you can extract all the files one by one as the 
zip streams in; you just don't know what they're called.

This is in fact a problem; that's why the idea of a manifest file was 
floated.  Of course if there's a better compression format more amenable 
to use here, that would be nice too.  I'm not sure there's an obvious 
candidate.

> 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

It doesn't.

> - if not, then use some other format instead.

Which one?

Note that support for creating compressed tar archives on Windows is not 
so great last I checked.  I think they can be opened without too much 
trouble, but creation is a different kettle of fish...  Or have things 
changed recently on this front?

-Boris
Received on Tuesday, 1 September 2009 12:43:34 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:20 GMT