Re: HTMLCollection item() vs. namedItem() with [] syntax (detailed review of the DOM)

Cameron,

Can you provide any other need for the "IndexGetter"?
http://www.w3.org/TR/DOM-Bindings/#IndexGetter

It can be demonstrated that all of: NamedNodeMap, NodeList, and
HTMLCollection are implemented in the top 4 browsers with extra
numeric properties being added.

http://html5.googlecode.com/svn/trunk/incoming/garrett-smith/noIndexGetter.html

StyleSheetList, and CSSRuleList also have this behavior. I can't find
an object that implements indexed properties the way you have
documented them.

Although the HTML DOM spec defines a 'length' property for
NamedNodeMap, yet provides no way to access items by index. This seems
to be a strange design decision, though not the most harmful. Ideally
such decisions would be tested out before writing a lengthy document.
Firefox, Opera, Safari, and IE all allow access by ordinal index, via
property access, but not by the way you have described in your
document.

It seems that a reasonable algorithm NamedNodeMap [[Get]] might be:-

[[Get]](P)
1. if the NamedNodeMap has a property named P, return P
2. Call getNamedItem(p), if result is not null, return result
3. Return undefined

However, I cannot find an implementation or a need for what you have
documented. Can you justify it? Creating an unnecessary feature would
be a bad idea.

Sincerely,

Garrett

On Fri, Jul 25, 2008 at 9:32 PM, Garrett Smith <dhtmlkitchen@gmail.com> wrote:
> On Fri, Jul 25, 2008 at 8:15 PM, Cameron McCormack <cam@mcc.id.au> wrote:
>>
>> Hi Garrett.
>>
>> Garrett Smith:
>
>
>>> Any assumption that there is a modified [[Get]] for the collection
>>> would be wrong.
>>
>> I see.  If we want to specify that (that they are real properties that
>> exist on the object),
>
> Whatever you do, definitely do not document something as being other
> than what it actually is in implementations.
>
>> then I think it will be hard for Web IDL to
>> provide some syntactic description of this behaviour.
>
> Why are you trying to document EcmaScript [[Get]] in IDL? EcmaScript's
> [[Get]] and property access operators are language specific to
> EcmaScript, are clearly defined, and don't have the same meaning in
> other bindings.
>
> [[Get]] resolves a property on an object (up through the prototype
> chain) and returns its value or undefined.
>
> Identifier[ <property-name-string> ]
>
> document.body.childNodes["0"]
> document.body.childNodes["item"]
>
> document.body.childNodes.0 - is not valid syntax, so the other
> property access operators must be used.
>
> http://google.com/search?hl=en&q=javascript+property+access+operator
>
>> So it would then
>> be up to HTML to state that properties get created and removed when
>> elements are added and removed from the document.
>>
>
> That seems to be a mistake. It can be clearly demonstrated that at
> least 3 implementations, Safari3, Firefox4, and Opera9 implement
> property access of a collection in an XMLDocument.
>
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
>        "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
> <html xmlns="http://www.w3.org/1999/xhtml" lang="en">
> <head>
>        <title>XML Document</title>
> </head>
> <body>
> <script type="text/javascript">
> alert(document.childNodes[0].nodeName);
> </script>
> </body>
> </html>
>
> Would it be bad to specify it in the EcmaScript bindings as an
> optional feature, and just make a small note about it? e.g.
> "Implementations MAY implement create numeric properties of the
> collection which may be then accessed via property access operator, in
> lieu of item()"
>
> ?
>
> This would leave explaining [[Get]] to the relevant language
> specification (Ecma-262)
>
> It would probably be OK to omit the details of where on the prototype
> chain these properties exists or what attributes they have (if the
> items are ReadOnly, DontDelete, et c).
>
> Garrett
>
>> --
>> Cameron McCormack
>

Received on Thursday, 31 July 2008 21:19:36 UTC