Re: Short-term workarounds - - <source> in <video>

On Thu, Oct 22, 2009 at 9:23 PM, Joe D Williams <> wrote:
> Hi Ian,
> " ... are only short-term workarounds, and the same applies to, e.g.,
> <source> in <video>, or <command>, ... "
> this quote was in another topic but it caught my eye because I'm not sure
> how <source> constitutes a workaround; what is the problem allowing multiple
> <source > elements is not solving?
> I thought the purpose was to allow authoring a simple fallback scheme by
> offering a list of candidate forms and in case the first <source> didn't
> work, then the second <source> would be tried. Finally if non of the listed
> sources could be played, then <video> would fallback to a nested html
> element for another attempt. This is a great simplification from <object>
> for instance where I only get only one type/source try before fallback to
> the nested node. Your complete phrase included <command> which I need to
> look at, but for <video> and <audio> why to characterize <source> as a
> short-term workaround?
> I only know of one alternative and that could be to allow the src to list
> multiple resources in the string, maybe separated by space or , but multiple
> <source> elements work fine. Anyway, I just thought I would check in on this
> before I start advocating adding the use of multiple <source> elements in
> <object>. It's a natural fit.

You misunderstood slightly.  ^_^  Ian was referring to the fact that
<source>, being a new void element, doesn't work properly in current
browsers (they treat it as as the start tag of an unknown element).
<command> is another new void element with similar problems.


Received on Friday, 23 October 2009 02:29:30 UTC