W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2011

Re: indexed properties on NodeLists and HTMLCollections

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 22 Jun 2011 15:56:16 -0400
Message-ID: <4E0248E0.6020707@mit.edu>
To: David Flanagan <dflanagan@mozilla.com>, Jonas Sicking <jonas@sicking.cc>, Allen Wirfs-Brock <allen@wirfs-brock.com>, public-script-coord@w3.org
On 6/22/11 12:17 AM, Cameron McCormack wrote:
 > It looks like Firefox, Chrome and Safari treat the interface as
 > [OverrideBuiltins]

The Gecko behavior here is just really weird.

What happens when a name lookup is performed on an HTMLCollection is 
that if we don't have an own property for that name already we look up 
the proto chain.  If we find something there, we do NOT define an own 
property even if something in the collection has that id/name.

If we _do_ have an own property of that name, there is no lookup to do, 
of course, but [[GetOwnProperty]] will return the named item from the 
collection if there is one.

Note that removing the expando property sets that set .item and 
.toString to 1 in your testcase changes the Gecko behavior for the gets 
after the id change....

All of this is largely an artifact of the exact way name lookups work in 
Gecko and the fact that this was implemented in the simplest way 
possible within that setup.

But the upshot is that Gecko doesn't override _prototype_ properties 
with stuff from the collection but does override _own_ properties.

I believe not overriding prototype properties is required.

I'm not sure what behavior I want for own properties, nor whether it 
much matters.

>> My reading of [[DefineOwnProperty]] for named properties was that we
>> ought to be able to define an expando property x even when a named
>> property x also exists, and that the new expando will hide the named
>> property.
>
> Only if [ReplaceableNamedProperties] is used on the interface.
> Otherwise (assuming there is no name setter), it will fall through to
> invoking the default [[DefineOwnProperty]] method and … oh, I see, this
> will succeed in reconfiguring the property.

I'm not quite sure how to reconcile that with the [[GetOwnProperty]] 
behavior mentioned above.

>> 1) A pre-existing named property will prevent the definition of an
>> expando property with the same name, so there is no shadowing issue.
>>
>> 2) A pre-existing expando will shadow a named property that comes
>> into existance after the expando. [This is different than the
>> current behavior of FF and Chrome, at least.]
>>
>> Is this the intent of the spec?
>
> Yes, that is the intent.

This will likely make definition of expandos somewhat slow, but I 
suppose that's ok; that's a rare case.

-Boris
Received on Wednesday, 22 June 2011 19:56:59 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:03 UTC