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

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/

Received on Thursday, 24 September 2009 18:22:30 UTC