W3C home > Mailing lists > Public > public-html@w3.org > May 2009

<object> element

From: Joe D Williams <joedwil@earthlink.net>
Date: Sun, 31 May 2009 13:36:33 -0700
Message-ID: <7B7C095CC23940179030C3898BCB66D9@joe1446a4150a8>
To: "Ian Hickson" <ian@hixie.ch>, "Larry Masinter" <masinter@adobe.com>
Cc: "HTML WG" <public-html@w3.org>
from Subject: was RE: HTML interpreter vs. HTML user agent

Sunday, May 31, 2009 10:58 AM Ian Hickson wrote:

> ...though that's not been requested by implementors so far.

Hi, speaking as an author-implementor, that is an author attempting to 
implement content using an embedded scriptable object plugin player, 
all I ask is that the W3C host browser makes it so that the user of 
the html5 tool is presented with an experience I can have some hope of 
predicting. Then I can plan for what will happen if the content is 
presented just exactly as I would wish, and to plan for however many 
levels of fallback seem feasible depending upon the user preferences 
and the user interface possiblities. Over the years, the <object> 
element has become the element of choice, due to the fact that more 
W3C browsers are really trying to accomplish a meaningful design that 
allows free and secure live communication between the DOM host and the 
active embedded object. VRML/X3D players have mostly agreed, or are 
agreeing, on the kind of host behaviors and services they would like 
to see and there is a mostly agreed upon sets of preferred DOM 
techniques and 'standard' <param> pairs used to control the plugin 
runtime. Yet the X3D players are also wavering on some simple 
decisions, such as a consensus on a <param> to pass the target content 
url. As a result, the current main web3d.org embedding example 
duplicates the data attr and the src param. That is where a user just 
walking up to this would be confused. Why do that? Of course since I 
have mostly followed how the <object> element and associated <param> 
element behavior has evolved, especially over the last 7 or so years, 
with new and improved W3C UAs, more 'open' vm possibilities that want 
to be an <object> emerging, and the fantastic improvements in W3C 
browser technology and robustness, I know it is better than ever! 
Overall, an author depending upon the <object> element for interactive 
multiple media has a better chance of success than at any time ever. 
It will only get better with deeper integration of interactive 
hyperlinked multiple media as the WWW advances technically.

Of course I need to look more at and catch up on some surrounding 
<object> issues like sandboxing and seamlessing and sniffing, but 
starting out, here is one simple suggestion:

* Obsolete using <embed> as a fallback for <object>.

Move <embed> to Obsolete, like <applet>.
There are no more processors that do not recognize <object> but 
recognize <embed>
Sure, <embed> came first but it became archaic and is fully replaced 
and extended by <object>.
Fairlly easy transform to replace <embed> with <object> or provide 
meaningfull fallback.
Focus on just one of these, the advanced case, <object> will improve 
secure support for plugin handling and web content authoring tools and 

Thanks to All and Best Regards,
Received on Sunday, 31 May 2009 20:37:16 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:47 UTC