[whatwg] Adding ECMAScript 5 array extras to HTMLCollection
dhtmlkitchen at gmail.com
Mon Apr 26 10:33:32 PDT 2010
On Mon, Apr 26, 2010 at 9:49 AM, Erik Arvidsson <arv at chromium.org> wrote:
> On Sun, Apr 25, 2010 at 01:07, David Bruant <bruant at enseirb-matmeca.fr> wrote:
>> Le 25/04/2010 00:39, J Z a écrit :
>>> I have thought a lot about weirdnesses that people could think about like
>>> trying to assign a value to the HTMLCollection (divs = myOtherDiv), but
>>> once again, it wouldn't be more allowed than it currently is (I have no idea
>>> of what happens today, but if an error is thrown in a for-loop, it should
>>> throw an error as well in a call within a forEach).
>> How would destructive methods like `push` or `sort` behave? Would
>> `document.body.childNodes.push(document.createTextNode('foo'))` append text
>> node to a body element? Or would it be a noop?
>> That is actually a very good point.
>> It think that the behavior should be exactly the same as "an equivalent
>> without array methods". (this point of my proposal would need to be made
>> completly explicit for each method)
> One way to solve this could be to split Array into two interfaces. One
> to be used with immutable array like objects and one to use to mutate
> objects. Then we could apply the immutable array like interface to
> NodeList and its related interfaces. The benefit of doing that is that
> NodeList.prototype.push would be undefined instead of failing when
Yes, that was also discussed on es-discuss list.
The complaints that have been mentioned on this thread are also detailed:
- and the reply by Allen:
| I'm probably repeating myself here, but an new interface is not
| necessary to make this requirement explicit. If you want (and
| can get agreement) for these objects to fully implement
| ECMAScript native object semantics then that is all you have to
Nobody argued with that post, which concluded the thread.
More information about the whatwg