- From: Philip Jägenstedt <philipj@opera.com>
- Date: Mon, 11 Jun 2012 11:47:33 +0200
- To: "Ian Hickson" <ian@hixie.ch>, "Kit Grose" <kit@iqmultimedia.com.au>
- Cc: "<whatwg@lists.whatwg.org>" <whatwg@lists.whatwg.org>, Francis Boumphrey <boumphreyfr@gmail.com>
On Thu, 07 Jun 2012 04:06:10 +0200, Kit Grose <kit@iqmultimedia.com.au> wrote: > On 06/06/2012, at 7:44 AM, Ian Hickson wrote: >> On Fri, 13 Jan 2012, Kit Grose wrote: >>> >>> I'd argue that while we did receive in WebM "a common codec" it does >>> not >>> enjoy the sort of universal adoption required to be able to mandate its >>> support in the spec, so on that logic, I think establishing a >>> declarative fallback mechanism is probably required to prevent a >>> situation where you cannot write a robust HTML5 page with video and >>> without resorting to JS. >> >> I don't think it's time to give up yet, but maybe I'm overly >> optimistic... > > > Is there any reason why it wouldn't be prudent to render the content of > the <video> element as HTML if the video cannot be played, given that > fallback content in the video element is already supported for legacy > browsers in the spec: > >> Content may be provided inside the video element. User agents should >> not show this content to the user; it is intended for older Web >> browsers which do not support video, so that legacy video plugins can >> be tried, or to show text to the users of these older browsers >> informing them of how to access the video contents. > > How are legacy UAs without <video> support appreciably different from a > UA with restrictive or limited <video> support? Surely the author's > intent in either case is delivering the content in a different way or > delivering appropriate alternate content. > > Even if we eventually get a common codec (which I—perhaps overly > pessimistically—feel is unlikely), authors are already using the <video> > element without supplying whatever that eventual codec will be, and > users are suffering without reasonable fallbacks. > > As it stands, it's almost better (and certainly easier) for authors to > default to Flash video and use the existing, declarative fallback > behaviour of the <object> element to use a <video> element instead. That > can't be in the best interest of the open web. This was discussed in the thread "HTML 5 video tag questions" in 2009: http://lists.w3.org/Archives/Public/public-whatwg-archive/2009Jul/thread.html#msg278 The resource selection algorithm never fails - it simply waits for another source to be inserted - so the the hard part is when to show the fallback content. At the time I was very skeptical of switching back and forth between fallback and trying to load a video as more source elements are added, and I still am. -- Philip Jägenstedt Core Developer Opera Software
Received on Monday, 11 June 2012 09:48:02 UTC