Why <video>? (was Re: Microsoft has now joined the HTML Working Group)

On Apr 5, 2007, at 2:05 PM, Chris Wilson wrote:

>
> [co-chair hat off]
> Matthew Raymond [mailto:mattraymond@earthlink.net] wrote:
>> 1) What's your position on <video> and using Ogg Theora as the format
>> that all browsers SHOULD support?
>
> See other thread from this morning about Theora.  On <video>, I'm  
> not sure I really see the need over fixing implementations of  
> <object>, and I'd like to understand that better but haven't had  
> the time;

I'm guessing you haven't followed the <video> discussion on the WHAT  
WG list. Here are some of the reasons to have <video>:

1) <video> has better syntax for video embedding than that available  
using <object>. It is easier for authors to generate (there will  
likely be no more need to copy magic recipes from web sites for  
simple video embedding). And it should be easier for systems that  
mine documents for data to identify as video (imagine a search engine  
that wanted to identify most popular videos of the day).

2) <video> has a consistent API that is sufficient for building  
custom playback controls and other likely web uses; currently if you  
want to support multiple formats using requests for multiple plugins,  
you get a different API for each.

3) <video> as specced in HTML5 has a better approach to format-based  
fallback than <object>. Alternate media are specified as <source>  
elements inside the <video>, but the same <video> element is used  
regardless of selected source, which avoids the <object> problem that  
you have to guess which one is actually active to find the right  
object to make API calls on. The <source> elements can also match  
based on codec, not just container type, which is all the MIME type  
usually tells you. (<video> can still fall back to an <object> in  
browsers that don't support it at all.)

4) <object> is already incredibly complex and overloaded with a  
number of different functionalities; this is part of what leads to  
the lack of interoperability. Overloading it further with rich  
functionality for timed media may well strain its complexity to the  
breaking point.

> and we would need to be equitable with audio, too, I'd imagine.

There is also a corresponding <audio> element which shares much of  
the same API and functionality.

Regards,
Maciej


P.S.:

> I explicitly cannot comment on features that will go in to the next  
> version of IE, as a matter of policy.  I think Apple needs to agree  
> that canvas should be pursued in the HTML WG, and then we can have  
> the discussion as a WG.  I'm not against canvas as a matter of  
> policy or anything.

For what it's worth: Per the W3C patent policy, all that would be  
necessary is for Apple not to call for exclusion on the patent in a  
limited time window after the first public working draft. Apple's  
active approval would not be needed to include it in the spec.

Received on Friday, 6 April 2007 02:51:10 UTC