W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: Proposed Specification for find/findAll/matches

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 12 Dec 2011 08:30:08 -0800
Message-ID: <CAAWBYDDVgeA5+o1R5YOu3ScNNBcXjXq6cXLwVwUK7s5_RaH0gQ@mail.gmail.com>
To: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Cc: public-webapps <public-webapps@w3.org>
Thanks for doing the work here, Lachlan!  This appears to be an
excellent summary of the discussion and a consistent proposal.

On Mon, Dec 12, 2011 at 3:07 AM, Lachlan Hunt <lachlan.hunt@lachy.id.au> wrote:
> 6. *Proposed IDL*
>
> interface NodeSelector {
>  Element   find(DOMString selectors, optional Element refElement);
>  Element   find(DOMString selectors, sequence<Node>? refNodes);
>
>  ???       findAll(DOMString selectors, optional Element refElement);
>  ???       findAll(DOMString selectors, sequence<Node>? refNodes);
> };
> Document implements NodeSelector;
> DocumentFragment implements NodeSelector;
> Element implements NodeSelector;
>
> This extends the same interface as that the existing querySelector methods
> use, which will make the methods available on elements, documents and
> fragments.
>
> Open Issues:
>
> 1. The return type for findAll is yet to be decided. It may be the
>   proposed NodeArray, a regular Array or something else.

It really needs to be NodeArray or whatever, so we can hang
.find/All() and many other useful methods off of it.


> 2. These new methods for Element may be split out to a separate
>   interface that omits the refElements and and refNodes parameters.

I'd agree with this.  Given that the refs are ignored on Element,
there's no reason to keep them in the IDL; it'll just be confusing.

> 3. Do we need both find() and findAll(), or should we only have a
>   single new method that returns a collection?

I'm still slightly for only having the single method that returns a
collection, but the original arguments for having a single-node
version still hold (efficiency, etc.), and many people still want it,
so I'm fine with it.

> Additionally, matchesSelector() will simply be renamed to matches().

With the detail (specified below) that it'll imply scope the same way
that .find() does, this is excellent.

> Open Issue: Should findAll("") and find("") throw SYNTAX_ERR or return empty
> collection and null, respectively?

No opinion on this.  I've never used "" in jQuery.  I assume it can be
used when you've built a selector in a switch or if-chain, and one of
the cases is just "use the same elements again".  However, in our
method you can just use ":scope" for that, so it doesn't seem
necessary to support it with the empty-string case as well.


Your :scope prepending rules look good as well.

~TJ
Received on Monday, 12 December 2011 16:36:26 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:49 GMT