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. —Kit Grose
