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
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
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
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
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
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
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
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
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
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
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
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")
>>> >
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
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
> 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
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");
>
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
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
> 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
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
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
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
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
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
>
> 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.
>
>
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
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:
> 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
45 matches
Mail list logo