Re: [SelectorsAPI] Thoughts on querySelectorAll

John Resig wrote:
> If there was an extra property to point to what the inappropriate selector was,
 > that'd be fundamentally important. Probably the best solution
 > (for both implementers and JavaScript library authors) would be to simply provide
 > a character index, working something like the following:

I should note that this might not be all that work-free for implementors either, 
unless they already keep track of this information in selector parsing. 
Certainly Gecko would have to add extra code to do this... and I'm not sure that 
the resulting index is that useful.  See below.

> The resulting solution in most libraries would then look something like
 > (of course different caching could take place, as well):
> 
>   try {
>     results = document.querySelectorAll(selector);
>   } catch(e) {
>     results = filterQuery(
>       document.querySelectorAll( selector.slice(0, e.position) ),
>       selector.slice(e.position)
>     );
>   }

So say the original |selector| is ":not(:link)" and the UA doesn't support 
:link.  This will presumably split the string into ":not(" and ":link)", neither 
of which is that useful.

Or say the original |selector| is "div ~ span" and the UA doesn't support the 
'~' combinator.  You end up with "div" and "~ span" as the two pieces and then 
what?  To apply the above query-and-filter solution you'd really want to 
querySelectorAll("span") and then filter based on "div ~", I would think.

This is not even worrying about cases when the querySelectorAll call passes in 
multiple comma-separated selectors...

So while I appreciate the desire to get more information out of the error, I'm 
not sure a character index gives you the sort of information you really want. 
What you somehow really want is the largest sequence of characters starting from 
the right which the UA still considers to be a valid selector.  You could then 
query for this group, and then filter using the rest.  But getting that sort of 
information is a lot of work, and not easily done as part of normal 
left-to-right selector parsing.  Oh, and even that will break as soon as there 
is an implemented proposal for :subject or something along those lines, since at 
that point the nodes actually matching won't get picked up by a querySelectoAll 
on the rightmost bits.

To really be future-proof here, both in terms of new syntax and in terms of new 
pseudo-classes and their interaction with :not(), I think the only thing that 
can be done without a rather large amount of effort on the part of either UAs or 
libraries is to just handle the query entirely "by hand" if there's a parsing 
error in the querySelectorAll call.

I could be wrong, of course.  Maybe someone will think of an error reporting 
mechanism that provides information that's useful and isn't too cumbersome for 
UAs.  But I should note that this can always be done as a later addition to the 
specification.  That is, adding more information to the exception is a 
backwards-compatible change: if the information isn't present, just redo the 
query by hand, else do something with the information.  So it might make more 
sense for a later version of the specification, possibly, if it looks like 
coming up with a decent solution here would take a while and people want to move 
  the rest of the spec out of limbo.

-Boris

Received on Thursday, 1 May 2008 00:04:12 UTC