Re: Supporting Scoped Selectors in Selectors API 2

Lachlan Hunt wrote:
> fantasai wrote:
>> I agree with Tab here, the use of ! is a strange way of handling special
>> cases like this. Its exceptional use is confusing, and its scoping is
>> inconsistent with the way selectors work. I'd rather see something like
>>
>> elm.scopeSelector("div div, div p")
> 
>> I think it's much clearer how that works and it avoids screwing around
>> with the Selectors syntax.
> 
> No, it absolutely does require screwing around with the selector syntax 
> regardless because it needs to allow each selector in the group to have 
> its first simple selector omitted and begin with a combinator.
> 
> e.g. ">em, +strong, ~b, i"
> 
> Each of those needs to have an implied :reference pseudo-class inserted 
> before it, and the last also needs an implied descendant combinator 
> inserted.

Or, you could not allow any shortcuts here and require :reference (or
:scope, as Tab recommends, and I second) to be inserted explicitly in
such cases. I would imagine they're less common than the descendant case.

>> I will also note that the use of ! has been proposed for other things,
>> and I would strongly prefer if your API did not introduce any new
>> punctuation into the Selectors syntax.
> 
> The point is that in order to solve the problem, we need some kind of 
> indicator to say that this is a scoped selector.  This indicator is used 
> for two purposes:
> 
> 1. Altering selector parsing to allow selectors to begin with
>    combinators and to insert implied :reference pseduo-class at the
>    beginning.
> 
> 2. Addressing the sibling element problem by modifying the selection
>    processing so that they can be selected as well. e.g. In the case of
>    ":reference+p".  Note that the current methods are restricted to
>    descendant elements only.
> 
> The solutions considered so far include:
> 
> 1. New queryScopedSelector() and queryScopedSelectorAll() methods.
> ...
> The first option is messy because it requires the introduction of so 
> many new methods, and it gets even more messy if we need to introduce 
> namespaced versions in the future like querySelectorNS(), 
> querySelectorAllNS(), queryScopedSelectorNS() and 
> queryScopedSelectorAllNS().

Sorry, I don't understand this. Why do you need separate methods for
namespaced versions? (What does it mean, a namespaced version of
querySelector?)

> 2. A boolean argument passed to the existing querySelector() methods.
> 
> The second option is a non-starter because it provides absolutely no way 
> of detecting implementation support and would give different results in 
> implementations with and without results.

I'm not much in favor of this either.

> 3. Define a document.createSelector() factory method that handles the
>    special selector parsing to create a SelectorExpression object which
>    can then be passed to querySelector.
>
> I initially tried the third option.  Although it had the advantage of 
> isolating the special selector parsing to a dedicated method, it proved 
> to be very cumbersome to use the API, and thus didn't adequately solve 
> the problem.

Yes, that looks annoying to use.

> 4. A special syntactic flag in the selectors argument, as used in the
>    current proposal.
> 
> That left me with the fourth and final option that I decided to try and 
> see if it will work.  I tried to make it as benign as possible, so that 
> it is a flag that is stripped from the beginning of the string before 
> selector parsing begins.  i.e. You don't need to use it at the beginning 
> of each selector in the group. (e.g. "!div, p" becomes ":reference div, 
> :reference p").

This is worse than a boolean flag. How is this not worse than a boolean
flag?

> The final option is to simply forgo the special parsing entirely and 
> require authors and javascript libraries to insert explicit :reference 
> pseudo-classes at the beginning of each selector, but we'd still need to 
> find some way of addressing the sibling element problem, and that would 
> require authors to use a more complicated approach like:
> 
> elm.parentNode.querySelectorAll(":reference+p", elm);
> 
> But that makes things more complicated because scripts would first need 
> to check if the element has a parent node, which it may not in the case 
> of disconnected elements, and then fallback to alternative processing.

Sorry, but I don't understand how your special syntax make a difference
here.

~fantasai

Received on Monday, 28 September 2009 22:51:18 UTC