- From: Jonny Axelsson <jonny@metastasis.net>
- Date: Mon, 31 Jan 2000 22:56:14 +0100
- To: www-html@w3.org
At 11:44 31.01.00 -0800, Murray Altheim wrote: >Last week the HTML WG decided to include <object> in XHTML 1.1. We are >currently developing a requirements document with the idea that it will >likely be completely reengineered for XHTML 2.0. I'm happy. Removing it from XHTML 1.1 would have killed it. While OBJECT may have some warts, they doesn't warrant a kill and resurrect procedure (IMHO, of course). >Unfortunately, I don't have at this point time to enumerate specific >problems. The gist is that there are 36 attributes, used in various >combinations to support a number of different uses of <object>. In addition >to the attributes in the HTML 4.0 Specification, there are *many* other >unofficial attributes used to support various other media types (apparently >Apple has added around 30 to support QuickTime, although I've not >substantiated this myself). Point taken. The attribute list/interpretation could be simplified without losing power or extensibility. A single attribute (type) should be sufficient as a decision mechanism, the rest should be handled by the agent (internal or external) set to manage that media type. If that needs 30 attributes, so be it as long as it doesn't bother the HTML UA. Though I find it hard to believe that those attributes wouldn't be PARAMetres. Admittedly I'm not an UA developer in anything but the most primitive sense, so my mental model may be off-target, but what is wrong with this mechanism? 1. OBJECT: Start inclusion procedure, placeholder for references to #object-id 2. Decide which agent to handle the object based on TYPE 3. Deliver OBJECT start tag and parametres to it 4. Continue the parsing %atts;, height, width, usemap, declare and standby will be used by the UI (name will be generally depreciated?). >I don't see any reason to believe anything with an underspecified, >complex interaction of contextually variant attributes could be >anything but difficult to implement. The fact that two years have >passed and nobody has been able to implement it fully should tell It is an indication, but the argument on its own that argument would imply that CSS is unimplementable, just because Netscape never bothered to try until Microsoft did. Mozilla and Opera implementors may tell if OBJECT is a pain to implement or not, as both Opera 4 and Mozilla 5 supposedly will implement OBJECT. >> (*) It is simple to remove. This is important in practice. Just give >> yourself a capabilities list of NONE. > >Well, most things are pretty simple to remove. This is not a major point, but it isn't as trivial as it may seem, if you just want to remove included elements, but nothing else and you don't have a list of all possible inclusion elements or attributes. If inclusion <=> object, it is trivial. >> (*) It is of course easy to extend, and in a way that doesn't add >> complexity of the UA. If the new object is on the capabilities list, fine. >> If it isn't, next. > >It is not extensible, in that a number of media types added proprietary >attributes to supply information not permitted in <object>, such as timing >or other display information. The only way to extend it is to add >proprietary markup. Shouldn't that be in the PARAM element? The object element should tell what, how and and where, while param should do the particulars (In My Ignorant Opinion).
Received on Monday, 31 January 2000 16:57:04 UTC