W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2012

Re: [whatwg] video element not ready for prime time

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>
Message-ID: <op.wfqf5julsr6mfa@kirk>
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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:43 UTC