- From: Sylvain Galineau <sylvaing@microsoft.com>
- Date: Wed, 22 Dec 2010 23:44:38 +0000
- To: Brad Kemper <brad.kemper@gmail.com>, Charles Pritchard <chuck@jumis.com>
- CC: Anthony Ricaud <anthony@ricaud.me>, Anne van Kesteren <annevk@opera.com>, Tab Atkins Jr. <jackalmage@gmail.com>, www-style list <www-style@w3.org>
> From: www-style-request@w3.org [mailto:www-style-request@w3.org] On > Behalf Of Brad Kemper > Sent: Friday, December 17, 2010 5:00 PM > To: Charles Pritchard > Cc: Anthony Ricaud; Anne van Kesteren; Tab Atkins Jr.; www-style list > Subject: Re: Feedback on Image modules > > On Dec 17, 2010, at 3:29 PM, Charles Pritchard <chuck@jumis.com> wrote: > > > 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. > > Is isn't good for selecting formats you do support, but isn't it still > helpful for eliminating those you don't support? For instance, you > could peek further for '.php', but not bother to do so for '.psd' if > you know you won't support Photoshop files. Then let the author give explicit unambiguous format hints, as done in CSS3 Fonts. I agree that depending on file extensions is a bad idea; at a minimum, doing so without defining all those file extensions and what formats they map to makes it harder to create solid testcases.
Received on Wednesday, 22 December 2010 23:45:14 UTC