W3C home > Mailing lists > Public > www-style@w3.org > December 2010

Re: Feedback on Image modules

From: Karl Dubost <karld@opera.com>
Date: Sun, 12 Dec 2010 11:14:46 -0500
Message-Id: <219A8D7C-4FF1-4986-8525-DDB800FCF287@opera.com>
Cc: www-style@w3.org
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Copying the spec content to have the context of the discusssion.

    If the URL for the image ends in a file
    extension (a period followed by letters) of four
    ascii letters ([a-zA-Z]) or less, then the UA
    may skip trying to load images whose file
    extension matches an image format it knows it
    does not support.
    – http://dev.w3.org/csswg/css3-images/#image-notation

This is the normative statement with a MAY if I understand. Just to clarify the statement, what does it mean 

    "trying to load images"

Either it loads it because there is a matching extension or it doesn't, but "trying to load" is not testable.


    For example, a UA that knows
    it supports JPEG and GIF, but expects to
    encounter many PNG and SVG images may choose to
    skip over images with filenames ending in ‘.png’
    or ‘.svg’ without loading them to check their
    MIME type. However it must not skip over images
    with filenames ending in extensions it doesn't
    recognize.
    – http://dev.w3.org/csswg/css3-images/#image-notation

Is "MUST" here a requirement or part of the example?

>> Plus, it ties the URL to the file format which is not a good idea.
> Theoretically, sure, but in practice the file extension is a very
> strong indicator.

There are two sides about this.

* Wether the extension is a strong indicator and we rely on it for downloading/parsing it. Then the next question becomes what is happening when the extension was wrong? Opera's MAMA data doesn't help here because Brian Wilson did exactly that.

    MAMA defaulted to using an image's file
    extension to judge the format type. If MAMA
    could declare an image format from just this
    data alone, it did not try to dig any deeper
    than that. If it could not determine the
    format from the file extension, MAMA would
    then download the HTTP HEAD of the
    referenced image and proceed to examine the
    image's MIME type to detect the format. This
    policy was a useful shortcut that really
    helped with the analysis script's overall
    performance.
    – http://dev.opera.com/articles/view/mama-images-elements-and-formats/

Except that this policy gives wrong results for data (unfortunately). The extension either doesn't exist, or a GIF is served as PNG, etc.

* Second, what is happenning for all people serving their images without extension but with the right mime-type, be it from script or from static images? What would be the processing policy?


Let's say a User-Agent with Accept: image/gif, image/png  (*no support for SVG*). The CSS at the domain http://example.org/ contains this rule:

    background-image: image(wavy, wavy.php, wavy.svg, wavy.gif);

1. http://example.org/wavy 
   Content-Type: image/png
2. http://example.org/wavy.php
   Content-Type: image/gif 
   (because it is the first in the list of user agent 
   Accept header, the script generates the image 
   dynamically depending on the user agent preferences.)
3. http://example.org/wavy.svg
   Content-Type: image/svg+xml
4. http://example.org/wavy.gif
   Content-Type: image/png
   (a program converted some gif images into png and 
   added the extension but the file is served without 
   extensions as the first one.)

What is happening?


[1]: http://dev.opera.com/articles/view/mama-images-elements-and-formats/

-- 
Karl Dubost - http://dev.opera.com/
Developer Relations & Tools, Opera Software
Received on Sunday, 12 December 2010 16:15:23 GMT

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