- From: Maciej Stachowiak <mjs@apple.com>
- Date: Thu, 5 Apr 2007 19:23:36 -0700
- To: Chris Wilson <Chris.Wilson@microsoft.com>
- Cc: Matthew Raymond <mattraymond@earthlink.net>, "public-html@w3.org" <public-html@w3.org>
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