Re: Proposed Specification for find/findAll/matches
On 2011-12-12 17:57, Boris Zbarsky wrote: On 12/12/11 6:07 AM, Lachlan Hunt wrote: 2. These new methods for Element may be split out to a separate interface that omits the refElements and and refNodes parameters. Yes, please. There's no point having the same interface if the behavior is totally different based on the |this| object as described. In my opinion. I did this by defining partial interfaces for each of Document, DocumentFragment and Element, rather than having a single NodeSelector interface implemented by all three. Open Issue: Should this change affect Element.querySelector() too, or leave it as currently specified? One option is to simply not do any special scope stuff in querySelector, if we suddenly have no use cases for it. I removed the refNodes stuff from querySelector, since all use cases for it are covered by find/findAll. Given a selector list as input to the method, trim whitespace and then for each complex selector, run the first step that applies: (Note: if the selector list is , then there are 0 complex selectors in the list and the following doesn't run) | 1. Otherwise, if the complex selector begins with any combinator This needs to be defined better. complex selector can't begin with a combinator, per its definition. I defined the concept of a relative selector a custom grammar to handle this better. I also started updating the draft to use Selectors 4 and DOM4 references and terminology. Some DOM3 references still remain, but they'll be changed eventually. This meant the removal of terms like context node in favour of context object defined in DOM4, among others. The editor's draft is here. http://dev.w3.org/2006/webapi/selectors-api2/#the-apis -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: Proposed Specification for find/findAll/matches
On 2011-12-12 17:57, Boris Zbarsky wrote: On 12/12/11 6:07 AM, Lachlan Hunt wrote: Given a selector list as input to the method, trim whitespace and then for each complex selector, run the first step that applies: (Note: if the selector list is , then there are 0 complex selectors in the list and the following doesn't run) | 1. Otherwise, if the complex selector begins with any combinator This needs to be defined better. complex selector can't begin with a combinator, per its definition. For the purposes of this API, I think the spec needs to define a modified syntax for a DOM Selector, which is similar to, but slightly different from a regular selector. The grammar production would be: dom_selectors_group : dom_selector [ COMMA S* dom_selector ]* ; dom_selector : [ combinator ]? selector ; Where the productions for combinator and selector are defined in Selectors. The spec would then define that the parameter accepts a group of DOM selectors that matches that grammar. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: Proposed Specification for find/findAll/matches
This proposal looks really good and matches my expectations. Yehuda Katz (ph) 718.877.1325 On Tue, Dec 13, 2011 at 3:53 AM, Lachlan Hunt lachlan.h...@lachy.id.auwrote: On 2011-12-12 17:57, Boris Zbarsky wrote: On 12/12/11 6:07 AM, Lachlan Hunt wrote: Given a selector list as input to the method, trim whitespace and then for each complex selector, run the first step that applies: (Note: if the selector list is , then there are 0 complex selectors in the list and the following doesn't run) | 1. Otherwise, if the complex selector begins with any combinator This needs to be defined better. complex selector can't begin with a combinator, per its definition. For the purposes of this API, I think the spec needs to define a modified syntax for a DOM Selector, which is similar to, but slightly different from a regular selector. The grammar production would be: dom_selectors_group : dom_selector [ COMMA S* dom_selector ]* ; dom_selector : [ combinator ]? selector ; Where the productions for combinator and selector are defined in Selectors. The spec would then define that the parameter accepts a group of DOM selectors that matches that grammar. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: Proposed Specification for find/findAll/matches
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.h...@lachy.id.au wrote:
6. *Proposed IDL*
interface NodeSelector {
Element find(DOMString selectors, optional Element refElement);
Element find(DOMString selectors, sequenceNode? refNodes);
??? findAll(DOMString selectors, optional Element refElement);
??? findAll(DOMString selectors, sequenceNode? 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
