RE: [selectors-api] Summary of Feature Requests for v2

2009-10-16 Thread Mike Wilson
Hi Lachlan, Another use-case for selectors, that I come across sometimes, is to be able to limit the query to first-level matches. Typically, this would be used in solutions where script wants to get the top matches, do some work that may affect the query results below these matches, then run a s

Re: [selectors-api] Summary of Feature Requests for v2

2009-09-30 Thread Garrett Smith
On Fri, Sep 25, 2009 at 8:11 AM, Boris Zbarsky wrote: > On 9/25/09 1:35 AM, Garrett Smith wrote: >> >> No, you did not say it is slow. I'm saying that your laptop is >> probably a lot more powerful than a mobile device with a browser, such >> as Blackberry9000. Do you agree with that? > > Sure.  I

Re: [selectors-api] Summary of Feature Requests for v2

2009-09-28 Thread Garrett Smith
On Mon, Sep 28, 2009 at 2:31 AM, Lachlan Hunt wrote: > Garrett Smith wrote: >> >> On Thu, Sep 24, 2009 at 1:28 AM, Lachlan Hunt >>  wrote: >>> >>> And overload the querySelector() and querySelectorAll() methods to also >>> accept a Selector object as the selector parameter. >>> >>> createSelector

Re: [selectors-api] Summary of Feature Requests for v2

2009-09-28 Thread Lachlan Hunt
Garrett Smith wrote: On Thu, Sep 24, 2009 at 1:28 AM, Lachlan Hunt wrote: And overload the querySelector() and querySelectorAll() methods to also accept a Selector object as the selector parameter. createSelector would allow the browser to parse and compile the selector and store it, much like

Re: [selectors-api] Summary of Feature Requests for v2

2009-09-27 Thread Garrett Smith
On Thu, Sep 24, 2009 at 1:28 AM, Lachlan Hunt wrote: > Sean Hogan wrote: >> >> I think a couple of those features are pretty low priority: >> >> - I don't see the point of collective queries on NodeLists. >> Are there any references for the proposal? >> Otherwise I can't think of any useful querie

Re: [selectors-api] Summary of Feature Requests for v2

2009-09-25 Thread Boris Zbarsky
On 9/25/09 1:35 AM, Garrett Smith wrote: No, you did not say it is slow. I'm saying that your laptop is probably a lot more powerful than a mobile device with a browser, such as Blackberry9000. Do you agree with that? Sure. It's a pretty self-evidently true claim. that said, note that on a m

Re: [selectors-api] Summary of Feature Requests for v2

2009-09-24 Thread Garrett Smith
On Thu, Sep 24, 2009 at 11:38 AM, Boris Zbarsky wrote: > On 9/24/09 2:17 PM, Garrett Smith wrote: >> >> On Thu, Sep 24, 2009 at 6:06 AM, Boris Zbarsky  wrote: >>> >>> Gecko doesn't.  Webkit doesn't. >>> >>> I just checked really quickly, and on my machine (a year-plus old laptop) >> >> That is pro

Re: [selectors-api] Summary of Feature Requests for v2

2009-09-24 Thread Sean Hogan
Boris Zbarsky wrote: On 9/24/09 6:45 PM, Sean Hogan wrote: That is surprising. Does the CSS engine do the same? If the CSS engine doesn't store the parsed selector then it probably doesn't matter for JS calls either. In Gecko the CSS engine stores the parsed selector. In addition, it stores

Re: [selectors-api] Summary of Feature Requests for v2

2009-09-24 Thread Boris Zbarsky
On 9/24/09 6:45 PM, Sean Hogan wrote: That is surprising. Does the CSS engine do the same? If the CSS engine doesn't store the parsed selector then it probably doesn't matter for JS calls either. In Gecko the CSS engine stores the parsed selector. In addition, it stores the selectors in vario

Re: [selectors-api] Summary of Feature Requests for v2

2009-09-24 Thread Sean Hogan
Lachlan Hunt wrote: Mike Wilson wrote: My first priority would be "Matches Selector", and see to that it fulfills the needs for event delegation. Is there any special functionality that would be needed to achieve this? If I understand correctly, event delegation just needs to be able to che

Re: [selectors-api] Summary of Feature Requests for v2

2009-09-24 Thread Sean Hogan
Boris Zbarsky wrote: On 9/24/09 6:29 AM, Sean Hogan wrote: I would be surprised if an implementation didn't create an internal lookup table keyed off the selector text. Gecko doesn't. Webkit doesn't. I just checked really quickly, and on my machine (a year-plus old laptop) parsing the ".foo

Re: [selectors-api] Summary of Feature Requests for v2

2009-09-24 Thread Jonas Sicking
On Thu, Sep 24, 2009 at 2:41 PM, Jonas Sicking wrote: >>> > If this is how it's implemented it actually becomes really useful to >>> > have >>> > the NodeList-based element filtering. >>> > >>> >     document.createNodeList([ ... some elements ... >>> > ]).filterSelector("em, >>> > strong") >>> >

Re: [selectors-api] Summary of Feature Requests for v2

2009-09-24 Thread Jonas Sicking
On Thu, Sep 24, 2009 at 2:09 PM, John Resig wrote: > >> My concern with this API is that it forces the implementation to >> always sort the array, even if already sorted, and then do a merge >> sort on the individual results from querySelectorAll. It would be >> faster to simply run the query on e

Re: [selectors-api] Summary of Feature Requests for v2

2009-09-24 Thread Boris Zbarsky
On 9/24/09 5:09 PM, John Resig wrote: It's only if it's an array that we have to do the dance. Even in the case where the array of results is already in document order the sort will be incredibly fast (O(N)). O(N) in number of nodes in the array, and that assumes that the array is not being so

Re: [selectors-api] Summary of Feature Requests for v2

2009-09-24 Thread John Resig
> My concern with this API is that it forces the implementation to > always sort the array, even if already sorted, and then do a merge > sort on the individual results from querySelectorAll. It would be > faster to simply run the query on each node, and then merge sort the > results. > That's not

Re: [selectors-api] Summary of Feature Requests for v2

2009-09-24 Thread Jonas Sicking
On Thu, Sep 24, 2009 at 8:59 AM, John Resig wrote: > Another alternative > would be to implement the merge/sort/unique method and have it return a > NodeList (which would, then, have qSA). > > For example: >     document.createNodeList([ ... some elements ... ]).querySelectorAll("em, > strong"); >

Re: [selectors-api] Summary of Feature Requests for v2

2009-09-24 Thread Jonas Sicking
On Thu, Sep 24, 2009 at 11:21 AM, Lachlan Hunt wrote: >>> It would be great to have a separate, standalone, function that handles these merge/sort/unique operations for collections of DOM elements (especially if they're disconnected from the document!). >>> The proposal from my

Re: [selectors-api] Summary of Feature Requests for v2

2009-09-24 Thread Sam Weinig
On Sep 24, 2009, at 11:39 AM, Boris Zbarsky wrote: On 9/24/09 2:36 PM, Sam Weinig wrote: WebKit now also has an implementation of Element.matchesSelector() (we are calling ours webkitMatchesSelector for the time being). [https://bugs.webkit.org/show_bug.cgi?id=29703] Right. The Gecko one

Re: [selectors-api] Summary of Feature Requests for v2

2009-09-24 Thread John Resig
> Not quite. It depends what's being done and which steps need to be > performed and how. AIUI, there are 3 major steps involved here. > > 1. Obtain a collection of Elements. This could be in one or more > Arrays and/or NodeLists, depending on th. > 2. Iteratively execute a selector query on al

Re: [selectors-api] Summary of Feature Requests for v2

2009-09-24 Thread Boris Zbarsky
On 9/24/09 2:36 PM, Sam Weinig wrote: WebKit now also has an implementation of Element.matchesSelector() (we are calling ours webkitMatchesSelector for the time being). [https://bugs.webkit.org/show_bug.cgi?id=29703] Right. The Gecko one is mozMatchesSelector. I bet we'd both love to rename i

Re: [selectors-api] Summary of Feature Requests for v2

2009-09-24 Thread Boris Zbarsky
On 9/24/09 2:17 PM, Garrett Smith wrote: On Thu, Sep 24, 2009 at 6:06 AM, Boris Zbarsky wrote: Gecko doesn't. Webkit doesn't. I just checked really quickly, and on my machine (a year-plus old laptop) That is probably many times faster, and can probably be much more liberal, than an optimize

Re: [selectors-api] Summary of Feature Requests for v2

2009-09-24 Thread Sam Weinig
On Sep 23, 2009, at 8:37 PM, Jonas Sicking wrote: On Wed, Sep 23, 2009 at 8:17 PM, John Resig wrote: Quick Summary of my opinions: Matches Selector: Super-super useful - critical, in fact. We're not able to remove jQuery's selector engine until this is implemented. I'm working with the d

Re: [selectors-api] Summary of Feature Requests for v2

2009-09-24 Thread Garrett Smith
On Thu, Sep 24, 2009 at 6:06 AM, Boris Zbarsky wrote: > On 9/24/09 6:29 AM, Sean Hogan wrote: >> >> I would be surprised if an implementation didn't create an internal >> lookup table keyed off the selector text. > > Gecko doesn't.  Webkit doesn't. > > I just checked really quickly, and on my mach

Re: [selectors-api] Summary of Feature Requests for v2

2009-09-24 Thread Lachlan Hunt
John Resig wrote: So the question is, at which point in the chain do you want to address this issue? The options are: A) Have specific selectors API feauture that allowed executing a selector query on a whole collection of elements that returns a single, sorted collection of unique elem

Re: [selectors-api] Summary of Feature Requests for v2

2009-09-24 Thread John Resig
> > So the question is, at which point in the chain do you want to address > this issue? The options are: > > A) Have specific selectors API feauture that allowed executing a > selector query on a whole collection of elements that returns a > single, sorted collection of unique elements. > >

Re: [selectors-api] Summary of Feature Requests for v2

2009-09-24 Thread Lachlan Hunt
Sean Hogan wrote: http://krijnhoetmer.nl/irc-logs/whatwg/20090922#l- I couldn't see where it was needed, only that it was possible in jQuery. I still can't think of any NodeLists that this could usefully be applied to that couldn't be achieved with a single querySelectorAll(). At least unti

Re: [selectors-api] Summary of Feature Requests for v2

2009-09-24 Thread Lachlan Hunt
John Resig wrote: Filtering NodeLists/StaticNodeLists, Queries on NodeLists/StaticNodeLists: Neither of these are useful, as is, to libraries. I believe this would be handled using the Array.filter() method, with a callback that checks if the selector matches the element, as Jonas pointed out:

Re: [selectors-api] Summary of Feature Requests for v2

2009-09-24 Thread John Resig
> Filtering NodeLists/StaticNodeLists, Queries on NodeLists/StaticNodeLists: >> Neither of these are useful, as is, to libraries. What is actually useful >> is >> the ability to run these against an array (or array-like collection) of >> DOM >> nodes. >> > > I believe this would be handled using th

Re: [selectors-api] Summary of Feature Requests for v2

2009-09-24 Thread Boris Zbarsky
On 9/24/09 6:29 AM, Sean Hogan wrote: I would be surprised if an implementation didn't create an internal lookup table keyed off the selector text. Gecko doesn't. Webkit doesn't. I just checked really quickly, and on my machine (a year-plus old laptop) parsing the ".foo .bar .baz" selector a

Re: [selectors-api] Summary of Feature Requests for v2

2009-09-24 Thread Sean Hogan
Lachlan Hunt wrote: Lachlan Hunt wrote: Sean Hogan wrote: I think a couple of those features are pretty low priority: - I don't see the point of collective queries on NodeLists. Are there any references for the proposal? Otherwise I can't think of any useful queries that can't already be achie

Re: [selectors-api] Summary of Feature Requests for v2

2009-09-24 Thread Sean Hogan
Garrett Smith wrote: On Thu, Sep 24, 2009 at 12:02 AM, Mike Wilson wrote: Yes, the base for event delegation is certainly something like that. I just wanted to make clear that the main reason for adding this functionality (IMO) is event delegation. I'll let event delegation library creators

Re: [selectors-api] Summary of Feature Requests for v2

2009-09-24 Thread Lachlan Hunt
Garrett Smith wrote: QuerySelector could be extended to have properties: readonly attribute boolean valid StaticNodeList match(in HTMLElement contextNode) What's the valid property for? It seems redundant. If the selector isn't valid, then the factory method should throw an error when

Re: [selectors-api] Summary of Feature Requests for v2

2009-09-24 Thread Lachlan Hunt
Lachlan Hunt wrote: Sean Hogan wrote: I think a couple of those features are pretty low priority: - I don't see the point of collective queries on NodeLists. Are there any references for the proposal? Otherwise I can't think of any useful queries that can't already be achieved with a single que

Re: [selectors-api] Summary of Feature Requests for v2

2009-09-24 Thread Garrett Smith
On Thu, Sep 24, 2009 at 12:02 AM, Mike Wilson wrote: > Yes, the base for event delegation is certainly something > like that. I just wanted to make clear that the main reason > for adding this functionality (IMO) is event delegation. > I'll let event delegation library creators chime in on the > d

Re: [selectors-api] Summary of Feature Requests for v2

2009-09-24 Thread Lachlan Hunt
Sean Hogan wrote: I think a couple of those features are pretty low priority: - I don't see the point of collective queries on NodeLists. Are there any references for the proposal? Otherwise I can't think of any useful queries that can't already be achieved with a single querySelectorAll(). It

RE: [selectors-api] Summary of Feature Requests for v2

2009-09-24 Thread Mike Wilson
Yes, the base for event delegation is certainly something like that. I just wanted to make clear that the main reason for adding this functionality (IMO) is event delegation. I'll let event delegation library creators chime in on the details on what is needed for making really efficient behavioural

Re: [selectors-api] Summary of Feature Requests for v2

2009-09-23 Thread Jonas Sicking
On Wed, Sep 23, 2009 at 9:57 PM, Maciej Stachowiak wrote: > > On Sep 23, 2009, at 5:26 PM, Jonas Sicking wrote: > >> On Wed, Sep 23, 2009 at 4:51 AM, Lachlan Hunt >> wrote: >>> >>> *Scoped Queries* >>> http://www.w3.org/Bugs/Public/show_bug.cgi?id=5860 >>> >>> This has been discussed extensively

Re: [selectors-api] Summary of Feature Requests for v2

2009-09-23 Thread Maciej Stachowiak
On Sep 23, 2009, at 5:26 PM, Jonas Sicking wrote: On Wed, Sep 23, 2009 at 4:51 AM, Lachlan Hunt > wrote: *Scoped Queries* http://www.w3.org/Bugs/Public/show_bug.cgi?id=5860 This has been discussed extensively in the past. Basically, the idea is that the selector would be evaluated in the sc

Re: [selectors-api] Summary of Feature Requests for v2

2009-09-23 Thread Jonas Sicking
On Wed, Sep 23, 2009 at 8:17 PM, John Resig wrote: > Quick Summary of my opinions: > > Matches Selector: Super-super useful - critical, in fact. We're not able to > remove jQuery's selector engine until this is implemented. I'm working with > the devs at Mozilla to get an implementation landed. Al

Re: [selectors-api] Summary of Feature Requests for v2

2009-09-23 Thread John Resig
Quick Summary of my opinions: Matches Selector: Super-super useful - critical, in fact. We're not able to remove jQuery's selector engine until this is implemented. I'm working with the devs at Mozilla to get an implementation landed. Already have a test suite in place. Filtering NodeLists/Static

Re: [selectors-api] Summary of Feature Requests for v2

2009-09-23 Thread Garrett Smith
On Wed, Sep 23, 2009 at 4:51 AM, Lachlan Hunt wrote: > Hi, >  I'm planning to look at beginning work on Selectors API v2 soon to add a > number of requested features that didn't make it into the first version. >  This e-mail is a summary of what is being considered, and is intended to > start disc

Re: [selectors-api] Summary of Feature Requests for v2

2009-09-23 Thread Sean Hogan
I think a couple of those features are pretty low priority: - I don't see the point of collective queries on NodeLists. Are there any references for the proposal? Otherwise I can't think of any useful queries that can't already be achieved with a single querySelectorAll(). - Filtering NodeList

Re: [selectors-api] Summary of Feature Requests for v2

2009-09-23 Thread Jonas Sicking
On Wed, Sep 23, 2009 at 4:51 AM, Lachlan Hunt wrote: > *Scoped Queries* > http://www.w3.org/Bugs/Public/show_bug.cgi?id=5860 > > This has been discussed extensively in the past.  Basically, the idea is > that the selector would be evaluated in the scope of the element, in a way > more compatible w

Re: [selectors-api] Summary of Feature Requests for v2

2009-09-23 Thread Lachlan Hunt
Mike Wilson wrote: My first priority would be "Matches Selector", and see to that it fulfills the needs for event delegation. Is there any special functionality that would be needed to achieve this? If I understand correctly, event delegation just needs to be able to check whether the event

RE: [selectors-api] Summary of Feature Requests for v2

2009-09-23 Thread Mike Wilson
My first priority would be "Matches Selector", and see to that it fulfills the needs for event delegation. Best regards Mike Wilson Lachlan Hunt wrote: > Hi, >I'm planning to look at beginning work on Selectors API v2 soon to > add a number of requested features that didn't make it into the