W3C home > Mailing lists > Public > public-html@w3.org > January to March 2007

Re: [whatwg] Video proposals

From: Asbjørn Ulsberg <asbjorn@ulsberg.no>
Date: Wed, 21 Mar 2007 12:24:52 +0100
To: "Jirka Kosek" <jirka@kosek.cz>
Cc: "Laurens Holst" <lholst@students.cs.uu.nl>, "Anne van Kesteren" <annevk@opera.com>, matt@builtfromsource.com, public-html@w3.org, "WHAT WG" <whatwg@lists.whatwg.org>
Message-ID: <op.tpjdzqtq5rel5w@quark>

On Mon, 19 Mar 2007 22:55:05 +0100, Jirka Kosek <jirka@kosek.cz> wrote:

> So in other words browser vendors have to implement support for a new
> element in order to show video, audio, ... But if they have to create
> new code why then they just not fix existing code for handling object
> element?

Because fixing the bugs in the <object> implementation will break legacy  
code and thus hurt backward compatibility.

> If the browser is able to recognize whether object should be treated as
> image or video or audio or whatever in order to present it to user then
> it must be able to provide correct API -- for treating timelined media,
> for images, ...

The problem is that today, it's not the media type that decides what API  
you get when programming against an <object> element (or rather, the  
plugin loaded inside it), it's the plugin itself. There's no way to  
generalize the media you see on the web today and say "everything that  
looks like video should have this API, and everything that looks like  
audio should have that API", because the media out there today already  
implements a completely different API from one another regardless of  
whether it's audio or video, and tightly coupled to the plugin being used  
to render the media.

> I think that such problems could be easily solved by class inheritance.

It's a good idea, but I don't think it can be solved. Not without breaking  
backward compatibility.

> There could be very basic API for general object element and specialized
> and more rich APIs will exists for objects handling video, audio, images,
> embeded code (like Java Applet or ActiveX).

But what about the Windows Media Player API exposed through the Windows  
Media Player plugin today? Should support for that just be dropped? And  
what about all the unique APIs authors have created for themselves with  
Flash, not to mention the Flash API itself?

> And what about backward compatibility? Reasonable webdesigner will never
> use such new element because there are too many browsers which are not
> supporting it. The problem is not in markup, nor in element name -- the
> problem is poor implementation in browsers and new element name will not
> improve situation.

   <video src="...">
     <object classid="...">
       <object data="...">
         <img src="..." alt="Alternate text">
       </object>
     </object>
   </video>

This works already today. The <video> element will be ignored by browsers  
not supporting it, the first <object> element will be ignored by browsers  
not supporting 'classid', the second <object> will be ignored by browsers  
not supporting <object> at all and the 'alt' text of the image will  
ultimately be rendered by browsers without image support.

It is a bit more complex than the above example, but the basics are the  
same.

-- 
Asbjørn Ulsberg     -=|=-    http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»
Received on Wednesday, 21 March 2007 11:24:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 21 March 2007 11:24:56 GMT