[selectors-api] Scoped Selectors

Hi,
    I'm trying to find a suitable solution for the scoped selector
issues, but figuring out what the most suitable API is proving challenging.


*Use Cases*

1. JS libraries like JQuery and others, accept special selector strings 
beginning with combinators. e.g. ">em,+strong". These libraries behave 
as if there was a selector that matched the context node.

e.g. In JQuery:

$("+p", elm);

This would select the p element that is a sibling of elm.

2. It would be useful to be able to check if an a given element matches 
a selector in relation to a specified reference element (:scope).  For 
example, check if an event target is a sibling of a specific element, 
and if the parent element has a specifc class name set.

e.g. Matches the selector: ".foo>:scope~input[type=text]"

This may be particularly useful for event delgation.

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.


*Problems*

1. Need a way to allow the browser to parse implicitly scoped selectors 
beginning with combinators and imply the presence of :scope before each 
in the group.

2. Need to allow :scope to be used within the selector strings, and 
specify one or more scope elements that will be matched by :scope.  This 
needs to be useable with all of the querySelector(), querySelectorAll() 
and matchesSelector() methods, or others with equivalent functionality.

3. Ideally, there would be an easy, reliable way for scripts to test if 
the implementation supports scoped selectors (at least, implicitly 
scoped selectors. Those using :scope could only be discovered by 
capturing the SYNTAX_ERR exception)  For legacy browsers that don't, 
they can fall back to their own selector engines.


*Possible Solutions*

1. Define a Selector object that can be used to parse and store a
     selector, and which can handle pre-parsing the selector and
     specifying the scope elements upon creation.  This selector object
     can then be passed anywhere that accepts a selector string. (This is
     basically part of the createSelector() and Selector interface
     proposal from earlier).

2. Add parameters to the querySelector(), querySelectorAll() and
     matchesSelector() methods for:
     a. Indicating whether the selectors parameter should be processed
        with an implied scope.
     b. Specifying one or more reference elements that would match :scope.

3. Create new scoped versions of the existing methods that accept one
     or more reference elements that would match the implied scope.
     Add an optional parameter to the existing querySelector*() methods
     that would Allow one or more reference elements to be specified to
     match the explicit use of :scope in the selector.


Option 2 doesn't provide an easy way to detect browser support.  Option 
3 creates an additional queryScopedSelector*() and 
matchesScopedSelector() methods, but this could get quite verbose if we 
also add equivalent NS methods to handle the namespace issue, to both 
the scoped and non-scoped versions.  This would create an unreasonable 
number of different methods that would make understanding the API quite 
complex.  Option 1 is syntactically messy, and requires the creation of 
a new object just to handle a scoped selector, even if that selector is 
only used once.

I'm not sure which alternative would be best, and I'm kind of hoping 
there's a 4th alternative I haven't thought of yet that can address the 
use cases easliy enough.

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

Received on Friday, 25 September 2009 03:01:46 UTC