- From: Shadow2531 <shadow2531@gmail.com>
- Date: Wed, 21 Mar 2007 07:10:26 -0400
On 3/20/07, Robert Brodrecht <whatwg at robertdot.org> wrote: > > Simon Pieters said: > > Oh. I thought <video> fallback would work pretty much like <object> > > fallback, but I see that's not the case. When I think about it it makes > > sense; <video> is pretty much like <iframe>, it never falls back in UAs > > that support it. > > Oh, damn it. I thought it'd work like <object>, too. I'm not sure I like > the only-fallback-if-no-support idea. I'm getting the feeling that there > won't be one common video format among the browsers. I think not having > fallback to nested video elements to get at other formats would ultimately > be a bad thing. It is different than expected, but I can now see why video would want to avoid these things. If you load an applet, with the object element, it'll never fallback (even if the class file can't be found) unless java is turned off or not supported. If you load <object type="application/x-mplayer2", in some browsers, it might never fallback unless plugins are off or the plugin is not installed (same with REAL and other plugins). In other browsers, it might fall back because there's no data attribute. However, there are use cases where data is not needed or not even wanted and it shouldn't fall back because of this missing data. The object element only really falls back like we want it to half the time. Usually, it only works right with native stuff. However, with the video element, we have the chance to described exactly when fallback should happen in every case. Right now, as was said, it works more like an iframe. -- burnout426
Received on Wednesday, 21 March 2007 04:10:26 UTC