On Thu, 08 Jun 2006 01:12:40 +0200, Cameron McCormack <[EMAIL PROTECTED]>
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/>
