Re: Supporting Scoped Selectors in Selectors API 2

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

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.

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.

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

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

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

Received on Tuesday, 29 September 2009 13:17:43 UTC