This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Currently the spec says that document[name] should match elements which are: "-applet, embed, form, iframe, img, or fallback-free object elements that have a name content attribute whose value is name, or -applet or fallback-free object elements that have an id content attribute whose value is name, or -img elements that have an id content attribute whose value is name, and that have a name content attribute present also. An object element is said to be fallback-free if it has no object or embed descendants." IE9 Beta implemented this behavior and subsequently witnessed a number of compat issues with top sites such as live365.com, napster.com,wunderground.com,slacker.com, and more. In IE8, fallback content for OBJECT elements was not included in the DOM if the object was instantiated. Thus, document[name] would match the OBJECT element which was instantiated. In browsers which used the Netscape plugin model, the fallback content (typically, an EMBED element) was included in the DOM and, by the rules mentioned above, document[name] returned the instantiated fallback content. Because IE9 beta then correctly included fallback content in the DOM and obeyed the rules above, it too returned the EMBED element for the above mentioned case. However, sites were expecting document[name] to actually return the instantiated plugin (conveniently, that's what it used to do: in IE8 you got the object element, and in other browsers you got the embed). Because this API is used in the wild in this manner, the spec should not give preference to fallback content ("embed elements or *fallback-free* object elements"). Specifying it as follows resolves the compatability issues and allows Netscape plugin based browsers to continue to behave as they do today: document["foo"] matches: embed or object elements which are showing and have a name or id of foo, or embed or fallback-free object elements, which have no object ancestor which is showing, and have a name or id of foo, or object elements which are either showing or have no ancestor which is showing, and have an id of foo, or applet, form, iframe or img elements that have a name foo, or applet elements that have an id foo, or img elements that have an id foo, and that have a name content attribute present also. In our testing this has afforded sites interoperability with either plugin model. This is the behavior which is implemented in IE9 Release Candidate.
I'll examine this more carefully but it seems reasonable in principle.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Partially Accepted Change Description: see diff given below Rationale: The exact criteria above don't quite work, but I've tried to come up with criteria that do work.
Checked in as WHATWG revision r6115. Check-in comment: Change how document[name] works to be compatible with both IE (which typically are targetted with <object>) and other UAs (which typically are targetted with <embed>). http://html5.org/tools/web-apps-tracker?from=6114&to=6115
mass-move component to LC1