[whatwg] HTML 5 video tag questions
Tab Atkins Jr.
jackalmage at gmail.com
Tue Jul 14 06:03:16 PDT 2009
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>
>> <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
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
>> 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
> <video fallback>
> <source src="foo" type="video/x-unsupported">
> <!-- steps 8-10 run here -->
> <source src="bar" type="video/x-supported">
> 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
If so, then yeah, you're right. @fallback can only be placed on
<video @src>, but not when <source> elements are involved.
More information about the whatwg