- 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>
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 UTC