Object element fallback applies to the DOM
When an object element has fallback content (typically, an embed element), Windows Internet Explorer 9 now parses this content and includes it in the Document Object Model (DOM), whereas previous versions of Windows Internet Explorer did not. This behavior change makes Internet Explorer 9's handling of such elements more standards-compliant and interoperable.
As a result, if an object element has the same name attribute as any of its fallback elements, then window["myName"] will now return a collection of all elements with the name "myName". Pages that assume Internet Explorer will return a single element (typically, the object element) as opposed to a collection can cause an exception to occur when accessing methods and properties on the returned value.
If you use the same name attribute for an object element as you do for the fallback content and attempt to retrieve a reference to the instantiated plug-in using window["myPlugin"], more than one element will be returned, where only the object element was returned in previous versions of Internet Explorer.
For example, consider the following script and markup:
Markup
<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" name="myPlugin"
codebase="http://fpdownload.macromedia.com/get/flashplayer/current/swflash.cab">
<param name="movie" value="myflash.swf" />
<embed src="myflash.swf" name="myPlugin" type="application/x-shockwave-flash"
pluginspage="http://www.adobe.com/go/getflashplayer"></embed>
</object>
JavaScript
plugin = window["myPlugin"]; //the OBJECT element in IE8, a collection of the OBJECT and
EMBED elements in IE9
plugin.style.display = "none"; //Causes an exception in IE9: "SCRIPT5007: Unable to set
value of the property ‘display’: object is null or undefined"
In Windows Internet Explorer 8, window["myPlugin"] would return just the object element (because Internet Explorer 8 did not include the fallback content in the DOM).
In Internet Explorer 9, the embed element is included in the DOM and thus window["myPlugin"] returns a collection of both the object and embed elements. This behavior is interoperable with other browsers and is standards compliant.
When expecting the instantiated plug-in, use document["myPlugin"] instead of window["myPlugin"]. document["myPlugin"] will not match fallback elements when the parent is instantiated.
plugin = document["myPlugin"]; //the instantiated plugin: OBJECT element in IE,
EMBED element in browsers which use the Netscape plugin model
Additional Details:
In pre-release versions of Internet Explorer 9, document["myPlugin"] returned the embed element and window["myPlugin"] returned an HTML Collection of both the object and the embed elements in the above example.
However, the following common coding pattern was observed on numerous sites:
if(document["myPlugin"]) {
plugin = document["myPlugin"]; //expected to be the object element in Internet Explorer and embed element in other browsers
}
To help site compatibility, Internet Explorer 9 has an improved behavior for document["myName"]. Provided the plug-in loads successfully, it will return the instantiated plug-in (in the above example, the object element). This effectively matches what Internet Explorer 8 returned while still allowing for standards-compliant parsing of the fallback content. This behavior allows for the above coding pattern to be interoperable in all major browsers.
window["myName"] remains unchanged from pre-release versions of Internet Explorer 9 and should only be used when expecting to match more than just instantiated elements. The following table describes how these APIs work in Internet Explorer 9.
| window["xyz"] returns | document["xyz"] returns |
|---|---|
|
An object element is said to be fallback-free if it has no object or embed descendants.