Re: <video> element feedback

Ian,

Thanks; that's a good point.  I see the need for a standalone element now.
 However, two points:

a) The current API for Video as specified in the WHAT specification
applies just as easily to audio, except for videoWidth and videoHeight
properties.  What are the barriers to a single element with a common
interface?

b) The element (whatever it becomes) should handle all video, not just
native video.  Otherwise, there is too much room for confusion.  Browsers
should see if a video is unsupported and show the fallback message, which
would contain a link to download the appropriate software.  For example,

<video src="example.wmv">
    This is a Windows Media Video file, but you need to download
such-and-such to display it in your browser.
<video>

This differs from Img in that Img supports the most common image formats
(JPEG, GIF, PNG; although this is a bit of a chicken-and-egg situation)
whereas Video would only support Ogg--and not even all Ogg video formats,
but only Theora, from what I've heard.  It would be like if Img only
supported PNG.  Digital camera software usually supports JPEG, but not
PNG; similarly, many video products support MPEG, but not Ogg-Theora. 
Such a narrow scope would lead to confusion, frustration, and hassle on
the part of users who won't understand why Video only supports Ogg Theora,
or even know what that is, but just want it to work with their WMV.

-Matt

On Tue, March 20, 2007 2:25 am, Ian Hickson wrote:
> ON HANDLING OTHER MEDIA FORMATS:
>
> A lot of feedback concerned the necessity of introducing an element
> specifically for <video> in the first place.
>
> We could use <object> for this, adding multiple APIs to <object> for each
> kind of media file, defining the semantics for changing from one to the
> other, for content-negotiation, for disambiguating similar media types
> that have overlapping but not identical APIs, and so forth.
>
> However, the browser vendors would hate us. Browser vendors have
> repeatedly and loudly stated that overloading elements leads to
> implementation difficulties, resulting in poor interoperability, edge
> cases with strange behaviour, security bugs, and the works. Good examples
> of this in existing HTML browsers are <object> and <input>, both of which
> have had huge interoperability problems over the years, and both of which
> still have big issues. When it takes more than 10 years to get an element
> implemented well in every single browser that has tried to implement it,
> you have to look at why that is, and you have to learn from the mistake.
> In this case, the mistake is adding too much functionality to one element.
>
> Similarly, for backwards-compatibility reasons, adding anything to
> <object> is a nightmare. We'd have to carefully examine every addition to
> make sure it didn't clash with existing content, for instance.
>
> Furthermore, overloading an element with various APIs results in
> difficulties for authors. An author dealing with audio doesn't want to
> think about aspect ratios, and an author dealing with video doesn't want
> to think about plugin parameters.
>
> This doesn't mean we have to specify everything as its own element. There
> are media types that it doesn't make sense to support with a specific
> element (at least not yet); we don't want to have six dozen elements with
> each type having its own set of features (and bugs). We _do_ have a
> generic element, <object>, which does work for generic inclusion. It
> doesn't support media-specific features (like the Video API) but it works
> as a stop-gap until the media in question is important enough to deserve
> special treatment, if that happens.

Received on Tuesday, 20 March 2007 18:39:04 UTC