Re: [whatwg] Video proposals

On Sun, 18 Mar 2007 20:08:43 +0100, Laurens Holst  
<lholst@students.cs.uu.nl> wrote:

> I think objects embedded by <object> should be able to provide an API,
> without needing a new tag to be introduced.

First, the problem with <object> is legacy, backwards compatibility and  
interoperability. Today, <object> is probably the least interoperable  
element in HTML. It works differently in almost all browsers (some share  
some characteristics, but they are in one way or another different and  
incompatible) and most authors have to use a combination of conditional  
comments, JavaScript and/or invalid markup to make a video play in all  
major browsers today.

By letting the mess that is <object> lay untouched as is, and instead  
focus the effort on something a bit more specific and new, the browsers  
might get it right this time. I agree on many of the comments about Audio  
vs Video and such, but dropping <object> in this case is imho a good way  
forward.

Second, we have a problem with APIs. Adding an API on top of <object> can  
prove to be really difficult. Microsoft already has a plethora of  
proprietary APIs for their ActiveX objects, tightly coupled to the ActiveX  
object rendered and the version of the object that is rendered. For  
instance, the API of Microsoft Windows Media Player 6 is very different  
 from Windows Media Player 9. Adding yet another API on top of this may be  
hard, if not even impossible.

Another problem with the API is that browsers (and authors) would have to  
switch API based on an often non-existing 'type' attribute. Given the poor  
support for <object> today, I doubt that's going to be a very solid  
solution. I predict that it's going to break in any number of ways because  
of the way <object> is implemented in today's browsers, as well as how  
they handle MIME types, content type sniffing, etc.

> But the mechanism should always be extensible, to allow plugin vendors
> to add functionality of their own where it is not specified.

For <object>, sure. But with <media>, <video>, <audio> or whatever the  
element is going to be called, I think we should have a standard API with  
a standard way to extend, e.g. setParameter('name', 'value'). That way,  
the browser vendors will implement the required mechanisms to support the  
playback, and if plugin authors wants to extend it, they can do it with a  
standard mechanism that won't break in browser X because the plugin vendor  
didn't implement support for it there.

> And btw, the <video> vs. semantics argument keeps popping up, but I find
> it very unconvincing. Semantics is nice and all, but it should not be a
> reason to include something in the specification if there isn’t a good
> use case for it (more than one, preferably), and so far I’ve yet to see
> anyone mention a good use case for marking it up from a semantics point
> of view. You also avoid it in your blog post (“you can then easily do
> specific things with it”), and the CSS bit Håkan posted earlier isn’t a
> very convincing one I think.

I think the element should be named <media>, but other than that, I think  
most of it is all dandy.

-- 
Asbjørn Ulsberg     -=|=-    http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»

Received on Monday, 19 March 2007 21:04:01 UTC