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

Re: ACTION-87: Selectors API

From: Anne van Kesteren <annevk@opera.com>
Date: Wed, 17 May 2006 14:18:12 +0200
To: liorean <liorean@gmail.com>
Cc: "Web APIs WG (public)" <public-webapi@w3.org>
Message-ID: <op.s9osvcbk64w2qv@id-c0020.customers.swisscom-eurospot.com>

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 think there's some confusion here about what is requested and what
> you think is requested. What I personally mean when I want to have a
> way to ask for all nodes in a NodeList that matches a selector or all
> nodes in an element's subtree that matches a selector doesn't effect
> the scope of the selectors. For example:
>
>     <doc>
>     /.../
>         <elm1>
>             <elm2 xml:id="bleh">
>                 <elm3/>
>                 <elm3/>
>             <elm2>
>         </elm1>
>     /.../
>     </doc>
>
>     var
>         selectorMatches=document.getElementById('bleh').matchAll(':root
> elm3',resolver);
>
> This selectorMatches variable would be StaticNodeList of both nodes in
> the subtree below #bleh that match the selector. It would not at all
> affect the scoping of the selector (':root' still matches the 'doc'
> element, for example). It would only affect a single thing: it would
> ask for matches in a subtree of the document instead of all matches in
> the entire document tree.

That would be a different request yes. This issue was not really coming  
 from you though... I guess I could add it, but it probably won't make the  
first public Working Draft.


> At least one issue more that I think should be added:
>
> Currently you can ask "gimme all matches in the document against this
> selector" but you can't ask "I've got this element handle (from
> event.target or whereever). Does this very element match this
> selector?". Even if you did add 'match' and 'matchAll' on the Element
> interface, those don't make it any easier to get an answer to that
> question. So, some type of equivalent to regex.test(string) would be
> immensely useful.

We already discussed that and imho it's out of scope for this version.


> (It can also be noted that this is the only functionality really
> needed. Traversal is already in the DOM1, so that is not the problem.
> What is missing is the functionality of asking for if an element
> matches a selector.)

Well yeah, and XPath is in DOM Level 3... This is more about providing a  
simple way of selecting a bunch of modes based on a group of selectors.  
This functionality is already provided in libraries and people would find  
this really useful. (As would I!)


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
Received on Wednesday, 17 May 2006 12:18:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:55 GMT