On Thu, 03 Dec 2009 14:31:41 +0100, Kornel Lesiński <[email protected]>
wrote:
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>
This has been proposed before, it is technically possible, but I don't
particularly support it because it adds complexity for very little gain.
Is the only problem we are trying to solve falling back to some legacy
markup when the video format isn't supported? Given that there are only 2
relevant formats so far, that doesn't seem like a problem worthwhile
solving.
--
Philip Jägenstedt
Core Developer
Opera Software
