[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On 16 Aug 2009, at 16:45, Giuseppe Bilotta wrote:
On Sun, Aug 16, 2009 at 4:04 PM, Toby A Inkster<mail at tobyinkster.co.uk> wrote: 
>
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.
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. 


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>


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.
Indeed. It's reasonably common to use Accept to decide whether to serve an XHTML page as application/xhtml+xml or text/html for older browsers that can't handle the former.
It's also common in the linked data world to use connection negotiation to send HTML to human visitors and RDF data to automated software.
My own homepage, http://tobyinkster.co.uk/ is connection negotiated between 9 different formats. 


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" 


The Iceweasel one is essentially useless for the multimedia case.
Firefox 3.5 (and Iceweasel is just an unbranded version of Firefox) actually sends context-sensitive Accept headers. If you request a web page, you will see the above. 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.) 


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. 


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

, and even Opera's, which is the most
detailed, fails to report support for image formats that are actually
supported.
It is unusual that SVG is not explicitly listed while XBitmap is (despite being pretty rare these days). SVG can of course be served as application/xml though image/svg+xml is far more common. Note that the low-priority (q=0.1) wildcard (*/*) matches SVG, though because of the priority, PNG, JPEG and GIF will generally be sent in preference. 


And I don't see this improving a little bit when support
for multimedia format will be taken into consideration.
It is true that current browser Accept headers are not perfect, but they'd be pretty easy to fix up if a little pressure was applied to browser vendors.
Content negotiation is also more wide-ranging than just negotiating media types. It allows languages to be negotiated (e.g. a French user can receive the French version of a document, while a Brazilian user will receive a Portuguese version at the same URL) and negotiation of charsets too. 

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

--
Toby A Inkster
<mailto:mail at tobyinkster.co.uk>
<http://tobyinkster.co.uk>