W3C home > Mailing lists > Public > www-style@w3.org > January 2011

[css3-images] image() function and file formats

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 18 Jan 2011 13:37:23 -0800
Message-ID: <AANLkTimSS+itCTn8iYX=t2ivGsOMSB3ij=vwrWd0W_X9@mail.gmail.com>
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 GMT

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