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

Re: Image sprites use cases

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 3 Sep 2009 14:34:25 -0500
Message-ID: <dd0fbad0909031234v1860b923re83f84322c75f0d8@mail.gmail.com>
To: Bert Bos <bert@w3.org>
Cc: www-style@w3.org
On Thu, Sep 3, 2009 at 2:14 PM, Bert Bos<bert@w3.org> wrote:
> 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?

Yeah, I think that's solving the wrong problem.  Or rather, just a
part of the problem.  Waiting for the <body> obviously doesn't take
long; the more important use of it is to prefetch things that aren't
used immediately, so you get a responsive UI later.  (Of course, I've
never seen it used either.  Ever.  Or even talked about.)  The main
use-case for sprites is collapsing many resources into one so that
they can be downloaded with a single connection.

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

I dunno what exactly the effects are of pipelining and
transfer-encoding, or how they compare to downloading a single
combined file, especially when the numbers of files grow large.

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

Sure, but those already exist.  This is just a particular way to do
the single-connection-preloading transparently in HTML.

~TJ
Received on Thursday, 3 September 2009 19:35:20 GMT

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