Re: [Uri-review] Proposal for a 'fallback' URI scheme

[Giuseppe Bilotta <giuseppe.bilotta at gmail.com>]

On Sun, Aug 16, 2009 at 11:57 PM, Toby A Inkster<mail at tobyinkster.co.uk> wrote:
>> Using nested objects to provide fallback for other tags (img, video,
>> audio, whatever might come up next) looks to me like a horrible hack.
>
> Using nested OBJECT elements to provide fallbacks is not a "hack" - it's how
> that element was designed to be used. Take a look at this example from the
> HTML 4.01 recommendation:
>
> http://www.w3.org/TR/html401/struct/objects.html#h-13.3.1
>
> | <P>                 <!-- First, try the Python applet -->
> | <OBJECT title="The Earth as seen from space"
> |         classid="http://www.observer.mars/TheEarth.py";>
> |                     <!-- Else, try the MPEG video -->
> |   <OBJECT data="TheEarth.mpeg" type="application/mpeg">
> |                     <!-- Else, try the GIF image -->
> |     <OBJECT data="TheEarth.gif" type="image/gif">
> |                     <!-- Else render the text -->
> |      The <STRONG>Earth</STRONG> as seen from space.
> |     </OBJECT>
> |   </OBJECT>
> | </OBJECT>
>
> Given that the preferred content is an applet, the first fallback is a
> video, the second fallback is an image and the last fallback is some HTML
> text, I don't see how a fallback URI scheme could even cope with this use
> case. e.g.
>
>        <img src="fallback:TheEarth.py|TheEarth.mpeg|TheEarth.gif"
>             alt="The Earth as seen from space." />
>
> seems inappropriate given that only one of the three files, the GIF, is an
> image.

I would say that trying to fit a python applet, an MPEG movie and a
GIF into an img tag would be an abuse of the img tag. _This_ is one
case where nested objects make sense. I didn't say that using nested
object in HTML was a hack, I said that using them to provide fallback
for a given other tag was a hack.

>> Not only It's painfully verbose to write, needing all attributes to be
>> specified for nested objects, but it also breaks DOM and complicates
>> manipulation via JavaScript and whatnot.
>>>
>
> The syntax isn't fantastic - a lot of HTML syntax comes from historical
> compromises. The <audio> and <video> elements in HTML5 have slightly more
> elegant mechanisms for fallback content. e.g.
>
>        <audio src="sound.mp4">
>                <source src="sound.ogg" type="audio/ogg;codecs=vorbis">
>                <source src="sound.mp3" type="audio/mp3">
>                <p>Download <a href="sound.mp4">my sound</a>.</p>
>        </audio>

Ah, interesting, I must have missed this the last time I looked over
the HTML5 draft. I wonder if the img tag could be extended this way
too ...

[snipping various very interesting insights on content negotiation]

> When Firefox downloads an image as the result of finding an
> <img> element, then it sends a different image-specific set of types. (For
> the HTML5 <video> and <audio> elements, it sends a less good one - this is
> an open bug, #489071 on Bugzilla.)

It _did_ sound strange to me that the Accept line would be so useless ...

>> Konqueror: "text/html, image/jpeg;q=0.9, image/png;q=0.9,
>> text/*;q=0.9, image/*;q=0.9, */*;q=0.8"
>
>> Konqueror's is slightly less useless (and it's missing some important
>> formats such as SVG and MNG)
>
> SVG's media type is image/svg+xml which matches the image/* wildcard. MNG
> doesn't have a registered media type, but image/x-mng and video/x-mng are
> often used; both of these are matched by Konqueror's wildcards.

The problem with those wildcards is that they are too broad, and since
they give the same quality to all formats, it's really non-distinctive
of the actually supported formats.

> Content negotiation uses less bandwidth than fallbacks would. Given:
>
>        fallback:|somefile.svg|somefile.mng|somefile.png
>
> a browser which didn't support SVG or MNG files would need to download all
> three files to find the one it was capable of displaying. With content
> negotiation it would request a file called "somefile" with an Accept header
> including image/png but not image/svg+xml or image/x-mng, thus it would be
> delivered a PNG file, and not waste bandwidth trying to receive the other
> two files.

That was actually the reason for question 2. in my proposal, aiming at
something like

fallback:|image/svg+xml;somfile.svg|image/x-mng;somefile.mng|image/png;somefile.png

but then the syntax would start to get complicated).

> Lastly: if browser vendors haven't gotten content negotiation right in the
> ten years since the HTTP 1.1 RFC, why would the fallback scheme be any
> different?

That's (sadly) a good point.

-- 
Giuseppe "Oblomov" Bilotta