Re: Supporting Scoped Selectors in Selectors API 2

Anne van Kesteren wrote:
> On Tue, 29 Sep 2009 00:50:35 +0200, fantasai
> <fantasai.lists@inkedblade.net> wrote:
>> Or, you could not allow any shortcuts here and require :reference (or
>> :scope, as Tab recommends, and I second) to be inserted explicitly in
>> such cases. I would imagine they're less common than the descendant case.
>
> I agree with this. Adding magic to the Selectors grammar is bad and
> makes things more complicated than needed.

You argument seems to be based on nothing more then theoretical purity. 
  The pragmatic approach here is to pave the cowpaths and provide an API 
that meets authors needs and expectations.

> I'm also not convinced this "problem" needs a special solution. If
> JavaScript libraries want to continue to support their own magic syntax
> they can add a very simple pre-processing step themselves. No need to
> complicate everything because of that.

The problem does need a special solution because without providing a 
scoped alternative, the ability for authors to use the API to do what 
they want is more complicated, and doesn't adequately address all use cases.

Using just the existing methods with :reference, refNodes, and without 
any special scoping requirements, the API is less intuitive.

elm.querySelectorAll(":reference+p") will not work.

The alternative for this would be to make authors use:

document.querySelectorAll(":reference+p", elm);

But then that doesn't work in the case of disconnected fragments, and so 
the author would instead have to use:

elm.parentNode.querySelectorAll(":reference+p", elm);

Though, authors can't naively do that either.  If elm happens to be a 
disconnected element node with no parent element, then that script will 
throw an exception.  So, if that code were part of a function that 
accepted a selector string and a context node (just like in JS 
libraries), the code would have to do this:

function(selector, elm) {
   if (elm.parentNode !== null) {
     elm.parentNode.querySelectorAll(selector, elm);
   } else {
     // The element has no parent, so no siblings either and
     // :reference+p won't match anything anyway. But other
     // selectors using other combinators will work.
     elm.querySelectorAll(selector, elm);
   }
}

That is very unintuitive and not so easy for authors to understand.  And 
let's hope authors using such a function never forget to explicitly 
include :reference, as the results could then include more elements than 
they were expecting.

We shouldn't require authors to jump through overly complicated hoops 
just to use the API to do what many are already doing significantly 
easier with JS libraries, and we definitely shouldn't make the API so 
complex that authors need to rely on the level of abstraction provided 
by JS libraries just to use it.

Then there's the problem that JS libraries will have to continue 
including their own, slower selector parsing libraries that have to 
handle the insertion of :reference themselves before passing it to the 
API, using a function similar to that above.

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Received on Tuesday, 29 September 2009 11:08:20 UTC