Re: [selectors-api] Scoped Selectors

Lachlan Hunt wrote:
> Sean Hogan wrote:
>> Here's a proposal.
>>
>> querySelector*(selector, context) // allows selectors with :scope
>> pseudo-class
>> queryScopedSelector*(selector, context) // allows selectors with implied
>> :scope
>> matchesSelector(selector, context) // allows selectors with :scope
>> pseudo-class
>
> Yes, this is effectively the same as option #2 that I described, 
> except you haven't provided a way to support implied scope there.

That's because implied scope is incompatible with ":scope ~ p" or "~ p" 
should we want to support those. I think it will be confusing to have 
implied and explicit forms for :scope.

>> element.querySelector*() limits selection to descendants of elements,
>> and element.queryScopedSelector*() should be consistent.
>> If element is the scope then element.queryScopedSelector*("~p") will
>> return no elements.
>> If we want to support sibling queries then we need to provide a scope
>> explicitly, so:
>>
>> element.parentNode.queryScopedSelector*("~p", element);
>>
>> Notes:
>> 1. I don't think browsers should provide queryScopedSelector*()
>
> This seems contradictory.  You seemed to be proposing that we use 
> queryScopedSelector, and now you're saying we shouldn't.  Personally, 
> I agree that we shouldn't.  It's my least favourite solution of them all.
>

I don't think implied ":scope" selector text should be supported at all. 
It's a whim of the JS libraries. I'm just concerned that if we do have 
it then at least it doesn't screw up the core functionality.

>> 2. I think :context is a better name than :scope
>
> Yeah, the name of :scope is a complicated issue. :context isn't ideal 
> either.  It would be slightly confusing because selectors API defines 
> the term "context node" as being the node upon which the method is 
> being invoked.  Maybe something like :ref or :reference might work.
>

Yeah.

>> 3. If the context argument of these methods could be an element or a
>> NodeList it might satisfy some of the other feature requests.
>
> Yes, the reference elements parameter will accept either a single 
> element, Array or NodeList.
>
> I have checked in a new draft containing my first attempt at 
> supporting scoped selectors, with support for both :scope (or whatever 
> it gets called) and implied scope selectors.  I've opted for a 
> combination of options 1 and 2 that I previously described, using the 
> createSelector() and SelectorExpression object for being able to 
> represent implied scoped selectors easily, and optional refNodes 
> parameters on querySelector*() and matchesSelector() methods for 
> supplying contextual reference elements (that match :scope).
>
> Basically, for the simple case, it works as illustrated in these 
> examples:
>
> elm.querySelector(":scope>p");
> document.querySelectorAll(":scope>p", elm);
> document.querySelectorAll(":scope>p", [elm1, elm2]);
>
> To provide the functionality of JS libraries supporting implied scope 
> selectors, you first create a SelectorExpression object like this:
>
> document.createSelector(">em,>strong", true);
>
> That object can then be passed to either the querySelector*() or 
> matchesSelector() methods.
>
> The effect of this is basically that JavaScript libraries can mostly 
> use document.createSelector(str, true) as a direct replacement their 
> own custom selector parsing libraries (except for the cases where 
> they're using custom pseudo-classes not supported by the browser)
>
> One possible modification I'm considering is introducing a separate 
> factory method for creating implied scope selectors: 
> createScopedSelector(selector); rather than using a boolean parameter.
>


Looks okay, except I don't think there should be implied contextual 
reference elements.
What are the chances that we will have to extend createSelector in the 
future? e.g. namespaces