- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Wed, 30 Apr 2008 18:56:33 -0500
- To: John Resig <jresig@mozilla.com>
- CC: public-webapi@w3.org
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