W3C home > Mailing lists > Public > public-webapi@w3.org > January 2007

Re: Selectors API: Multiple elements with the same ID

From: Boris Zbarsky <bzbarsky@mit.edu>
Date: Sun, 28 Jan 2007 18:35:30 -0600
Message-ID: <45BD4152.40400@mit.edu>
To: Maciej Stachowiak <mjs@apple.com>
CC: "public-webapi@w3.org" <public-webapi@w3.org>

Maciej Stachowiak wrote:
>> For what it's worth, that's not what Gecko does, and I personally 
>> would rather not try to enforce that -- it's somewhat expensive to do 
>> so in the face of DOM mutations.
> I tried to make some test cases to figure out the difference (in current 
> WebKit sources we changed to return the first match in document order to 
> match IE, and, we thought, Firefox)

I can describe the difference in detail if you'd like, but to a first 
approximation there's a id-to-element hashtable, but it's lazily populated and 
doesn't guarantee ordering.  So in the following sequence of events:

1)  Insert node A with id "test" into the document.
2)  getElementById("test")
3)  Insert node B with id "test" into the document before node A.
4)  getElementById("test")

step 4 will return node A, not node B.

In all static cases (document with multiple ids loaded, then getElementById 
called), you'll get the first node with that id.

> <div id="foo">
> </div>
> <script>
> alert(document.getElementById("foo"));
> </script>
> This is with Firefox on Mac OS X. What am I doing wrong here?

See <https://bugzilla.mozilla.org/show_bug.cgi?id=178258>.  If you put a <body> 
around the whole thing you'll get the right answer.  As it is, the script is 
executing before the <div> has been parsed in your testcase...

Received on Monday, 29 January 2007 00:35:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:22 UTC