- From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
- Date: Mon, 19 Dec 2011 15:12:03 +0100
- To: Boris Zbarsky <bzbarsky@MIT.EDU>
- CC: public-webapps@w3.org
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/
Received on Monday, 19 December 2011 14:14:54 UTC