Making NodeList Constructible and Observable

Continuing the discussion from Element.ancestorQuerySelector:

[quote=“stuartpb, post:1, topic:1065”]

// this would use a (non-live) NodeList, but there doesn't appear to be an API for that
```[/quote]

Despite all the standard interfaces that use NodeList, there is still no constructor for polyfills to use for *creating* a NodeList. There is also no way to determine if a NodeList is live, or to observe the changes that may occur to a live NodeList. I propose addressing these issues with the following extensions:

## NodeList.live

A boolean property that states whether a NodeList is live (reflecting document changes), something which is [currently not accessible to end developers](http://stackoverflow.com/questions/28163033/when-is-nodelist-live-and-when-is-it-static), leaving it unclear whether or not users can use its values without having to re-run a given query callback.

## new NodeList(nodes[, populator])

Returns a new NodeList from a given array of nodes. If the `populator` callback is specified, the NodeList is marked as `live`, and the callback receives two functions, `addNode` and `removeNode`. When the NodeList needs to be adjusted, these functions should be called, with a Node, NodeList (interpreted statically), or array of nodes to add or remove (respectively).

## NodeList.observe(callback[, acceptList]), NodeList.unobserve(callback)

Works similarly to `Object.observe` and MutationObserver on a live NodeList. Callbacks receive an object, similar to MutationRecord, with NodeLists at `addedNodes` and/or `removedNodes` describing changes to the NodeList.

If making NodeList inherit from Array is on the table (and, although it currently doesn't, I don't necessarily see any reason why it *couldn't*), this should maybe be reconsidered in favor of a general `Array.prototype.observe` - or, if Array chooses to go the same route as `Object.observe` where the observation function is a property of the *constructor* rather than the *prototype*, there would be no problem in the interim, since the `observe` property of Array subclasses wouldn't be affected.

Also, in making live node lists a bit more usable, it would be nice to have a querySelectorLive function that works identically to querySelectorAll but returns a live NodeList. (Same does for all other functions that currently return non-live NodeLists.)

Is this basically http://nodelist.org/ ? John Resig set that up like, I don’t know before github IIRC - it’s been at least 5 years he’s tried to make that happen…

Nope. While I wasn’t aware of that proposal already, there is almost no overlap between the things proposed in this proposal and the things proposed in Resig’s, and on the few points where they do overlap, this is more flexible:

• Resig’s proposal still doesn’t have a way to determine whether a NodeList is live or not.
• Resig’s proposal has no mechanism for creating live NodeLists.
• Resig’s proposal, while having methods for adding listeners to node lists, has no methods for removing those listeners.

@stuartpb I’ve mentioned in other posts, that NodeList will most likely be considered legacy, and the new Elements will be used. I’m kind of doubting that NodeList will be updated.

Elements Collection Spec

You also mentioned having methods for live NodeList and creating live NodeList

I personally think that was a mistake and they should of never been live, they cause problems.

If I remember later on what were the problems that they caused for me when I was developing NodeList.js I’ll come back to this and comment it.

@stuartpb Still, it seems to me like he would be a good person to have in this conversation if you’re really interested in persuing… Especially since it seems like his proposal was actually lower bar.

Who John Resig? @briankardell

@Edwin_Reynoso yes, John