Re: [selectors-api] Summary of Feature Requests for v2

>
>  So the question is, at which point in the chain do you want to address
> this issue?  The options are:
>
> A) Have specific selectors API feauture that allowed executing a
>   selector query on a whole collection of elements that returns a
>   single, sorted collection of unique elements.
>
> B) A more generic API for being able to easily merge and sort
>   NodeLists/Arrays of elements.
>
> Option A saves the step of having to run the queries on each individual
> element manually and just returns a merged and sorted collection of unique
> elements.  But it's limited to running selector queries, rather than any
> other getElementsBy*() method to obtain the results.
>
> Option B is more generic in that it could potentially merge and sort any
> set of NodeLists, and those NodeLists could be obtained by any method, but
> would still require running the queries on each element individually to
> obtain the the lists that then need to be merged.
>
> Both options present an issue with sorting, since they could result in
> lists that contain both connected and disconnected elements, and the sort
> order for connected elements in relation to disconnected elements would need
> to be defined.
>
> Option B seems potentially harder to define and possibly implement,
> especially if you want to be able to sort merge NodeList objects with Array
> objects.  Since Arrays aren't limited to just containing DOM Nodes, the
> issue of what to do with other types objects and how to sort them along with
> the Nodes is complicated.


B is a subset of A. You need B in order to implement A. Ideally we could
have both options (A for the obvious cases where you already have a NodeList
and which to do another query against the results, which would be faster
than manually going through the results and doing B).

Whereas B is needed in its own right (as I outlined before).


> It would be great to have a separate, standalone, function that handles
>> these merge/sort/unique operations for collections of DOM elements
>> (especially if they're disconnected from the document!).
>>
>
> The proposal from my previous mail falls into Option A.  Would it address
> this issue adequately?  Specifically, defining document.createSelector() and
> a Selector interface that allows running a query like this:
>
> var elements = [...] // Some Array (or NodeList) of Elements
> var selector = document.createSelector("em, strong");
> var list = selector.querySelectorAll(elements);
>
> This is equivalent to iterating over the elements array, running
> elements[i].querySelectorAll("em, strong") on each, and then merging/sorting
> all of the results into a single collection.


Not a huge fan of that - it seems really backwards. Another alternative
would be to implement the merge/sort/unique method and have it return a
NodeList (which would, then, have qSA).

For example:
    document.createNodeList([ ... some elements ... ]).querySelectorAll("em,
strong");

createNodeList would create a NodeList holding the DOM nodes in document
order (with duplicates removed). Since it's a proper NodeList we could then
use qSA to find the elements that we want.

If this is how it's implemented it actually becomes really useful to have
the NodeList-based element filtering.

    document.createNodeList([ ... some elements ... ]).filterSelector("em,
strong")

(Since this would be much faster than using Array.filter or some other
method.)


>  If there was a merge/sort/unique method it would drop the need for having
>> a
>> NodeList/Array.querySelectorAll.
>>
>
> Whether we should go for the extra complexity required for this really
> depends on the use case you're trying to address.  Do you just need to merge
> NodeLists that are all obtained via querySelector methods, or do you need to
> merge any random NodeLists or Arrays that could be obtained via
> querySelector*() or getElementsBy*(), or wherever else.


The latter, absolutely. These results could be coming from anywhere - and
could even be coming from non-query methods (like the aforementioned
.parents() method in jQuery which does its own ancestor traversal).

--John