Oops, meant #6011, not #6042.

It may be usable but no, it's not part of jQuery core yet. I want to make sure that we work out the exact API before moving further - so I don't know exactly what release it'll land in, yet.

@jeresig can you update us on the status of this? Is it usable in this branch and what post-1.4 release can we expect to see it in? Thanks!!!

Forgot to thank Justin Meyer for his live namespaced tests - thanks Justin!

oh, good luck getting paid in that case. hahaha

Waaaayy ahead of you:
http://code.google.com/p/chromium/issues/detail?id=883

Been open for over 2 years at this point.

should file a Chrome bug and get paid : )

Great!

Yes. As you'll note, delegate just uses live - therefore it supports everything that live supports.

We now have two ways to do event delegation in jQuery.
One uses the good old jQuery syntax we all know but seems somewhat magical before you know how event delegation works.
The other requires a good understanding of event delegation but seems much better from a performance point of view.

Is delegate already compatible with mouseenter/mouseleave, change, submit and focus/blur?

Oops, didn't mean to leave that nodeName check in - removed in 8a4b210.

John, I completely agree to remove setArray, but maybe jQuery.fn.init is more appropriate to integrate that.

@rkatic: As a public-facing API setArray simply doesn't make sense (and it never has been an API that we've wanted to expose). It's a destructive operation which is completely against the rest of the jQuery API. Moving it into pushStack is really better all around.

(Uf, I wrote jQuery.setArray instead of jQuery.fn.seArray. I have to sleep.)

the only place jQuery(array) is used is within pushStack

I know, but pushStack is heavily used. Had to be more clear telling that jQuery(array) is frequently evaluated.

I am not completely convinced about incorporating setArray into pushStack.
Internally, currently, pushStack is the only one that uses jQuery(array), but what about plugins? What about adding jQuery.fromArray then.

Ah, I got carried away. Although, name "pushStack()" dramaticaly improves the readability of the API. It clearly reveals the intent and the reason of existence of the method... I would like to see (much) more of that kind of activity, while moving towards 1.5

The Official jQuery Podcast – Episode 9 – David Artz, Aol.also reveals , what my little contribution (from few months ago) tried to explain too : not everyone is jQuery expert. Managing a large(ish) teams and/or Web 2.0 companies, becomes a nightmare, because of power and flexibility of jQuery. Which often produces a lot of headaches when "given" to those big teams developing and/or supporting large portals.

They rarely bother with api documentation, usually not before the whole mountain of javascript code starts disolving, because of code like : $("*").click() ...

All API ambiguity must be weeded-out, as much as possible ...

--DBJ

No, that's not what I said. I use want to remove jQuery.fn.setArray as it's no longer needed - it can be incorporated into jQuery.fn.pushStack.

@John, I wellcome anyhting that untangles jQuery() , "multifunctional" single function interface. That is If, I understood properly you want to deprecarte jQuery( array ) ...

@rkatic: Actually, that's not entirely true - the only place jQuery(array) is used is within pushStack - that can easily be rewritten to use the faster code path - and if it's being removed then it makes a lot of sense to deprecate/remove it as well (people should be using pushStack anyway).

@John

'jQuery.setArray' is still significantly faster then 'jQuery.makeArray', and although it is not strictly necessary, 'jQuery(aArray)' is still heavily used internally. Is this change motivated by the intention to deprecate/remove 'jQuery.setArray'? It is not used any more.
If so, then I would suggest to integrate 'jQuery.setArray' inside 'jQuery.makeArray' or inside 'jQuery.merge or even better inside' 'jQuery'.

My name is not DBJDBJ, either ...