- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 22 Oct 2009 21:28:38 -0500
- To: Joe D Williams <joedwil@earthlink.net>
- Cc: HTMLWG WG <public-html@w3.org>
On Thu, Oct 22, 2009 at 9:23 PM, Joe D Williams <joedwil@earthlink.net> 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. ~TJ
Received on Friday, 23 October 2009 02:29:30 UTC