- From: Charles Pritchard <chuck@jumis.com>
- Date: Fri, 17 Dec 2010 15:29:11 -0800
- To: Anthony Ricaud <anthony@ricaud.me>
- CC: Anne van Kesteren <annevk@opera.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>
On 12/17/2010 3:15 PM, Anne van Kesteren wrote: > On Fri, 17 Dec 2010 18:29:54 +0100, Tab Atkins Jr. > <jackalmage@gmail.com> wrote: >> Do you think the idea of an image fallback function is useful at all? > > I do not think it is useful, indeed. > > >> Or are you just objecting to the manner of indicating the image >> format? > > If we decide to go through with having some kind of fallback function, > yes. > > We do use image fallbacks, but we just go ahead and do it through onerror, and so forth. Mainly, we use it when a resource can't be found/connected to: but I'm sure we'll also be adding in logic for conditional support of the new WebP format. As most of us know, "guessing" on an image format based on the extension is not workable-- until/unless the extension has already been fetched, or peeked at via HEAD, for a mime content type. And as most of us know, image formats can typically be "guessed", by peeking at the first dozen bytes of the stream. Neither of those save the HTTP lookup, but I really don't see a way around that, short of explicitly defining the image format url(image.com; format=image/jpeg)
Received on Friday, 17 December 2010 23:29:07 UTC