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

> From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf
> Of Tab Atkins Jr.
> Sent: Tuesday, January 18, 2011 2:39 PM
> To: Tantek Çelik
> Cc: www-style list
> Subject: Re: [css3-images] image() function and file formats
> 
> On Tue, Jan 18, 2011 at 2:17 PM, Tantek Çelik <tantek@cs.stanford.edu>
> wrote:
> > On Tue, Jan 18, 2011 at 13:37, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
> >> 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.
> >
> > RIght. Here's the citation (W3C TAG issue) you're looking for:
> >
> > http://www.w3.org/2001/tag/group/track/issues/24

> 
> No, this functionality applies before HTTP's Content Type even comes into
> play, as it can prevent a download from occurring at all.
> There's no conflict there.
> 
> >> I don't have a strong opinion on the matter -
> >
> > then best to drop it.
> 
> Not necessarily.  *I* don't have a strong opinion, but that may just be
> because I'm insufficiently informed.  By requesting other people's
> opinions, I can determine if I should care or not.

You already asked the question and agreed to update the draft last month: http://lists.w3.org/Archives/Public/www-style/2010Dec/0421.html

So this feels a bit like a European referendum ('We shall keep asking until 
you say Yes') :)

> 
> 
> >> in theory, doesn't say anything about the file, but also that in
> >> practice most files have the correct extension for their type.
> >
> > worse than that, file extension based assumptions lead to security
> > problems (because the "can/should I handle this" code is almost always
> > different than the actual "handle/display/execute this" code - check
> > bug databases of (nearly?) any browser for this - "here go display
> > this .jpg file" - "oh look, it actually looks like a script I should
> > execute" oops).
> 
> That's not relevant in this context, as (1) this functionality
> *prevents* downloads, rather than triggering downloads that would
> otherwise not occur or changing the interpretation of a resource being
> downloaded, and (2) image() is essentially just a shortcut for putting the
> appropriate resource directly in the relevant property.
> "background: image(url(foo.jpg));" is identical in behavior to
> "background: url(foo.jpg);" - whatever browsers currently do when you
> serve a js file as ".jpg" for a background, they'll do here as well.
 
Precisely. Browsers don't use the .jpg extension to decide what to do with
the data returned by url(); you're now suggesting that part of the URL can 
be used to assume a Content-Type. Which interferes with scenarios that are 
possible, valid and supported on the web: I can switch the format of my web 
site's /logo.gif URL - e.g. replace the original GIF with an SVG version - 
without breaking the original URL and browsers will do the right thing provided 
I serve the resource with the proper Content-Type. 

I could also be using a server-based image generation service with a URL
that either does not accept file extensions or allows them anywhere in the 
path e.g. as on http://dummyimage.com/. Etc.

The URL and the underlying resource representation format are orthogonal and 
I don't get why it's good or useful to break that here. 

Also, see http://www.w3.org/TR/webarch/#uri-opacity.


I think it's fine to allow authors to explicitly tag images as being of a certain 
format so the browser can fall back, just as is done in CSS3 Fonts with the format 
hint. Explicitly being the key word. 

(And, by the way, if this should work for images, why should we keep the format hint 
and not use the font files extensions as well ?)

Received on Tuesday, 18 January 2011 23:29:43 UTC