W3C home > Mailing lists > Public > public-webapi@w3.org > May 2006

Re: ACTION-87: Selectors API

From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Date: Wed, 17 May 2006 23:19:46 +1000
Message-ID: <446B22F2.6020401@lachy.id.au>
To: Anne van Kesteren <annevk@opera.com>
CC: liorean <liorean@gmail.com>, "Web APIs WG (public)" <public-webapi@w3.org>

Anne van Kesteren wrote:
> On Wed, 17 May 2006 06:29:54 +0200, liorean <liorean@gmail.com> wrote:
>>>    * Several people have raised issues with naming the methods match and
>>> matchAll as those might suggest a boolean return value. Alternate 
>>> suggestions
>>> have been select and selectAll.
>> For ECMAScript, I think "match" is a fine choice of verb and is
>> consistent. For the closest comparison, regex 'match' isn't boolean.
> Sure, I like match() as well. Mostly because it's short and simple, but 
> there were some concerns raised.

I like match() too because it's much shorter than 
getElementsBySelector(), but I think the fact that it only returns a 
single node is confusing and that, in most cases, authors would want the 
whole collection, not just the first match.  I think it would be better 
if the methods were:

interface DocumentSelector {
   StaticNodeList match(in DOMString selectors, in XPathNSResolver 
   Node matchOne(in DOMString selectors, in XPathNSResolver nsresolver);

Or possibly matchFirst() instead.

>>     <doc>
>>     /.../
>>         <elm1>
>>             <elm2 xml:id="bleh">
>>                 <elm3/>
>>                 <elm3/>
>>             <elm2>
>>         </elm1>
>>     /.../
>>     </doc>
>>     var
>>         selectorMatches=document.getElementById('bleh').matchAll(':root
>> elm3',resolver);

What's wrong with using:

var selectorMatches = document.matchAll('#bleh elm3', resolver);

There may still be use cases for matching a sub tree, so it may be worth 
extending the Element interface too, but all the ones I can think of can 
be handled by simply writing a more specific selector.

Lachlan Hunt
Received on Wednesday, 17 May 2006 13:20:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:21 UTC