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

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

On Sun, Aug 16, 2009 at 4:04 PM, Toby A Inkster<mail at tobyinkster.co.uk> wrote:
> On 15 Aug 2009, at 20:21, Giuseppe Bilotta wrote:
>
>> fallback:|somefile.svg|somefile.mng|somefile.png
>>
>> A supporting agent would then load the SVG file, or fall back to MNG
>> if SVG is not supported, and finally to PNG if neither of the previous
>> is supported.
>
> This seems fairly unnecessary to me.
>
> Firstly, (X)HTML already provides fallbacks for the OBJECT element. The
> fallbacks in your example could be written as:
>
>        <object data="somefile.svg">
>          <object data="somefile.mng">
>            <img src="somefile.png" alt="some sensible text" />
>          </object>
>        </object>

Using nested objects to provide fallback for other tags (img, video,
audio, whatever might come up next) looks to me like a horrible 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.

> Secondly, HTTP connection negotiation already allows browsers to tell
> servers a specific list of content types they accept, and servers to deliver
> a file based on that information.

I would really like to know if this has ever really been used
successfully. I gave a look to the Accept: headers sent by the three
browsers on my machine, and they are as follows:

Iceweasel: "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"
Konqueror: "text/html, image/jpeg;q=0.9, image/png;q=0.9,
text/*;q=0.9, image/*;q=0.9, */*;q=0.8"
Opera: "text/html, application/xml;q=0.9, application/xhtml+xml,
image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1"

The Iceweasel one is essentially useless for the multimedia case.
Konqueror's is slightly less useless (and it's missing some important
formats such as SVG and MNG), and even Opera's, which is the most
detailed, fails to report support for image formats that are actually
supported. And I don't see this improving a little bit when support
for multimedia format will be taken into consideration.

And of course, this disregards the fact that not all people have
complete access to the features of the web servers that hosts them,
and may not be able to configure it to handle content negotiation
properly.

> Thirdly, both the above techniques are already supported in existing,
> real-life browsers. A hypothetical "fallback:" URL scheme would not work in
> existing browsers, only being supported by shiny new browsers that were
> released after the fallback scheme was standardised. Thus anyone caring
> about backwards compatibility with older browsers (and surely backwards
> compatibility with older user agents is the entire point of providing
> fallbacks) would not use the scheme.

I do realize that the fallback scheme can hardly be backported to past
versions, but the whole point of it is to future-proof the next
versions, not the older one. It's a long-term approach. In fact,
that's the reason why I'm surprised something like it has not been
proposed much earlier on in the history of the Web.

_Of course_ it won't be globally deployable until it's widely
supported, but the same can be said about any new format or technology
that comes up: PNG, the failed MNG, SVG, the audio and video tags in
HTML5, and who knows what else will come up further down the road.

The big difference being, if the fallback scheme is adopted, it will
make things much easier for future enhancements. And (provided it's
cleanly defined) it wouldn't be too hard to implement either.

-- 
Giuseppe "Oblomov" Bilotta