869376 - Nodelist should be ArrayClass

Status: RESOLVED WONTFIX

(Core :: DOM: Core & HTML, enhancement)

Description

[mike.maccana]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.65 Safari/537.31

Steps to reproduce:

I want to iterate over a Nodelist


Actual results:

I had to run:

    NodeList.prototype.forEach = Array.prototype.forEach

Or equivalent code. This (or something very similar) has become one of the first thing any programmer who wants to use Vanilla JS does. 



Expected results:

It would be reasonable for browsers to provide NodeList.prototype.forEach for us. This would:

 - eliminate boilerplate code required to do simple things with .querySelectorAll() or .children() results
 - be consistent with other iterables most notable Arrays.

Comment 1

[Masatoshi Kimura [:emk]]

Please file a spec bug or discuss it on public-webapps.
https://www.w3.org/Bugs/Public/enter_bug.cgi?product=WebAppsWG&component=DOM
http://lists.w3.org/Archives/Public/public-webapps/
It doesn't make much sense to implement it only on Firefox.

Comment 2

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

The right mailing list for DOM is www-dom, not public-webapps, and the spec already has [ArrayClass] on NodeList, which would add forEach in particular.

WebKit tried to implement it but hit issues on Google properties; arv is planning to try it again in Blink. If that succeeds, we'll probably implement it too.

Comment 3

[Boris Zbarsky [:bzbarsky]]

All [ArrayClass] means is that you chain up to Array.prototype instead of Object.prototype, right?

That's pretty trivial to implement if people want to experiment with it.  I'll put up a patch, just for posterity.

That said, is there a reason HTMLCollection is not [ArrayClass]?  Worries about issues with named props?  It does meant that .children will NOT have the arrayclass behavior.

Comment 4

[Anne (:annevk)]

Currently only childNodes and mutation records use NodeList.

The concern with HTMLCollection is indeed named props. Overall concern is compatibility. If we're happy to experiment...

(One longer term plan is to make sure that the new .find and .findAll return objects that do have this and are also more extensible than HTMLCollection and NodeList.)

Comment 5

[Boris Zbarsky [:bzbarsky]]

I should note that [ArrayClass] leads to some pretty bizarre behavior, per specs.  For example, this:

  var x = document.querySelectorAll("*");
  var y = x.concat();

gives us a "y" that's an Array of length 1, and y[0] === x.

Comment 6

[Boris Zbarsky [:bzbarsky]]

> Currently only childNodes and mutation records use NodeList.

And querySelector*, fwiw.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Attachment: Implement support for [ArrayClass]. r=??????. This patch still needs tests

Comment 8

[mike.maccana]

(In reply to Boris Zbarsky (:bz) from comment #7)
> Created attachment 749328 [details] [diff] [review]
> Implement support for [ArrayClass].  r=??????.  This patch still needs tests

Thanks very much for this Boris and co.

As Boris and I mentioned earlier, NodeLists are used in querySelector() / querySelectorAll() which are typically the first steps of library-free selection and DOM manipulation. Not having to patch in NodeList.prototype.forEach() would be massively helpful to any web developer interested in 'Vanilla JS'.

Comment 9

[Boris Zbarsky [:bzbarsky]]

I spun off basic ArrayClass support into bug 892609.

Comment 10

[Boris Zbarsky [:bzbarsky]]

This needs @@isConcatSpreadable support to have a hope of being web-compatible.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Wontfix in favor of bug 1290636; we have not managed to convince anyone else to do this, so...