- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 18 Jan 2011 13:37:23 -0800
- To: www-style list <www-style@w3.org>
The CSS3 Images spec <http://dev.w3.org/csswg/css3-images/#image-notation> defines the image() function, which allows authors to specify multiple images, representing the first one that doesn't give an error (that is, if the first one 404s or similar, the browser will instead fetch the second one in the list, etc.). Right now, the image() function has a form of light type-sniffing via the file extension, such that if the UA sees an image with an extension corresponding to a type of image the UA *knows* it doesn't support, it can skip trying to load the image altogether and just jump to the next image in the list. People have expressed concern that sniffing the image format via the file extension is unreliable and not a good practice. I don't have a strong opinion on the matter - I know that the file extension, in theory, doesn't say anything about the file, but also that in practice most files have the correct extension for their type. As well, this is a very conservative effect - the only way it could cause a problem is if the author was (1) intentionally using image(), (2) specifying the wrong extension on their images, and (3) this wrong extension happened to correspond to an image type the UA knows it doesn't support. It can be easily fixed by just using the correct extension, or if one must mislabel their images, by using a more ambiguous extension, like ".php", which the UA doesn't know it doesn't support. I'm interested in implementor opinions here. Is this type of sniffing okay? If not, I don't think that the functionality it offers (allowing UAs to skip some resources) is useful enough to complicate up the syntax further a la @font-face, so I'll just drop the relevant text. ~TJ
Received on Tuesday, 18 January 2011 21:38:20 UTC