I do think you're unnecessarily limiting the use of the Selectors API in the current draft by only allowing selector matching on the subtree of the document node though. The same way you might want to use getElementsByTagName not on the document node but on some deeper element node, you might want to do selectors matching on the subtree of a deeper element node instead of on the entire tree.

Well, does it matter if StaticNodeList in the ECMAScript bindings is defined to have the Array.prototype as it's prototype object instead of the Object.prototype? That doesn't change the interface itself, it's just a question of ECMAScript bindings. The reason one would want this is of course that one might want to use array methods such as Array.prototype.sort, Array.prototype.map or Array.prototype.filter on the returns from the selector match without having to jump through hoops to do so. At least the ECMAScript defined Array.prototype methods are written to be generic and work on any array-like object, I hope the Mozilla JavaScript 1.6 Array extras are written that way too. And StaticNodeList looks to me to be pretty array-like.