On 3/20/07, Robert Brodrecht [EMAIL PROTECTED] 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