Re: ACTION-87: Selectors API

Some comments on the outstanding issues:

> 1.3 Outstanding Issues
>This section is non-normative.
>
>The draft has several outstanding issues that either need to be
addressed in one
>way or another at some point:
>
>    * 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.
Regex 'match' returns an array of the matched data  - data which may
be either detail about a single match OR a list of all full matches
depending on whether the regex has a global flag.
Regex uses the verb 'test' for the boolean matching.

>    * There was at least one request for scoped selectors. For example, being able
>to do event.target.match() or in other words allowing the methods on Element
>nodes. Given that Selectors itself has no notion of scoped selectors
this might be
>difficult to define and is perhaps better delayed until the CSS WG has defined
>scoped selectors.

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.

>    * It would be nice if extensibility was addressed by DOM Level 3 Core or a
>separate specification that all DOM specifications could reuse.
>    * Need to look into XPathNSResolver and the default namespace.
>    * If DOM Level 3 Core gets errata we might be able to get away with not having
>a new interface at all for NodeList (StaticNodeList), but just say
that the object
>implementing the NodeList interface is not live.

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.

(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.)
-- 
David "liorean" Andersson
<uri:http://liorean.web-graphics.com/>

Received on Wednesday, 17 May 2006 04:30:04 UTC