On Thu, 03 Dec 2009 03:31:27 +0100, Kit Grose <[email protected]>
wrote:
On 28/10/2009, at 1:10 PM, Aryeh Gregor wrote:
On Tue, Oct 27, 2009 at 7:40 PM, Kit Grose <[email protected]>
wrote:
Can I get some sort of an understanding on why this behaviour (non-
descript error in supported UAs rather than using the fallback content
that can provide alternate access methods) would be preferred?
Suppose browsers fell back to the contents if they couldn't play any
of the sources. Then what happens if the browser isn't sure whether
it can play a video until it's started loading it? This would be
extremely common -- it would happen any time the source is given with
src="", or if <source> elements are given with no type="", or even if
there was a type="" but the browser wasn't sure it supported the exact
versions or didn't fully trust the author or whatnot. Then does the
browser not load the contents until it figures out it can't play the
video, then load the contents at some undefined later time? So
scripts execute out of order and so on?
Sorry to resurrect an old thread but I was using my iPhone and had an
extra couple of questions about this I was hoping people might be able
to answer for me.
The iPhone (and other similar devices) are restricted to certain file
formats and even bitrates/image sizes. When the iPhone encounters our
<video> element, I can supply a non-compatible video (still in an MP4
container) and the iPhone knows to mark the video in place as
non-playable. If I whack in a compatible H.264 video, the video is shown
as playable.
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).
--
Philip Jägenstedt
Core Developer
Opera Software
