- From: Alan Stearns <stearns@adobe.com>
- Date: Wed, 10 Jul 2013 13:07:58 -0700
- To: "www-style@w3.org" <www-style@w3.org>
- CC: Erik Arvidsson <arv@chromium.org>, Boris Zbarsky <bzbarsky@MIT.EDU>
>On 7/9/13 1:12 PM, "Erik Arvidsson" <arv@chromium.org> wrote: > >>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. >> > >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); I have reverted the change. The NamedFlowCollection methods now return null if there is no NamedFlow with the provided index or name. Thanks, Alan
Received on Wednesday, 10 July 2013 20:08:30 UTC