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

Received on Friday, 25 September 2009 23:05:41 UTC