W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2009

[whatwg] HTML5 video element - default to fallback in cases where UA can't play format

From: Kornel Lesiński <kornel@geekhood.net>
Date: Thu, 3 Dec 2009 13:31:41 +0000
Message-ID: <2D885D58-F9EF-4FAA-B2FE-6E1E66C69BBB@geekhood.net>
>> Can someone explain to me how this works, given Aryeh's response  
>> above? Surely if the iPhone can determine its capacity to be able  
>> to play a video file, other UAs could do likewise and fall back on  
>> the content accordingly as UAs with zero <video> support do?
>
> I know nothing about the iPhone, but any UA can know if it can play  
> a resource or not simply by trying and adjusting the UI as  
> appropriate. One *could* use the same hooks to display fallback  
> content in those cases, but it is a very bad idea. Apart from the  
> things Aryeh mention, because of how the resource selection  
> algorithm works, you can never know if there will be a playable  
> resource later, so there's no point where it's appropriate to show  
> the fallback content. The only remaining option is flip-flopping  
> between replaced content (video) and fallback content, which don't  
> want (especially considering that the fallback content is likely to  
> contain <object> for Flash or some other legacy fallback).

How about making end of selection algorithm explicit?

Something like video.imDoneWithSourcesEitherPlayOrShowFallback()  
method, which upon failure permanently locks <video> in fallback state  
(to avoid flip-flopping).

or a special source that, if selected, triggers fallback:

<video>
	<source src=file>
	<source fallback> (or <source src="#fallback">?)
</video>

-- 
regards, Kornel
Received on Thursday, 3 December 2009 05:31:41 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:54 UTC