John Resig wrote:
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.
B is a subset of A. You need B in order to implement A.
Not quite. It depends what's being done and which steps need to be
performed and how. AIUI, there are 3 major steps involved here.
1. Obtain a collection of Elements. This could be in one or more
Arrays and/or NodeLists, depending on th.
2. Iteratively execute a selector query on all elements in the
collection, saving the results from each.
3. Merge and sort all elements into a single NodeList, removing
duplicates.
In order to understand which of those steps need to be optimised by the
browser with new APIs, it would help if you could explain some typical
tasks, or use cases, that would need to perform any or all of those steps.
In particular, what type of task would lead to there being more than one
Array and/or NodeList to be used as input to step 2?
What type of task would require executing the same selector query over a
whole collection of elements?
And what task would require the results of those to be merged into a
single list?
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.
Could you elaborate?
Another alternative would be to implement the merge/sort/unique
method and have it return a NodeList (which would, then, have qSA).
The collection of elements (step 1, above) input into the qSA step (step
2) wouldn't need to be a sorted list. Technically, it doesn't even
necessarily have to be a merged list if the API allows multiple arrays
and/or nodelists to be provided. It will have no effect on the result.
The important point seems to be that a collection of elements can be
provided somehow and that the implementation can execute the query on
each distinct element in that collection. How exactly that is done is
just an API design issue.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
