Why does document.querySelectorAll return a StaticNodeList rather than a real Array?

Question

It bugs me that I can't just do document.querySelectorAll(...).map(...) even in Firefox 3.6, and I still can't find an answer, so I thought I'd cross-post on SO the question from this blog:

http://blowery.org/2008/08/29/yay-for-queryselectorall-boo-for-staticnodelist/

Does anyone know of a technical reason why you don't get an Array? Or why a StaticNodeList doesn't inherit from an Array in such a way that you could use map, concat, etc?

(BTW if it's just one function you want, you can do something like NodeList.prototype.map = Array.prototype.map;...but again, why is this functionality (intentionally?) blocked in the first place?)

Answer 1

I don't know why it returns a node list instead of an array, maybe because like getElementsByTagName it will update the result when you update the DOM. Anyway a very simple method to transform that result in a simple array is:

Array.prototype.slice.call(document.querySelectorAll(...));

and then you can do:

Array.prototype.slice.call(document.querySelectorAll(...)).map(...);

Answer 2

I believe it to be a philosophical decision of the W3C. The design of the W3C DOM [spec] is quite orthogonal to the design of JavaScript, as the DOM is meant to be platform and language neutral.

Decisions like "getElementsByFoo() returns an ordered NodeList" or "querySelectorAll() returns a StaticNodeList" are very much intentional, so that implementations don't have to worry about aligning their returned data structure based on language-dependent implementations (like .map being available on Arrays in JavaScript and Ruby, but not on Lists in C#).

The W3C aim low: they'll say a NodeList should contain a readonly .length property of type unsigned long because they believe every implementation can at least support that, but they won't say explicitly that the [] index operator should be overloaded to support getting positional elements, because they don't want to stymie some poor little language that comes along that wants to implement getElementsByFoo() but cannot support operator overloading. It's a prevalent philosophy present throughout much of the spec.

John Resig has voiced a similar option as yours, to which he adds:

My argument isn't so much that NodeIterator isn't very DOM-like it's that it isn't very JavaScript-like. It doesn't take advantage of the features present in the JavaScript language and use them to the best of its ability...

I do somewhat empathize. If the DOM was written specifically with JavaScript features in mind it would be a lot less awkward and more intuitive to use. At the same time I do understand the W3C's design decisions.

Answer 3

Just to add to what Crescent said,

if it's just one function you want, you can do something like NodeList.prototype.map = Array.prototype.map

Don't do this! It's not at all guaranteed to work.

No JavaScript or DOM/BOM standard specifies that the NodeList constructor-function even exists as a global/window property, or that the NodeList returned by querySelectorAll will inherit from it, or that its prototype is writable, or that the function Array.prototype.map will actually work on a NodeList.

A NodeList is allowed to be a ‘host object’ (and is one, in IE and some older browsers). The Array methods are defined as being allowed to operate on any JavaScript ‘native object’ that exposes numeric and length properties, but they're not required to work on host objects (and in IE, they don't).

It's annoying that you don't get all the array methods on DOM lists (all of them, not just StaticNodeList), but there's no reliable way round it. You'll have to convert every DOM list you get back to an Array manually:

Array.fromList= function(list) {
    var array= new Array(list.length);
    for (var i= 0, n= list.length; i<n; i++)
        array[i]= list[i];
    return array;
};

Array.fromList(element.childNodes).forEach(function() {
    ...
});