Re: Supporting Scoped Selectors in Selectors API 2

On Wed, Sep 30, 2009 at 7:31 AM, Lachlan Hunt <lachlan.hunt@lachy.id.au> wrote:
> fantasai wrote:
>> I have a slight preference for
>> a) :scope instead of :reference
>
> This does seem to be the only name that people seem to be happy with,
> despite it being not entirely accurate for all use cases.  So far, all the
> names considered seem to have problems.  All the ones I can recall are:
>
> :scope, :this, :self, :context, :context-node, :reference, :ref, :important,
> :root, and the emoticon-inspired :D, :s and :p

I... didn't even think of using :this.  That has a very interesting
synergy with js's this variable.

My vote's for either :this or :scope then.

>> b) Requiring :scope when there's an explicit combinator so as not
>> to present incomplete selector fragments.
>
> I think that's suboptimal because it will require JS libraries to perform
> selector parsing themselves to insert the pseudo-class before passing it to
> the API.  But since adjusting selector parsing for this seems to be
> unacceptable :-(, I've reluctantly changed the spec to require the explicit
> pseudo-class when a combinator other than the descendant combinator is
> needed, so "+p" is no longer allowed. Scripts have to use ":reference+p"
> instead.  I will now have to deal with the inevitable complaints from
> authors and JS library develpers for making their lives harder.

Fantasai, was this really an issue in a new function?  I think
queryScopedSelector("+p") is just fine, and requiring the explicit
:scope is a lose considering the existing precedent in js selector
engines.  My issues were just dealing with the potential ambiguity
when both scoped and non-scoped were handled by the same function.

~TJ

Received on Wednesday, 30 September 2009 13:48:52 UTC