Re: [ANN] Selectors API

On Thu, 08 Jun 2006 01:12:40 +0200, Cameron McCormack <cam@mcc.id.au>  
wrote:
>   ▪ (1) “This specification introduces two methods which take a
>     selector (technically a group of selectors) as argument and return
>     the matched elements as result.”
>
>     Why not just call them a group of selectors from the get go, since
>     that’s the correct term?

Since it's the introduction.


>   ▪ (1.1) The example ‘test’ function uses matchAll to select “:root”.
>     This returns a StaticNodeList, but you compare it for strict
>     equality with the document element.  This is always going to be
>     false.

The node is not a copy, why would it be false?


>   ▪ (1.2) Maybe a sentence just before the list of conformance classes
>     such as “The following conformance classes are defined by this
>     document:” should be present.

Thanks, added.


>   ▪ (1.3) Although it’s obviously a reasonably subjective issue, FWIW I
>     say to use select and selectAll.

I registered more votes for this and I personally would like to use them  
as well, but the main concern is that authors would confuse them with  
selectNode and selectSingleNode (used for XPath). What's your take on that?


>   ▪ (1.3) Regarding extensibility being addressed by DOM 3 Core, what
>     extensibility is being envisaged exactly?  The extensibility section
>     in 2.1.1 doesn’t give much.

How vendor extensions to the interface are done when they are not part of  
a standard. If the semantics of the members of interface can change  
overtime (I guess) and all kind of related questions. 2.1.1 was just some  
tryout.


>   ▪ (1.3) I was going to mention the default namespace.  DOM 3 XPath
>     says of the XPathNSResolver: “The XPath evaluator must never call
>     this with a null or empty argument, because the result of doing this
>     is undefined.”  I don’t think this would be incompatible with
>     Selectors API defining what happens with null is passed as the
>     argument (i.e., to return the default namespace’s URI if one is
>     desired) in the context of the DocumentSelect methods.

Yeah, I'm coordinating this with Jonas when he edits the XPath document.


>   ▪ (2.1) I think the term “document order” is sufficiently known that
>     it’s unnecessary to say that it uses a “depth-first pre-order
>     traversal”.

I think being clear doesn't hurt here.


>   ▪ (2.1) Having matchAll return null if no nodes matched, instead of an
>     empty NodeList, is somewhat inconsistent with other DOM methods that
>     return NodeLists, such as Document.getElementsByTagName.

Let's resolve this once it's decided if we go with an Array or not (and we  
probably go with an Array; DOMArray).


>   ▪ (2.1) Should mentioning that an ECMAScript Function can be passed as
>     the namespace resolver be in a separate bindings section?  Perhaps
>     this can defer to Bindings For DOM if that is completed in time.
>     Either way, the “MUST do this thing (or MAY do this other thing)”
>     feels strange.  Maybe omitting the MAY would help.

Good call, dropped MAY there.


>   ▪ (2.1.1) “Authors may use extension mechanisms specific to the host
>     language, like .prototype in ECMAScript.”  I don’t know what kind of
>     extensibility this is meant to be referring to.  Assigning to
>     myNSResolver.prototype.lookupNamespaceURI for some reason?

This is just some text to make people complain. I hope to be able to  
remove the section...


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Thursday, 15 June 2006 10:41:24 UTC