[X3D-Public] HTML <object> element - Web3D.org Front Page

[Joe D Williams]

HI Braden,
Thanks for the response.

The basic idea is how object element supports a plugin, and how the 
plugin responds. For example, I thought it reasonable to consider 
param src as live and naturally thought I would just send a new url in 
there from the host dom, then the plugin would arrange to get the 
data, and the new one would light up. This works fine in Flux and 
maybe even elsewhere now that I haven't specifically tested or studied 
for a while, but basically, the params are supposed to be live. True, 
this is a great unspecified wasteland with all kinds of jargon like 
"DASHBOARD" and several data types mixed in there also, but, in the 
context of <object> they are live attributes and the host DOM or 
whatever can most likely expect to be able to read or set or silently 
ignore the attempt.
The <object> attributes, like @data are pretty much the same way. I am 
following the HTML 5 documentation(s) about <object> and explanations 
of:

http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-0.html#embedded-content-0

interface HTMLObjectElement : HTMLElement {
           attribute DOMString data; valid URL.
           attribute DOMString type; valid MIME type
           attribute DOMString name; valid browsing context name.
           attribute DOMString useMap; has associated image map
  readonly attribute HTMLFormElement form; form owner
           attribute DOMString width;
           attribute DOMString height;
  readonly attribute Document contentDocument;
  readonly attribute WindowProxy contentWindow;

and the associated steps to get the thing running.
I think we need sandbox on this thing.

http://www.hypermultimedia.com/x3d/Examples/index1.htm

works fine with with IE and Flux and probably Vivaty using

  document.getElementById('objx3d').src = file;

It still works in IE8 and an old Flux, but never reliably with other 
X3D browsers and other W3C browser hosts.

> Since "data" is effectively an initialization parameter, does 
> changing it post-initialization necessarily mean that it should 
> trigger restart of the plug-in?

That is what I would like to find out. mainly are those attributes and 
params just initialization data, or are those live?

I believe this is another complicated problem because the W3C browser 
designers working on HTML 5 are not producing consistent results at 
this time. Of course another issue might be raised that X3D browser 
designers may not all be doing the same things. It is expected that 
the DOM will allow access to the X3D execution context, just like from 
an internal script. So, right, if the X3D SAI is running as specified, 
an author really does not absolutely need 'live' <object> attributes 
or <param>s.

> Unlike the solution you're proposing, behavior of Browser.loadURL is 
> specified.

Yes.

> Where a particular need has been identified, I'd rather see 
> implementers encouraged to adopt existing specifications that 
> satisfy the requirement rather than have them (or the W3DC) come up 
> with new specs.

Thank you Braden, at a minimum, itr seems like the X3D players should 
have a list of attributes and <param> name-value pairs that everybody 
agrees upon.
Can you post or point to some code that shows the best usage of this?
I have an Ajax3D example however it is now caught with @loadUrlS 
pre-spec syntax.:)

  web3Dbrowser = document.objx3d.getBrowser();
  web3Dbrowser.loadUrl("X3Dme.x3d");

is that what you were expecting or closer to what you would like to 
see for DOM script?

Thanks Again and Best Regards,
Joe

.

----- Original Message ----- 
From: "Braden McDaniel" <braden at endoframe.com>
To: <x3d-public at web3d.org>
Sent: Thursday, July 02, 2009 10:15 PM
Subject: Re: [X3D-Public] Web3D.org Front Page


> [Sorry for the delayed response to this.  It was a busy week and
> "respond to long e-mail" kept getting put off.]
>
> On Wed, 2009-06-24 at 22:12 -0700, Joe D Williams wrote:
>> >> >>>  <object data="your.wrl" ... >
>> >> >>> <param name="src" value="your.wrl" >
>> >> >>> </object>
>> >> >>>
>> >> >>
>> >> >> The duplication of data="your.wrl"
>> >> >> and
>> >> >> name="your.wrl"
>> >> >> is just due to the fact that BS didn't recognize the src 
>> >> >> param.
>> >> >
>> >> > Presumably you mean "that BS didn't recognize the data
>> >> > attribute".
>> >>
>> >> No, @data is standard and everybody accepts that.
>>
>> Well it is not like the plugin has to accept or use @data. It is a
>> choice.
>
> Supporting Web standards is always a choice.
>
>> > "data" *is* standard; but what Lauren has described suggests that 
>> > it
>> > doesn't work with Contact.  I don't have Contact here, so I can't
>> > test it myself.  But if this is accurate, I can't say I find it
>> > *that* shocking.  If one were to bolt an NPAPI interface onto an
>> > ActiveX control, it is the sort of thing that could get 
>> > overlooked
>> > (because it is a way in which ActiveX containers differ in 
>> > behavior
>> > from NPAPI hosts).
>>
>> I believe it. I saw where IE9 will do something different with
>> ActiveX?
>
> I don't know anything about this.
>
>> >> The <param> src, or whatever the X3D browsers makers decide, is 
>> >> the
>> >> one missing last time I checked..In fact, the last time I 
>> >> looked,
>> >> Flux was the only one that accepted the url via a <param>.
>>
>> > Flux does so mostly because it is primarily an ActiveX control. 
>> > I
>> > think Contact and Cortona are in the same boat there.
>>
>> Well, I think in practice it is just tthe way that it works.
>> Regardless, the <object> has some attributes and some custom 
>> params.
>> In order to use the custom params the plugin must agree. The best 
>> way
>> is when the plugin gets running, then the appropriate attriburte
>> values and the custom parameters are passed to the plugin.
>>
>> > IIRC, the ActiveX container has some special awareness of the 
>> > "src"
>> > param and it gets some special handling.
>>
>> Maybe so. That would make it easier as in <embed> but it can be
>> anything, like movie or whatever.  But it is not automatic, maybe 
>> it
>> should be another name, and the plugin must set it up. The DOM will
>> follow and create the requested interfaces but won't bother 
>> checking
>> if the <param>s in the user code match up.
>
> Okay, now I remember. Let me tell you a story...
>
> In older versions of Internet Explorer (around version 4, IIRC), if 
> you
> loaded plug-in content in "full page" mode (e.g.,
> "http://example.com/your.wrl" in the Web browser's location bar) and 
> did
> "View source", you'd see the source to a brief HTML page with an
> "object" element in it.  What the browser was actually doing here 
> was
> generating an HTML page for it to render where the page had an 
> "object"
> element with its width and height both set to 100%, thus consuming 
> the
> entire page area.
>
> Now, Microsoft was an early adopter of the "object" element,
> implementing it before it was fully specified.  And it seems that at
> some point in "object"'s evolution, the attribute we now know as 
> "data"
> was called "src".  Or, at least, that's what the Microsoft 
> developers
> who wrote the code to generate this page thought, because the object
> element in the page refers to the content handled by the plug-in 
> with an
> *attribute* of "object" named "src".
>
> At least in those older versions of IE, this "src" attribute got 
> passed
> along to the ActiveX control looking no different from a "src" 
> *param*.
> (I would not be surprised if recent versions of IE do not permit 
> "src"
> as an attribute.) The upshot of this behavior is that if an ActiveX
> control developer wanted his control to be usable in full page mode, 
> the
> control *had* to support a "src" param--because that's what the 
> browser
> would send in that case.
>
> While I think modern versions of IE have managed to obscure this
> generated HTML page from view, I'm pretty sure it's still doing the 
> same
> thing behind the curtains.
>
> [snip]
>
>> >> http://www.ietf.org/internet-drafts/draft-abarth-mime-sniff-01.txt
>> >>
>> >> is in work now, but they are mostly skipping the hard parts.
>>
>> I meant that is fine but I think it is mising how to sniff multiple
>> media.
>
> I don't think I'm familiar with what you're referring to here.
>
>> > If one simply configures the Web server to send the correct media
>> > type, what's described in that draft is rendered moot.
>>
>> True, although the content type header should be damaged and that
>> procedure serves as a recovery. It is real life for W3C browsers. 
>> That
>> procedure really does not cover many types of embedded content, but
>> that is OK by me.
>
> Damaged? If your HTTP headers are getting garbled, you have bigger
> problems than can be solved with MIME type sniffing.
>
> That draft looks like an attempt to normalize what Web browsers have
> been doing for years rather than do anything new.  And that's fine. 
> But
> I don't see how it relates to this discussion.
>
>> > And note that, should this draft proceed to RFC status, it
>> > wouldpresumably need to update RFC2616 (HTTP/1.1).
>>
>> Well, if not updated, the difference is noted.
>
> "Update" is the RFC parlance.
>
>> The important point is that so far, the @data attribute is sort of
>> special.
>
> It's no different from the "src" attribute of "img".  In fact, 
> there's
> no reason for a browser to treat "<object data='some-png'></object>" 
> and
> "<img src='some-png'>" any differently.
>
>> >> True, if the media type is not supported the host won't even 
>> >> try.
>> >> There are other problems is the server doesn't provide a 
>> >> matching
>> >> content type.
>>
>> >> > I haven't tested it yet, but recent bugzilla.mozilla.org 
>> >> > activity
>> >> > leads me to suspect that Firefox 3.5 might finally be
>> >> > implementing this more-or-less to spec.
>>
>> >>
>> >> Yes, hard to tell what the spec is because they are sort of
>> >> honoring classid.
>> >>
>> >> http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-0.html#the-object-element
>> >>
>>
>> >> >> In particular, the browser may try to 'sniff' content type or
>> >> >> other aspects of the file, as well as download the complete 
>> >> >> file
>> >> >> before sending it to the plugin when data is used. Aside from
>> >> >> the "classid" attribute, *the server-provided media type is 
>> >> >> the
>> >> >> only specified means to indicate what plug-in should be
>> >> >> started*. That means that a correct implementation cannot 
>> >> >> start
>> >> >> the plug-in until *after* the resource specified in "data" 
>> >> >> has
>> >> >> started downloading.
>>
>> >>
>> >> Fortunately that is not true.
>> >
>> > It is true as far has HTML 4 is concerned.
>>
>> In practice it does not happen that way all the time. Essentiallly 
>> the
>> minimum  <object> to get a plugin going is:
>> <object type='modelx3d+xml'>
>> </object>
>>
>> The registered plugin should start up, report in, and accept any
>> attributes and <param>s.
>
> That does reflect the behavior I'm observing in Firefox 3.5.  I 
> don't
> think this has been specified anywhere prior to the HTML5 drafts.
>
> XHTML2 had some clever rules (for its "srctype" attribute) that were
> similar in effect, yet managed not to conflict with HTTP/1.1.  It 
> would
> be nice to see HTML5 adopt some of that language.
>
>> >> The problem is that (and I have to keep checking this) is that 
>> >> IE
>> >> and other browsers won't let you send in a new @data value via 
>> >> the
>> >> DOM.
>>
>> > How is this not a bug? Have you submitted bug reports? (Or are 
>> > you
>> > aware of existing ones?)
>>
>> I think it is a security thing. The host may want to sniff the 
>> content
>> returned for @data url. But like I said, I think the main browsers 
>> are
>> converging. .
>
> Security?  I don't think so.  That doesn't make any sense.
>
> More likely, no (or perhaps few) browsers have wanted to bother with
> implementing shutdown and restart of a plug-in in response to 
> changing
> an attribute via DOM.
>
> And from an implementation perspective, I don't think it's crystal 
> clear
> what should happen in that case.  Since "data" is effectively an
> initialization parameter, does changing it post-initialization
> necessarily mean that it should trigger restart of the plug-in? 
> Without
> a specification saying so, an implementer would be jumping to a
> conclusion (albeit not an unreasonable one) in doing that.
>
>> >> You have to rewrite the entire <object> tag to change the URL. 
>> >> This
>> >> is not true with a player that accepts a url via the <param> 
>> >> (Flux)
>> >> because you can always send in a new url via the src <param>
>>
>> > In changing the URI specified in the HTML, you'd need effectively 
>> > to
>> > restart the plug-in, anyway.
>>
>> Me not know but it sounds like that may not work that well.
>> I have some examples that script the src param that work fine,
>> However, scripttin @data is another matter. I hope to return to 
>> these
>> at some point and see what is actually happening now.
>
> Even a plug-in that supports a "src" param isn't obligated to do
> anything if it gets set to a new value post-initialization.  All of 
> this
> is completely unspecified.  You don't magically get this behavior 
> with
> support for an initialization-time "src" param.
>
>> > Practically speaking, the result isn't much different from just
>> > replacing the whole "object" element.  If you want to avoid that,
>> > use Browser.loadURL in the SAI.
>>
>> Right, and I would like to show some examples of that. AjaX3D did 
>> some
>> of everything I have talked about here. .
>> http://www.hypermultimedia.com/ajax3d/index.htm
>
> Unlike the solution you're proposing, behavior of Browser.loadURL is
> specified.  Where a particular need has been identified, I'd rather 
> see
> implementers encouraged to adopt existing specifications that 
> satisfy
> the requirement rather than have them (or the W3DC) come up with new
> specs.
>
>> >> >> On the other hand, if src param is used, then the url is sent 
>> >> >> to
>> >> >> the plug when it is ready and then the plugin asks for the
>> >> >> content when it is ready.
>>
>> >> > A correctly written NPAPI plug-in will be ready for an initial
>> >> > stream. Period.  There is absolutely nothing about VRML or X3D
>> >> > that would make implementing this especially problematic.
>>
>> It is just a way a normal user would expect to be able to prgrram 
>> the
>> thing. For heck's sake it should be easy to send in a new scene 
>> That
>> is what those html attributes and params are for - a direct 
>> connection
>> to the host DOM.
>
> AFAICT, how a plug-in handles changes to params post-initialization 
> is
> completely unspecified.
>
> -- 
> Braden McDaniel <braden at endoframe.com>
>
>
> _______________________________________________
> X3D-Public mailing list
> X3D-Public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org