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

Re: Image sprites use cases

From: Bert Bos <bert@w3.org>
Date: Thu, 3 Sep 2009 21:14:48 +0200
To: www-style@w3.org
Message-Id: <200909032114.48662.bert@w3.org>
On Monday 31 August 2009, Boris Zbarsky wrote:
> See 
> http://limi.net/articles/resource-packages for a very initial
> proposal draft; comments welcome.

Sort of a side-comment: one other piece of prior art is the DECLARE 
attribute of HTML, which allows you to list in the HEAD all the 
resources that might be useful to download right away.

It lists the resources directly, instead of indirectly, as in the Limi 
proposal, which means it increases the size of the document more and 
thus has a higher risk of slowing down instead of speeding up the 
download of the full compound document.

It exists since 1997, but my impression is that it isn't used. Maybe 
waiting for the BODY doesn't actually take that much longer?

I also wonder if downloading a zip is really more efficient than 
downloading the individual files (assuming HTTP and a browser that 
supports pipelining and transfer-coding; it's not the same for FTP and 
other protocols). The stream of bytes that comes down to the client is 
about the same length as the zip (because the compression is the same). 
It contains more HTTP header lines, but the zip contains a directory.

(On second thoughts, those header lines would somehow have to be added 
to the zip, too, because without them you don't know what the MIME type 
of each file is or how long you can cache it...)

And, if preloading indeed proves efficient, shouldn't it be defined in a 
way that applies to all kinds of compound documents, not just HTML?

  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos                               W3C/ERCIM
  bert@w3.org                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France
Received on Thursday, 3 September 2009 19:15:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:39 UTC