- From: Erik Arvidsson <arv@chromium.org>
- Date: Tue, 9 Jul 2013 16:12:09 -0400
- To: Alan Stearns <stearns@adobe.com>
- Cc: "www-style@w3.org" <www-style@w3.org>
All the item and namedItem methods returns null in the DOM. It is the
JS [[Get]] that returns undefined and not null. The following asserts
hold true at all times:
assert(collection.item(42) === null);
assert(collection.namedItem('foobar') === null);
assert(collection[42] === undefined);
assert(collection['foobar'] === undefined);
On Wed, Aug 29, 2012 at 4:34 PM, Alan Stearns <stearns@adobe.com> wrote:
> On 8/29/12 9:53 AM, "Boris Zbarsky" <bzbarsky@MIT.EDU> wrote:
>
>>On 8/29/12 12:46 PM, Mihai Balan wrote:
>>> Currently the spec says that should a script try to retrieve an
>>> inexistent object from a NamedFlowCollection, either by using an
>>> out-of-range index or an invalid name, it should return **null**.
>>>
>>> I think it would be better to return **undefined** instead, for a couple
>>> of reasons:
>>>
>>> ·Currently all JavaScript and HTMLCollection-s return **undefined** for
>>> invalid keys (e.g. Array, document.forms, document.querySelectorAll() )
>>>
>>> ·Also, in general, null doesn¹t mean that there¹s nothing there, but
>>> actually that something might be there, but it¹s not a definite object
>>>(yet)
>>>
>>> Anyone has any thoughts on this?
>>
>>Won't you get the "undefined" behavior for free if you use sane
>>definitions of the supported names and indices in your prose?
>>
>>I agree that the undefined behavior is better, btw: it also makes "in"
>>work correctly and such.
>
> I agree as well. I've made the change.
>
> Thanks,
>
> Alan
>
>
--
erik
Received on Tuesday, 9 July 2013 20:12:56 UTC