Re: Supporting Scoped Selectors in Selectors API 2

On Tue, 29 Sep 2009 15:16:25 +0200, Lachlan Hunt  
<lachlan.hunt@lachy.id.au> wrote:
> Anne van Kesteren wrote:
>> 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.
>
> Well, that's not true, based on the fact that thousands of authors using  
> JS libraries seem to be having absolutely no trouble with the special  
> syntax and many find the results to be rather intuitive.  Even fantasai  
> claimed earlier in this thread [1] that the results would be more  
> intuitive, despite subsequently objecting to the essential processing  
> requirements that would achieve those results.  So your claim is  
> demonstrably false.

I made two claims. And I'm not convinced the latter claim is false. Every  
feature we add to the Web platform increases complexity and increases the  
amount of things authors have to learn. It has not even been demonstrated  
that this library feature is often used and widely understood by authors,  
let alone that authors outside that community would find it intuitive.


> But I believe I have found a way to make even more intuitive without  
> breaking anyone's expectations.
>
> I removed the syntactic flag from the scoped selector string and  
> introduced scoped methods instead.
>
> When those methods are used, for each selector in the group, if the  
> first sequence of simple selectors contains :reference, then no special  
> processing is performed.  Otherwise, if it begins with a sequence of  
> simple selectors that doesn't contain :reference, then :reference  
> followed by a descendant combinator is inserted.  Otherwise, if it  
> begins with a combinator (>, + or ~), then :reference is inserted.
>
> For example,
>
> "div div" becomes ":reference div div"
> "+p" becomes ":reference+p"
> ":reference>p" is unchanged.
>
> This allows authors to be explicit if they don't like the shorthand  
> syntax, while still allowing the shorthand for those that do.

This still requires changes to how Selectors are processed so that does  
not satisfy me. E.g. :reference could have been written as :refer\0045nce.  
Also introducing new methods while there are easy and simple workarounds  
sounds like adding bloat for no good reason. I do not think we should  
increase the feature set of the Web platform unless it gives a real  
benefit.


>>> 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 :-)
>
> Right, JS libraries do have their own significant overhead.  But by  
> making the APIs more complex to use than needed, we only increase the  
> overhead and increase authors dependance on them, which doesn't help at  
> all.

It helps keeping the Web platform simple by not introducing special  
parsing of Selectors if they are used in an API.


> [1] http://lists.w3.org/Archives/Public/www-style/2009Sep/0261.html


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

Received on Tuesday, 29 September 2009 13:36:59 UTC