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

Re: [ANN] Selectors API

From: Cameron McCormack <cam@mcc.id.au>
Date: Thu, 8 Jun 2006 09:12:40 +1000
To: Public Web API <public-webapi@w3.org>
Message-ID: <20060607231240.GC23246@port.mcc.id.au>

Robin Berjon:
>   http://www.w3.org/TR/selectors-api/


I have some further comments:

  ▪ (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?

  ▪ (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

  ▪ (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.

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

  ▪ (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.

  ▪ (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.

  ▪ (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

  ▪ (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.

  ▪ (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.

  ▪ (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?



Cameron McCormack, http://mcc.id.au/
	xmpp:heycam@jabber.org  ▪  ICQ 26955922  ▪  MSN cam@mcc.id.au
Received on Wednesday, 7 June 2006 23:12:49 UTC

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