W3C home > Mailing lists > Public > public-html@w3.org > April 2009

Re: document[id] and document.id to <element id="id"> matching

From: Michael A. Puls II <shadow2531@gmail.com>
Date: Mon, 06 Apr 2009 18:17:10 -0400
To: "Anne van Kesteren" <annevk@opera.com>, public-html@w3.org
Message-ID: <op.urzj6wqt1ejg13@sandra-svwliu01>
On Mon, 06 Apr 2009 17:33:58 -0400, Anne van Kesteren <annevk@opera.com> wrote:

> On Mon, 06 Apr 2009 23:19:28 +0200, Michael A. Puls II  
> <shadow2531@gmail.com> wrote:
>> 1. I don't really understand the part about there always being one  
>> element by definition and 'lists' and collections in this case. I don't  
>> really understand the first iframe case either.
>
> <iframe> is special cased because if there are multiple elements  
> matching the document[name] and one of them is <iframe> you would get  
> the <iframe> element itself back as part of the list and not a reference  
> to the global object of that element.

So:

document.a returns an HTMLCollection:
<body>
<img name="a">
<iframe name="a">
</body>

where a[1] would be the IFRAME element.

document.a returns the iframe as a window object:
<body>
<iframe name="a">
<img name="a">
</body>

, instead of an HTMLCollection because the iframe (as a window object) can't exist in an HTMLCollection, so the iframe as the window object is favored.

Is that what you mean?

> That there is always one element follows from the list of values that  
> make up the "names of the supported named properties". The algorithm  
> would not be called at all otherwise, because there would not be a  
> property with that name.

I see. I was thinking from a caller perspective and thought it was saying that document.<nomatch> would return at least one element instead of undefined.

-- 
Michael
Received on Monday, 6 April 2009 22:17:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:33 GMT