Open Standards for Real-Time 3D Communication

If it won't work cross these two browsers using the simplist way, let's try the next simplist way by leveraging Tony's Ajax3D.org tutorials to get this done. I think we can predict that if we keep it simple Ajax, we can get it to work in both IE and Ff.

Tony Parisi authored the original Ajax3D then published them on ajax3d.org as a great community service. While showing reliable DOM and extension httprequest performance in major html/xhtml host browsers, the set is a great and easily accessible proof that the X3D SAI is up to the job of living in DOM web pages. I think every good X3Der must consider capabiites and preferences of the host. For html/xhtml web browser hosts, so far as these examples are concerned, the good news is that when you scratch just below the surface, everything we need is fine.

Again, it would be great not to have to concern ourselves with cross-browser HTML and DOM implementations and Extensions. The good news is that when you scratch just below the surface, everything is fine. Basic AJAX appears consistent in IE and Ff, hopefully eliminating the need for a lot of feature testing leading to code forking. However, right at the first step - including X3D as an active element in the web page in more than one html/xhtml web browser - we find a problem.

I’m making a simple DOM event replace an X3D scene work for both IE and Ff at:
http://hypermultimedia.com/x3d/Examples
X3D Examples From the Standard
Specifies Flux Player.

These are some simple examples, very close to what is printed in the ISO X3D encodings standard. A click on a numbered box should cause the X3D area to update to a new example. I’m sure this will work anywhere someday, but the problem today is it does not work in Ff. To figure this out, along with a work-around, let’s examine what is happening in the different host browsers.

Here is how the X3D is embedded in the host html document.

function x3dContent(scene) {
if (window.ActiveXObject)
{
// browser supports ActiveX/IE API and specifies Flux Player
 document.write('
');

}
 else

 {

 // browser supports Firefox/Netscape Plugin API.

  document.write('
');

 }

 }

Which seems to work better than any other so far, given the differences between the oh-so-very-delicate handling of the html object element. Of course it does get easier if you don’t try to specify the player, Flux in this case, but not much.

Ajax3D needs host scripting and active element security approvals set by the user, so you may as well start by scripting the html container element for the X3D content. Problems in this feature test may include the instance where the host window is an ActiveX object, but not really IE. Since X3D covers the entire range of platforms, we are always looking for better host identity tests; this one seems to work for now with latest IE and and Ff using this simple if-else evaluation.

Now for the fun part, using simple DOM to update content in the X3D area of the window when certain html elements are clicked. As you can see, the html DOM is very responsive. Position the pointer over one of the numbered squares and some text changes to show the name of the scene to be selected for display. Clicking the button causes the new scene to replace the current one and the title updates.

Here is how that is done.

IE: document.getElementById(‘x3dscene’).src= file;

Ff: document.getElementById(‘x3dscene’).data = file;

Ooopps! it doesn’t work in Ff? For anyone trying to get a simple thing done simply and working cross-browser, make no mistake, this problem with the html/xhtml object tag is mainly due to some unsettled interface security issues. Either someone will tell me how to figure out how to do this or else it will start working after some update. We are already compensating for host browser differences in usage of a src param and a data attribute, and now we find that the obvious way to get this done via simplist DOM does not work.

The IE object works like I would expect (or hope for). The host sets up the plug-in and hopefully treats the meta params as real interfaces, like other object attributes. Ff apparently does not allow dynamic update of this attribute of the object element. I have heard on the x3d list that this is known to Ff coders. At this time, it does not matter whether the Ff object is created by script generated code or straight html it does not work as actually defined in the w3c html recommendation.

Well, if it won’t work cross these two browsers using the simplist way, let’s try the next simplist way by leveraging Tony’s Ajax3D.org tutorials to get this done. I think we can predict that if we keep it simple Ajax, we can get it to work in both IE and Ff.

Thanks and Best Regards,
Joe