On Mon, 13 Jul 2009 11:14:21 +0200, Jonas Sicking <jo...@sicking.cc> wrote:
On Sun, Jul 12, 2009 at 11:20 PM, Ian Hickson<i...@hixie.ch> wrote:
On Fri, 10 Jul 2009, Jonas Sicking wrote:
>>
>> Hmm.. is that good? What if you want to use an <object> (to use
flash
>> or java) or a <img> as fallback?
>
> Then you do it with script.
>
> The design is based around the assumption that we will eventually
find
> a common codec so that fallback won't ever be needed in supporting
> UAs.
I agree that the current design makes sense once there is a common
codec
supported across all browsers. However currently it seems like we might
not reach that point until after all major browsers support <video>.
What would be the downside of displaying the fallback contents if none
of the videos can be displayed due to unsupported codecs?
When would you fall back? For example, while parsing, would you fall
back
in between the <video> element being parsed and the first <source>
element
being parsed?
You could display the fallback once you've reached the </video> and
not found an acceptable <source>. Technically it'd be when you pop the
video element off the stack of open elements. I don't even think it'd
be hard to pull down all <source>s and check that none of them are
supported before displaying the fallback if types aren't specified on
the <source> element.
It would have to be part of the resource selection algorithm. Since that
waits for new source elements indefinitely, when exactly would you decide
to switch to fallback content? Bad solutions include special-casing static
markup and/or (falsely) assuming that scripts will not insert more source
elements at some point. If fallback content is defined simply as the
content of the video element I also can't figure out any other solutions.
The design you describe is what <object> tried to do, and it proved to
be
extremely problematic in practice -- and that was without another
built-in
fallback mechanism to complicate matters.
While <object> has had a very poor implementation story, I don't think
this was a big reason for that.
Robert O'Callahan, Boris Zbarsky and other gecko layout folks can
answer this better, but at least in gecko I don't think this part of
object was particularly hard to implement correctly once we actually
tried.
Has any browser vendor argued against displaying the fallback due to
high implementation burden?
Implementation probably isn't the biggest burden here, specifying sane
behavior is. For example:
If fallback content is displayed after the last source element has failed,
what should happen when a new source element is inserted? Switching back
to "video mode" would make it even more special than object fallback and
if you don't you'll just get stuck with fallback and have effectively
broken the possibility of inserting source elements via scripts.
Something like <video><source
src="cant.play.ogg"><new-fallback-element>Ooops!</new-fallback-element></video>
is what you'd need to make the resource selection algorithm deal with
fallback in a sane way when scripts are disabled, but this is too much of
a corner case to justify the complexity in my opinion.
--
Philip Jägenstedt
Core Developer
Opera Software
