- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 13 Jul 2009 16:32:44 -0500
On Mon, Jul 13, 2009 at 4:01 PM, Philip J?genstedt<philipj at opera.com> wrote: > 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. 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 > > <video> > <source fallback> > <source src="cant.play.ogg"> > fallback here > </video> > > ? 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 >>> >>> 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. >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). ~TJ
Received on Monday, 13 July 2009 14:32:44 UTC