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/
