Next entry: Can X3D and SAI be to real-time 3D what wav files and VST are to music?
Previous entry: What's hot in 3D today?: Cartography, mobile, medical imaging and social networking
X3D Community Blog
August 25, 2006
AJAX3D - cross-browser html object how to
The AJAX tutorials on Ajax3d.com point the way to a great application area, but the 1990’s-browser-wars-style of html coding seriously impacts its use.
You gotta use the html/xhtml ‘object’ element if you want to be close to current html/xhtml standards. So far, it remains Not Possible to present a single object tag that provides sufficient guidance for both Firefox (Ff ) and IE. Along with related security issues, the author’s choice for showing active content using X3D hosted on a typical html/xhtml web browser is to use simple ecmascript to evaluate a basic browser capability check and generate a specific object element based on browser object implementation preferences and capabilities. We must demand w3c spec html/ecmascript from our html web browsers when we use them as a basis for our X3D aimed at the WWW.
Unfortunately, the html/xhtml object element is not yet fully standardized in the major html/xhtml web browsers. Ff cannot honor ‘classid’ and ‘codebase’, preferring to look at the ‘type’ (mime) attr and ‘pluginspage’ param. Those details along with differences in the way that a ‘data’ attribute, a ‘src’ parameter, and the actual file extension are applied produces slightly different functionality that may be one of the last artifacts of the early browser wars.
There are a couple of reasons for this, Probably one biggest one is
security. At this time, IEs security for the object is fairly well
developed. Security is required in the wild because the browser is loading and executing a control that may be designed to essentially replace the host browser and its host operating system. However, it is very simple to use the ‘classid’ and ‘codebase’ attrs to identify a specific control to be used along with a site for download if that control is not installed. The user is protected by layers of security ranging from not even showing the user any options for the control, to providing detailed interactions before allowing download and execution, to complete promptless freedom to download, install, and run the thing. Ff appears to be more limited by not allowing the author to identify a specific control (looks at ‘type’ instead of ‘classid’) and, as a result, there is no way to reliably recognize whether a specific control is installed and where to get it from a
download site (except possibly under some specific circumstances
where a control naming a specific mimetype has never been loaded).
More work needs to be done to move some existing AJAX3D examples into compliance with html standards and thus work in multiple html/xhtml web broswers, but here is a first step, being the first time i have been able to get X3D to run reliably OK in both Ff and IE. It is basically combos of a couple of Gecko tutorials. The idea is to produce a ‘custom’ object element that will load a specific X3D browser (Flux in this case) or if not installed, download it and run it.
html;
.js;
function LoadObjx3d() {
if (window.ActiveXObject)
{
// browser supports ActiveX/IE API and specifies FluxPlayer
document.write('
Comments
Beware of trying to do the right thing and use the OBJECT tag in some Web2.0 apps. In particular, Myspace strips out OBJECT tags (and all Javascript) from all user-contributed content, but allows the EMBED tag. Thus Myspace is training a whole generation of HTML coders to use the old construct, which is likely to remain supported by the major browsers and used by a large amount of content.
I have updated my favorite way of using the html object tag, still not including embed, in latest web3d blog.
I am still refusing to use the old html embed element. Sure it probably works to a limited extent in most web browsers, but is ultimately doomed for use in the wild - especially when the time finally comes that coders of web browsers agree how to handle the html/xhtml object element, attributes, and params.
One aspect is me wanting the ability to specify the X3D player, just as I wish to specify the host web browser. With html/xhtml hosts, it is just simple differences, some based on security and history, that make it just a bit harder for us to get the good stuff in there using othewise reliable modern html/xhtml host browsers.
X3D applies in many different host platforms, and each will have small differences. It may be that no single web3D X3D content delivery tool will ever dominate the www user base, or even be the overwhelmingly author-preferred X3D player out there in the wild. In that case, a web author shouldn’t worry much about which host/player combo represents their object, but probably still must learn some basic capabilities and preferences of the host, and of the host of the host, and,, as you point out, on up to the ultimate content host, then code accordingly.
Best Regards,
Joe
Post your comments
Note: All comments are moderated by the webmaster. Until then, the comment won't appear on the entry. Thanks for waiting.
