Re: Proposed Specification for find/findAll/matches

On 12/12/11 6:07 AM, Lachlan Hunt wrote:
> 2. These new methods for Element may be split out to a separate
> interface that omits the refElements and and refNodes parameters.

Yes, please.  There's no point having the same interface if the behavior 
is totally different based on the |this| object as described.  In my 
opinion.

> Open Issue: Should this change affect Element.querySelector() too, or
> leave it as currently specified?

One option is to simply not do any special scope stuff in querySelector, 
if we suddenly have no use cases for it.

> Given a selector list as input to the method, trim whitespace and then
> for each complex selector, run the first step that applies:
>
> (Note: if the selector list is "", then there are 0 complex selectors in
> the list and the following doesn't run)
>
> | 1. Otherwise, if the complex selector begins with any combinator

This needs to be defined better.  "complex selector" can't begin with a 
combinator, per its definition.

I think we all sort of maybe understand how this should work, but there 
still needs to be a clear normative definition of the parsing.  Then we 
can check whether your maybe-understanding was actually shared, for one 
thing.

-Boris

Received on Monday, 12 December 2011 16:58:09 UTC