[whatwg] HTML 5 video tag questions

[Tab Atkins Jr.]

On Tue, Jul 14, 2009 at 3:29 AM, Philip Jägenstedt<philipj at opera.com> wrote:
> On Mon, 13 Jul 2009 23:32:44 +0200, Tab Atkins Jr. <jackalmage at gmail.com>
> wrote:
>> <source> elements, change step 3 so that whenever any of those
>> conditions are met, if the <source> has @fallback the algorithm aborts
>> immediately and shows the fallback content, otherwise it fires the
>> error event and jumps to the "search loop" step as normal.
>
> This would only cause fallback to be used when the source element is
> rejected up front, not if it is a candidate for the resource fetch algorithm
> that fails to fetch/play. So you also need to check @fallback before step 6.
> However, by then the source element may very well be removed from the DOM,
> so I you'd have to assign @fallback to a variable earlier in the algorithm
> and check that.

Ah, yes, you're right.  You'd have to check for @fallback at the end
of substep 2 (those subsubsteps are guaranteed atomic, so no race
condition) and set a flag, then actually activate fallback if the
algorithm fails at step 3 or 6.

> This approach is implementable in my guesstimation, but I'd really want to
> know more about the history of object fallback issues. Should fallback
> content be treated as if it were display:none, or are there nastier hacks
> involved?

As others note in emails following yours, there are already issues
with the existing defined fallback content.  Once those are
successfully resolved, I believe it should work fine for here as well.
 Successfully resolving them, though, will almost certainly require
"nastier hacks".

>> Alternately, we could just put @fallback always on the <video> element
>> directly, rather than on <source>.  That would preserve the first part
>> of what I said, but now we have a step between substeps 9 and 10 that
>> checks for @fallback on the <video>.  If it finds it, it immediately
>> aborts and shows the fallback content, otherwise substep 10 proceeds
>> normally (waiting forever).
>
> That would cause the fallback to be triggered unconditionally during
> parsing:
>
> <video fallback>
> <source src="foo" type="video/x-unsupported">
> <!-- steps 8-10 run here -->
> <source src="bar" type="video/x-supported">
> </video>
>
> There's nothing in the resource selection algorithm that's special-cased for
> static markup by hooking into the parser, which would be required to make it
> work (but then only for static markup). Putting @fallback on the video
> element just won't work.

Sorry, I assumed that checking it at step 10 *did* effectively
special-case static markup.  I assume that I'm wrong because the delay
could just be due to the network/parser being slow at receiving and
adding the <source> elements that are supposed to be in the the static
document?

If so, then yeah, you're right.  @fallback can only be placed on
<video @src>, but not when <source> elements are involved.

~TJ