Re: Supporting Scoped Selectors in Selectors API 2

On Tue, 29 Sep 2009 13:07:41 +0200, Lachlan Hunt  
<lachlan.hunt@lachy.id.au> wrote:
> Anne van Kesteren wrote:
>> 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.

No it's not. I don't think the added complexity is worth it, especially  
considering that easy workarounds for the short term exist.


>> 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.

That seems like a good thing considering how querySelectorAll is defined.


> 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.

If you would use the same code for documents and fragments maybe. But that  
seems unlikely and the dominating case will be the use in documents anyway.


> 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.

You would find that out soon enough.


> 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.

I do not think it is as complex as you make it out to be (especially for  
the >90% case) and changing Selectors syntax has at least as much  
additional cognitive load if not more if you ask me.


> 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.

Giving that JavaScript engines are becoming increasingly optimized some  
very simple string processing does not seem like it will be that slower.  
The overhead will be more in using a library I'd think :-)


-- 
Anne van Kesteren
http://annevankesteren.nl/

Received on Tuesday, 29 September 2009 11:21:43 UTC