Re: Selector Parsing for Selectors API

On Tue, Jan 15, 2013 at 2:59 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> On Tue, Jan 15, 2013 at 9:02 AM, Sylvain Galineau
> <sylvaing@microsoft.com> wrote:
> > [Lachlan Hunt:]
> >> You need to separate scoped stylesheets from the API.  HTML scoped
> >> stylesheets use scope-contained by default. find() uses scope-relative.
> >>  matches() uses a variant of scope-relative that isn't yet defined
> there.
> >>
> > Do we believe developers will keep these straight in their heads?
> > Note: I'm not trying to be facetious; there seem to be important nuances
> > involved. Has any kind of usability testing been done or is this
> something
> > to be figured out once implementations get out there?
>
> Based on my own experiences with the equivalents that already exist, I
> think the current behavior is what people expect.  People are used to
> jQuery's selector engine, which is exactly scope-relative (in
> particular, it lets you do "+ foo" to get the sibling of the scoping
> element).  On the other hand, when using ids to scope portions of a
> stylesheet, I rarely see people trying to get things outside of that
> scope.  When they do wish to do so, we'll have the @host rule or
> whatever to switch them over to scope-relative.
>
> ~TJ
>
>

I agree with Tag on this point, it is very intuitive and that particular
one has been re-gone over on the list for more than a decade - in fact -
I'm pretty sure that's probably where John Resig got it from in the first
place.... There is a great historical debate between fantasai and hixie on
matches/has and combinators (in which, for the record, I actually agreed
more with hixie).

One more piece of feedback here - most of us were really disappointed when
qsa didn't work this way to begin with, but the funny part about an API is
that it lets people imagine things that they couldn't before and actually I
think having both opens interesting possibilities that I am glad we will
have.

-- 
Brian Kardell :: @briankardell :: hitchjs.com