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.


>> 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.


>> I'm interested in implementor opinions here.  Is this type of sniffing
>> okay?
>
> In a spec, especially for new functionality, no.
>
> If you choose to implement it for some sort of legacy/compat support,
> be prepared to deal with all the bugs and security risks you'll
> encounter as a result. Your (implementer) risk decision to make.
>
> Better reason:
>
> Make it consistent with previous similar multiple image URLs with
> fallbacks properties. e.g. 'cursor'.
>
> http://dev.w3.org/csswg/css3-ui/#cursor

Sounds good.

~TJ

Received on Tuesday, 18 January 2011 22:40:26 UTC