Re: [selectors-api] Scoped Selectors

> 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")

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).

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")



> *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.
>

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.

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

Same length as getElementsByClassName - long but not untenable.

--John

Received on Friday, 25 September 2009 17:27:37 UTC