Re: Image sprites use cases

Hallo,
> On Tue, Sep 1, 2009 at 10:49 AM, Pascal Germroth<pascal@germroth.name> wrote:
>> - - real attachments to websites, like emails. For example, the home page
>> could attach the stylesheets and images, which speeds up loading even
>> more since in one request you get everything without having to parse the
>> page first. Other pages would refer to the files as usual, the browser
>> would use the cached versions, or if you didn't visit the home page
>> first, load them as needed. (Of couse, people would soon start attaching
>> everything to every page...)
> 
> That's a showstopper.  We *cannot* rely on people visiting the
> homepage first; search engines direct you straight to the page you
> want which can be deeply internal.  I want *all* pages to benefit from
> this, so I'd have to 'attach' the files to *every* page, which defeats
> a lot of the purpose.  Making them still be a separate resource lets
> the browser decide that it's already cached the thing and ignore it on
> subsequent page loads.

Well, one could do both: attach resources directly, have a single
multipart file with every resource linked to (instead of the ZIP file)
and, for backwards-compatibility, seperate files.

On tool support: It should be relatively easy to write an apache httpd
extension which will create ZIP-files or multipart MIME files on the fly
(cached, of course) off a folder (tree) or the manifest. This would be
the easiest way for authors, since they would not have to manage the ZIP
file and the "normal" tree of files.

The other advantage of multipart MIME would of course be, that it
already includes the manifest, with free headers on parts etc.
The XML manifest on the other hand could be a way for a new Semantic
Web-ish type of header, with namespaces, RDF,...

Received on Tuesday, 1 September 2009 23:30:11 UTC