Re: Supporting Scoped Selectors in Selectors API 2

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.

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

2. A boolean argument passed to the existing querySelector() methods.

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.

4. A special syntactic flag in the selectors argument, as used in the
    current proposal.

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

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

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

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.

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

Received on Monday, 28 September 2009 21:00:17 UTC