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

Re: Adjusting the definition of fallback-free object

From: Joe D Williams <joedwil@earthlink.net>
Date: Wed, 3 Jun 2009 17:47:22 -0700
Message-ID: <A23814C732C54B72AABE2D2D169626E4@joe1446a4150a8>
To: "Ian Hickson" <ian@hixie.ch>, "Simon Pieters" <simonp@opera.com>
Cc: "public-html" <public-html@w3.org>


>> I've looked at 
>> http://philip.html5.org/data/object-with-id-or-name.xml.bz2
>> (don't open that in a browser) and noted the following:
>>  * Most have just an embed nested in object.

This is just a sad now obsolete workaround to capture an otherwise 
advanced browser that did not accept <object>.
No longer necessary in any browser since all now recognize <object> 
and the others are too old. Specialized viewers always use fallback 
content. Other reasons to also obsolete <embed>?

>>  * Some have nested objects. Many of those have one of the 
>> following nested in the inner object:
>>     - "FAIL (the browser should render some flash content, not 
>> this)." or

Sure, the fallback can be any HTML.

>> other copy-paste cruft

maybe latenight maniacal attempts to get somethng to work. Now is 
hopefully finally reached quiet of the current great united work in 
getting <object> to perform as expected wherever. If you had looked at 
one epoch there would be no object visible because it "had" to be 
generated by a script.

>>     - "<a href=...><img alt="Get Adobe Flash player" src=...></a>"
>>     - Actual alternative content (e.g. an image map)

Yes, anything to allow the user to help find the player, get past 
browser security, and finally play the thing as a secure accessible 
context of the host DOM.
X3D shows this:

Adobe always has fairly complete and current info to get theirs 
Fortunately, they are also able to move away from <embed> and get what 
is wanted although <embed> is tuned for Flash, which is fine because 
it is pretty much self-contained.
Most producers that use plugins want it to be a complete scriptable 
object with a reasonable way to define and use parameters used by the 
plugin for initialization and runtime.

>>  * None of them had an <applet> nested in <object>

Not likely to find that one, OK to obsolete <applet>.

>>  * None of them had an <iframe> nested in <object>.

Another very rare one although it should work since <iframe> is any 
More likely <object> in <iframe> or other block.

>>  * A few have <form> (with id/name) nested in <object>.

A <form> as fallback content for <object>?
I think that might be an advanced example and maybe the reason for the 
presence of name attriburte?
Would this solve a security issue by producing a nested 

>> In conclusion, I think the list should be just object and embed.

How is name used? How would user/author/player use it differently than 
>From a script, the object interfaces can use the id as in
 document.myobj.prop = ...
 without need of a name attribute.
<object id='myobj' ...>
<param name='prop' value='list'>

>From the title "Adjusting the definition of fallback-free object", of 
the embedded group only <object> and <video> have a fallback behavior. 
<video> just uses a certain attribute, poster. <object> is unique in 
offering progressive fallback, I think. But I think I also want smart 
fallback in <source> element?.

> Done.

Again, Thanks for the great work by all the W3C authors and browser 
makers to provide a consistent <object> element.

Thanks Again and Best Regards,
Received on Thursday, 4 June 2009 00:48:03 UTC

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