W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > February 2011

[Bug 12091] New: HTMLdocument named-item getter and object fallback

From: <bugzilla@jessica.w3.org>
Date: Wed, 16 Feb 2011 02:31:22 +0000
To: public-html-bugzilla@w3.org
Message-ID: <bug-12091-2486@http.www.w3.org/Bugs/Public/>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12091

           Summary: HTMLdocument named-item getter and object fallback
           Product: HTML WG
           Version: unspecified
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: HTML5 spec (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: jrossi@microsoft.com
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-wg-issue-tracking@w3.org,
                    public-html@w3.org


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.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Wednesday, 16 February 2011 02:31:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 16 February 2011 02:31:41 GMT