Re: [selectors-api] Scoped Selectors

John Resig wrote:
>> 3. Obtain a collection of elements based on their relation to more than one
>> specified reference elements.
>>
>> e.g.
>> Query to the document to obtain elements matching ":scope+span", where
>> :scope is intended to match any of the elements in a specific collection.
>>   This would be simpler than iterating all of the nodes in the collection,
>> running the query on each of them and then merging the results.
>
> I don't see the purpose of making a distinction between the root node used
> for the query and the node being used for the scope - they should be one and
> the same.
>
> // Doesn't make sense:
> document.querySelectorAll("div div", document.body)
>
> // Does make sense
> document.body.querySelectorAll("div div")

It does make sense.  It just means something slightly different from 
what you appear to be thinking.  In the above, the document.body element 
wouldn't have any effect because it's not a scoped selector and there is 
no :scope pseudo-class used.

> Also, I don't think it's been made clear in the discussion thus far but
> while cases like handling ">  div" are nice - we're mostly concerned about
> cases like "div div" (that escape outside the original root of the query).

The problems with handling ">div", "+div" and "div div" are exactly the 
same issue.  The only difference is that the first 2 begin with a child 
combinator and sibling combinator, respectively, and the latter has an 
implied descendant combinator.  They can all be addressed with the same 
solution.

> Given this DOM:
>
> <body>
>    <div id="one">
>      <div id="two"></div>
>    </div>
> </body>
>
> // All of these should return nothing
> document.getElementById("one").querySelelctor("div div")
> document.getElementById("one").querySelelctor("body div")
> document.getElementById("one").querySelelctor("div #two")

The real benefit of the API as I first designed it, is that it elegantly 
provides ways to address nearly every use case raised and more, using 
the simple, yet extremely powerful concept of contextual reference 
elements, which is in fact not so different from the pattern used in 
JQuery: $("selector", context);.

> There doesn't need to be scoping for matchesSelector. matchesSelector
> implies that it it's starting from the specified node and doing a match.
> Additionally the use case of .matchesSelector(">  div") doesn't really exist.

The use case doesn't really exist when the context node is considered to 
be the contextual reference element.  But allowing reference nodes to be 
specified, it allows the query to check where it is in relation to 
another element.  So, for example you could more easily check if the 
parent of element elm is one of the nodes in the collection elms.

var elms = [div1, div2, div3];
e.g. elm.matchesSelector(":scope>*", elms);

Returns true if the elm.parent == div1, elm.parent == div2 or elm.parent 
== div3.

> With that in mind, option #3 looks the best to me. It's lame that the API
> will be longer but we'll be able to use basic object detection to see if it
> exists. Unfortunately the proper scoping wasn't done the first time the
> Selectors API was implemented so we kind of have to play the hand we've been
> dealt.
>
> Thus there would be two new methods:
> queryScopedSelectorAll
> queryScopedSelector

I really didn't want to introduce new methods for this if it could be 
avoided.  I realise one problem with the first draft of the API I posted 
yesterday was that is was too cumbersome for scripts to create and use 
scoped selectors, rather than normal selectors.  That draft required 
scripts to do the following:

var selector = document.createSelector("+p", true);
document.querySelector(selector, elm);

I have come up with a significantly simpler, alternative solution that 
not only abolishes the createSelector() method and the 
SelectorExpression interfaces, but also avoids introducing additional 
methods like queryScopedSelector(), or extra parameters.

The draft now defines the concept of a *selector string* and a *scoped 
selector string*.  The selector string is just an ordinary selector, as 
supported by current implementations.

A scoped selector string is a string that begins with an exclamation 
point followed by a the remainder of the selector.  The purpose of the 
exclamation point is to clearly identify the string as a scoped selector 
that requries an extra pre-processing step to turn it into a valid group 
of selectors.

There are also slightly different requirements for the processing 
Element.querySelectorAll() when the selector argument is a scoped 
selector string.  This allows for the sibling combinator cases to work.

e.g. The selector ">em, >strong" supported by JS libraries can simply be 
prefixed with a "!", like "!>em, >strong" and the implementation will be 
able to process it to become ":scope>em, :scope>strong".  Of course, it 
will also work with the other combinators.

This allows JS libraries to trivially prepend "!" to the selector before 
passing it to the API, rather than requiring any complicated 
pre-processing.  In current browser implementations, the "!" will 
trigger a syntax error and allow JS libraries to fallback to their 
custom processing.

The following examples illustrate how this API can be used to address 
the use cases.  Assume the variable elm refers to a single element and 
and elms refers to  a collection of elements, such as an array or nodelist.


Use Case: Select elements based on their relationship to one specific 
element.  i.e. Given an Element elm, be able to select child, grandchild 
or sibling elements.

In JQuery:

   $(">em, >strong", elm);
   $("div div", elm);
   $("+p", elm)

or the equivalents using $(elm).find("...");

To do either of these in Selectors API, use:

   // Equivalent to ":scope>em, :scope>strong". Use either:
   document.querySelectorAll("!>em, >strong", elm);
   elm.querySelectorAll("!>em, >strong");

   // Equivalent to ":scope div div". Use either:
   document.querySelectorAll("!div div", elm);
   elm.querySelectorAll("!div div");

   // Equivalent to ":scope+p". Use either:
   document.querySelectorAll("!+p", elm);
   elm.querySelectorAll("!+p");


Use Case: Select elements based on their relationship to elements in a 
collection.  i.e. Given a collection of elements elms, be able to select 
child or grandchild elements, or sibling elements, of each element in 
that collection.

In JQuery:
   $(">em, >strong", elms);
   $("div div", elms);
   $("+p", elms)

This effectively works the same as the previous use case.  Just create 
the selectors in the same way, and pass the elms collection to 
querySelectorAll(), as in:

   document.querySelectorAll("!+p", elms);


Use Case: Given a collection of elements, find a subset that meets 
specific conditions.  e.g. Given an array of elements elms, select only 
those that have a specific class name.

For instance, a document contains several input elements, like:

<input type="text" name="addr-line1" class="required">
<input type="text" name="addr-line2">
<input type="text" name="addr-suburb" class="required">
<input type="text" name="addr-country">

In JQuery:
var elms = $("input");
// do something with elms.
// Now select only the required controls for additional processing:
var filterdList = elms.filter(".required");

document.querySelectorAll(".required:scope", elms)

(There's currently no shorthand syntax that can be used by JS libraries 
to have this generated automatically.  It might be worth defining one 
analogous to scoped selector strings.)

The one limitation of the above is that if the elms collection contained 
nodes from both within the document and disconnected elements, only 
matching elements within the document would be selected.  (The results 
would be similar, if this was done on a DocumentFragment or disconnected 
Element node).  So it's not quite identical to running the query on each 
individual element and merging the results.  But it's not clear whether 
or not such a use case is significant.  It seems more natural to want to 
restrict the results to those within the same tree.

See the current editors draft for more details.
http://dev.w3.org/2006/webapi/selectors-api2/

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

Received on Saturday, 26 September 2009 20:37:08 UTC