[whatwg] HTML 5 video tag questions
Tab Atkins Jr.
jackalmage at gmail.com
Mon Jul 13 14:32:44 PDT 2009
On Mon, Jul 13, 2009 at 4:01 PM, Philip Jägenstedt<philipj at opera.com> wrote:
> I thought you meant
> <source fallback>
> fallback content here
> I would prefer if fallback content and source elements weren't mixed on the
> same level, but maybe that's just me.
Eh, fallback content for non-<video> browsers is already there, so
it's nothing new.
>> (You could also just put @fallback on the second <source> and drop the
>> third <source> entirely for the same effect.)
> Once the source element is iterated by the resource selection algorithm and
> starts loading, the fallback attribute or the whole source element might be
> removed. You would have to set a flag at some point to remember the fallback
> state and unset it... when? What is the effect of
> <source fallback>
> <source src="cant.play.ogg">
> fallback here
It would hit the first <source>, note that there's no @src, see that
there is @fallback, and immediately drop to showing fallback content.
> Is fallback irrevocable or could the same video element go back to showing
> video under some circumstances?
It should be revocable in the exact same circumstances that a <video>
element might start playing from one <source>, and then switch to
another. From my reading of the algorithm I don't think this is
possible, so fallback would be irrevocable.
> Does audio also have fallback content?
It uses <source> and the same source-selection algorithm (and the same
fallback situation in the case of non-<audio> browsers), so yes.
>>> This is why I suggested <video><source
>>> I still think the use of this is questionable though.
>> I'm not sure why you think the usecase is questionable. It seems
>> pretty clear - it'd be nice to have a non-script way of showing
>> content (specifically, alternate video players) when the browser
>> supports <video> but can't play any of the provided sources.
> Yes, handling the (minor) use case video support + no supported source + no
> script would be nice, but only if it doesn't make an even bigger mess of the
> resource selection algorithm and doesn't allow switching back and forth
> between video and fallback.
>From what I can tell of the resource selection algorithm, fallback
should be irrevocable, just like a successful <source> load is.
The resource selection algorithm appears to need fairly trivial
changes to accommodate this. Step 4, when parsing @src from <video>,
insert a new substep between substeps 2 and 3. Pull the first
sentence from the current substep 3 into this new substep, and say
something like "If the element has a fallback attribute, abort this
algorithm immediately and display the fallback content." When parsing
<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.
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).
More information about the whatwg