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
Received on Wednesday, 17 May 2006 12:18:22 UTC

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