Re: More questions about contextual reference nodes

On 2011-04-09 10:12, Boris Zbarsky wrote:
> I have two questions about
> http://www.w3.org/TR/selectors-api2/#determine-contextual-reference-nodes
>
> 1) What are the use cases for supplying more than one contextual
> reference node, exactly? It seems weird to allow more than one node to
> match :scope.

There were cases in JQuery where the script wanted to iteratively run a 
selector on all nodes in a collection, and return elements that are 
descendants of those elements.  This allows :scope to be used in those 
cases by passing the collection as the refNodes.  There was previous 
discussion of this somewhere in the public-webapps archive.

> 2) If we do want to allow the multiple node thing, can we please do it
> in IDL instead of the (currently pretty vague) prose? Something like:

I know the draft is quite poorly written with regards to how to deal 
with collections right now.

> Element querySelector(in DOMString selectors,
> in optional Element refElement);
> Element querySelector(in DOMString selectors,
> in optional NodeList refElements);
> Element querySelector(in DOMString selectors,
> in optional sequence<Element> refElements);

I also have to include one for HTMLCollection, which doesn't inherit 
from NodeList.  But if that would be better, then yes, we can do that. 
It just makes the IDL 4 times longer, as that has to be repeated for 
each method of the 3 methods.  Ive made this change now.

I also dropped queryScopedSelector at the same time, since it wasn't 
able meet the original requirements that it was being designed for and 
so not worth keeping.

> or some such? It's not quite clear to me whether we want a
> "sequence<Element>" or a "T[]"; that's worth checking.

WebIDL says sequences are passed by value and arrays are passed by 
reference.  So I suspect using an array is better here so that it 
doesn't have to create a copy.

> In either case, the prose will need to define what happens with the
> NodeList or sequence/array cases, but there will be no ambiguity
> about how one gets Elements out of what's passed in. The one
> difference is that in the array case if non-elements are present in
> the array an exception will be thrown. I think that's fine, myself.

Yes, I would like feedback about the best way to define this, 
particularly for Arrays.  In particular, how to address the following cases.

var ref = [];
ref[0] = el1;
ref[1000000] = el2;

That will contain almost a million empty cells. Will iterating through 
that cause any unwanted performance issues?  Should we require arrays to 
contain contiguous Elements and only iterate up to the first empty or 
non-Element cell, ignoring anything beyond that?

ref[1] = "string";

Should passing this now throw an exception, or should it just accept 
that ref[0] was an element and use that?

For NodeLists, should it accept any NodeList and only use the Element 
nodes?  e.g. element.childNodes may contain text or comment nodes.

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Received on Saturday, 9 April 2011 13:27:40 UTC