W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2010

Re: DOM collections index out of bounds and JavaScript.

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Tue, 19 Oct 2010 09:46:33 -0700
Message-ID: <AANLkTinQDNmbjK7ftt2s3V6DMMOciRkgGksDMu=sAz2K@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: public-webapps@w3.org
On 10/18/10, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 10/18/10 9:34 PM, Garrett Smith wrote:
>> \.item\(\d+\s*\)\s*===\s*null lang:javascript
> Doesn't catch cases when the argument to item is not a numeric constant,
> most simply.
Or a reference like `i`, `foo.bar`, `f["d"]`, `f[ d ]`

\.item\((("|')?\s*(\d+("|')?)|([$_a-z]+)\s*)\)\s*===\s*null lang:javascript

That covers quoted numbers like `"2"` and `'3'` and lexical
environment references. It does not cover object environment
references such as `.item( foo.bar.baz[ 'bing' ] )`.

Regexes seem to be case-insensitive in google code search.


So I pick up 1 dude's unit test, "test.dom.css.js" that has a
one-liner that makes two assertions (which itself is stupid, but
that's beside the point). I see public code using item( n ) === null
being one file. Seems to be low impact, wouldn't you agree?

The impact to making `item( n )` return `undefined` instead of `null`
when `n` is not found seems pretty minimal.

The benefit is that square bracket property access and the `item`
method have the same result (behavior that was guaranteed in DOM 1)
and that property access does not need to use a proxy to conform to
the spec.

Received on Tuesday, 19 October 2010 16:47:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:13 UTC