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
