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

Re: http content type authoritative for object data?

From: Joe D Williams <joedwil@earthlink.net>
Date: Sat, 12 Dec 2009 10:24:41 -0800
Message-ID: <F565E90E8DD44166BC4752D3EBBBF200@joe1446a4150a8>
To: "Julian Reschke" <julian.reschke@gmx.de>
Cc: "Jonas Sicking" <jonas@sicking.cc>, "Boris Zbarsky" <bzbarsky@mit.edu>, <public-html@w3.org>

> Joe D Williams wrote:
>> What, step up to YouTube and tell them how full of it they are for 
>> using mindless junk like this?
>> <object style="height: 344px; width: 425px" >
>> <param name="movie" value="http://www.youtube.com/v/vwI3tL2yc6k">
>> <param name="allowFullScreen" value="true">
>> <param name="allowScriptAccess" value="always">
>> <embed src="http://www.youtube.com/v/vwI3tL2yc6k"
>> type="application/x-shockwave-flash"
>> allowfullscreen="true" allowScriptAccess="always"
>> width="425" height="344">
>> </object>

I know I shouldn't be critical about YouTube or any other coder and 
formatter styles because of the long series of evolutions they needed 
to use over the years while the major browsers were bringing <object> 
into the mix to replace <embed>. They have had to chase solutions over 
time as the movie player form reached its present state along with 
browsers changing and adapting to user needs, fears, and preferences. 
As we can see, the final solution is still somewhat in doubt. 
Hopefully we will see <video> and <audio> take over this part of the 
solution and, with <canvas> working in a wide range of interactive 
graphical solutions, we can start to deal with <object> as a live, 
general-purpose tool for extending HTML rather than being tuned for 
Flash and other movie forms. Maybe play on some of the substantial 
standardized intelligence of servers and clients.

Besides, it may not be that great of an example anyway because this 
was just suggested code, not the scripti-generted <object> acrtually 
created on the owner's YouTube page.

>> Good Luck and Best Regards,
>> Joe
> Ignoring the <embed> for a moment... The <object> tags looks good to 
> me, the type is not declared,

To me, this <object> element is not reasonable because @type is not 
Alone, this code

<object style="height: 344px; width: 425px" >
<param name="movie" value="http://www.youtube.com/v/vwI3tL2yc6k">
<param name="allowFullScreen" value="true">
<param name="allowScriptAccess" value="always">
<fallback html>

tells the UA absolutely nothing about what it might be working with.
Here, @type is missing and no @data so the UA has nothing to determine 
what processing to use.
If @type was there then the UA could begin to fire up the context that 
will represent the object in the DOM.
What to do? I would say nothing and go to fallback,
That is too bad, because a <param> actually gives location and 
possibly some added information about the resource repository. If the 
mime were known, the UA could start the context and pass this 
parameter to whatever and let it figure out what to do. Either the 
plugin should request network resources to retrieve the resource, or 
ask the UA to go get it and send it in.

Instead, the author has requested that the UA just go ahead and try to 
figure it out. Maybe, since there is nothing there of value to the UA, 
since the UA knows nothing about <param> elements without negotiaton 
with whatever represents the context, the UA must fallback. So, here 
<object> is just a wasted wrapper with literally no functionality.
Simple addition of @type should make this run, if the plugin can 
negotiate with the UA and obtain resources.

However, since I think <object> will not do anything, the UA must 
fallback. Here, the author/producer has used our venerable <embed> 
element. This is a slightly different, maybe more current version than 
used above. Here, @src passes some info to the server concerning 
associated content and some appearance preference.

allowscriptaccess="always" allowfullscreen="true"
width="445" height="364"></embed>

This is an act of desperation, because there is no standardized 
fallback for <embed>. It either has to work or, the UA has failed. 
Fortunately, there is plenty of stuff here. @type is given so that the 
UA can find a define a context and @src gives a resource. Notice the 
duplication of other name-value pairs to the containing <object>. That 
is they look the same here, as attributes of <embed> like <param>s 
because of pretty printing but are really a single string like 
currently outlawed for window open.

But this copy and paste suggestion is not that realistic in terms of 
what YouTube and others actually do to get a video playing on a site. 
I think here the script would generate the <object> and check that 
something was running before failing. But this is always partly by 
incantation and is a subject of much research, surveilance, and 

So, I just have to study the current <object> writeup some more and 
try some things that should work in both main <object> apis.

Thanks and Best Regards,
Received on Saturday, 12 December 2009 18:27:15 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:04 UTC