On 28/10/2009, at 1:10 PM, Aryeh Gregor wrote: > On Tue, Oct 27, 2009 at 7:40 PM, Kit Grose <k...@iqmultimedia.com.au> 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? —Kit
