On Mon, 13 Jul 2009 21:28:45 +0200, Tab Atkins Jr. <jackalm...@gmail.com>
wrote:
On Mon, Jul 13, 2009 at 2:15 PM, Philip Jägenstedt<phil...@opera.com>
wrote:
On Mon, 13 Jul 2009 20:38:11 +0200, Tab Atkins Jr.
<jackalm...@gmail.com>
wrote:
On Mon, Jul 13, 2009 at 1:33 PM, Boris Zbarsky<bzbar...@mit.edu> wrote:
Philip Jägenstedt wrote:
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.
A <source> that says "use the content"?
-Boris
Ie inserting <source fallback> or <source contents>. If both @src and
@fallback are specified on a <source>, it is treated like a <source
src><source fallback>; that is, it first tries the @src attribute, and
if that doesn't work, then it goes to the fallback content.
That would require the parser to inspect an attribute to determine if
the
element is a void element (one that does not have a closing tag) or not,
which I've been told is not very nice. Are there any other such cases?
Hm? I'm not sure what you mean here. It would work like this:
<video>
<source src="foo">
<source src="bar">
<source fallback>
<p>I'm some fallback content!</p>
</video>
You'll see the <p> if the browser doesn't support <video>, or if the
resource selection algorithm hits that third source and hasn't found
anything it can play yet. It wouldn't change whether the <source> is
a void element or not.
I thought you meant
<video>
<source fallback>
fallback content here
</source>
</video>
I would prefer if fallback content and source elements weren't mixed on
the same level, but maybe that's just me.
(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
<video>
<source fallback>
<source src="cant.play.ogg">
fallback here
</video>
?
Is fallback irrevocable or could the same video element go back to showing
video under some circumstances? Does audio also have fallback content?
This is why I suggested <video><source
src="cant.play.ogg"><new-fallback-element>Ooops!</new-fallback-element></video>
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.
The browsers that have already shipped with video don't support fallback
but they are the ones that are the most likely to need it (assuming that
format support will get better over time). It would be nice to hear what
they think about all of this.
--
Philip Jägenstedt
Core Developer
Opera Software
