jQuery Forum

First off all I would precise that I am a huge fan of .on/off() as much better names then .bind/unbind() (shorter and less confusion with func.bind()).

Also I applause the decision to deprecate .live/die() for too many reasons...

However, I am not that excited for also making .on/off() the substitution for .delegate/undelegate().
I think it could raise too many readability issues, and I would like to expose some of those.

Consider this example:

1. $("#foo").delegate(".boo", "click", function( event ) {
2.   blablabla( filililula, hahaha );
3. });
4. 
   
5. $("#foo").on("click", ".boo", function( event ) {
6.   blablabla( filililula, hahaha );
7. });
8. 
   
9. $("#foo").on("click", function( event ) {
10.   blablabla( filililula, hahaha );
11. });

Using .delegate() it is immediately clear that we are doing some event delegation, while using .on(), the reader have to spot, not the first, but the second argument to conclude the same thing.

Also, in my opinion, .delegate() has much better arguments order. Having the selector as first argument is not only more logical reading the entire line from left to right, but also provides much clear/structured delegation using map of events:

1. $("#foo").delegate(".boo", {
2.   "click": function( event ) {
3.       blablabla( filililula, hahaha );
4.   },
5.   "hover": function( event ) {
6.       blablabla( filililula, hahaha );
7.   }
8. );
9. 
   
10. $("#foo").on({
11.   "click": function( event ) {
12.       blablabla( filililula, hahaha );
13.   },
14.   "hover": function( event ) {
15.       blablabla( filililula, hahaha );
16.   }},
17.   ".boo"
18. );

Using .delegate() it is clear form the first line on which elements two handlers will be applied, while using .on(), the reader have to scroll at the very end to only realize that it is delegation and not simple binding.

At the end, .on() is shorter then .delegate(), but it makes code less readable when used for event delegation, making our code harder to maintain.

Maybe it is too late, but I would still ask you to consider to un-deprecate .delegate/undelegate() and to deprecate .on/off() for event delegation instead.

Am I crazy? Am I missing something? :)

Now that jQuery.makeArray(nodeList) is supported correctly, maybe it
is wanted to make that also for jQuery.each, jQuery.map and
jQuery.grep.
There are mainly two reasons why I think it is worth of consideration:
1. $.each(nodeList) is already possible and I suppose that there are
individuals that are considering that action legal because NodeLists
are array like things too. Unfortunately it is not always true in IE
and Opera where length expando can be overwrited.
2. Using $.each, $.map and $.grep directly with NodeLists can be still
useful, not only for optimizing jQuery itself.
I made a patch that would fix this
http://github.com/rkatic/jquery/commit/7203092c23d5ddb623495f9145d2dab3edf1c529
If this change is welcome, than I will open a ticket...
--

Wat a hell is going here?
// Recurse if we're merging object values
if ( deep && copy && typeof copy === "object" && !copy.nodeType ) {
var clone;
if ( src ) {
clone = src;
} else if ( jQuery.isArray(copy) ) {
clone = [];
} else if ( jQuery.isObject(copy) ) {
clone = {};
} else {
clone = copy;
}
// Never move original objects, clone them
target[ name ] = jQuery.extend( deep, clone, copy );
You are going to extend with any object including a Date, a String, a
Number... (ah yes, excluding nodes).
You are going to extend (with) arrays? [1,2] and [4] to obtain [4,2].
Really?
If an object is not an array nor an object literal then extend object
with itself???
The only things to extend recursively are objects literals to me:
if ( deep && copy && jQuery.isObject(copy) && (!src || jQuery.isObject
(src)) ) {
target[ name ] = jQuery.extend( deep, src || {}, copy );
}
Am I loosing my mind? :)
--

Using $.fn.add(selector) the context property remains the same.
It's ok, but the given selector will be applied always with the
default context (document).
This is not correct for me if we are using jQuery with xml documents
for example.
$("user", xmlDoc).add("lusers");
There is no way to add lusers of the xmlDoc document!
Here an optional context argument would be useful:
$("user", xmlDoc).add("lusers", xmlDoc);
But even this is not ideal for me. If the context argument is not
given (first example), which document would be used?
I suppose the obvious answer is xmlDoc.
An corrected implementation of add() would be something like this:
jQuery.fn.add = function( selector ) {
return this.pushStack( jQuery.unique( jQuery.merge(
this.get(),
typeof selector === "string" ?
jQuery( selector, (this.context || this[0] ||
0).ownerDocument ) :
jQuery.makeArray( selector )
)));
};
--

I suppose it is rear to use multiple namespaces to unbind an event and
that it is the reason why no one spotted this bug (I spotted it by
examining code, not by using the feature).
This is the problem:
$("div").bind("click.aaa.bbb", function(){...});
$("div").unbind("click.a.bbb"); //this is unbinding the previous
bind!!!
Now someone would suppose: "Well it seams fine, there is .bbb so it
will unbind click.aaa.bbb too", but it is not true:
$("div").unbind("click.bbb.other") // will not unbind click.aaa.bbb
The problem seams to be the generated regexp into event.remove() and
event.handle():
var namespace = RegExp("(^|\\.)" + namespaces.slice().sort().join(".*\
\.") + "(\\.|$)");
that for me would be:
var namespace = RegExp("(^|\\.)" + namespaces.slice().sort().join("\\.
(?:.*\\.)?") + "(\\.|$)");
Am I missing something here?
Here is a test-case http://jsbin.com/aledo
And here is the same case with the corrected event.remove() function:
http://jsbin.com/eqofo
(I hope jsbin.com has no problems any more)
Will I open a ticket?

I suppose it is rear to use multiple namespaces to unbind an event and
that it is the reason why no one spotted this bug (I spotted it by
examining code, not by using the feature).
This is the problem:
$("div").bind("click.aaa.bbb", function(){...});
$("div").unbind("click.a.bbb"); //this is unbinding the previous
bind!!!
Here is a test-case http://jsbin.com/aledo
And here is the same case with the corrected even.remove() function:
http://jsbin.com/eqofo
(I hope jsbin.com has no more problems)
Will I open a ticket?

After some readings on the "A Modest Proposal: jQuery Enterprise"
discussion at http://groups.google.com/group/jquery-dev/browse_frm/thread/1ec4dca6e02616d6#,
it is clear that jQuery needs an own widget system that will expose an
standard way to write widgets/plugins. This need is more evident on
larger projects. JQuery UI implements an own.
Some ideas:
jQuery UI: http://jquery-ui.googlecode.com/svn/trunk/ui/ui.core.js
John: http://dev.jquery.com/~john/plugins/widget/widget.js
my try with inheritance: http://bender.fesb.hr/~robert/jquery.plugin.js
Thoughts?

The querySelectorAll returns elements in documents order, but Sizzle
(for now?) treat each selector separately.
Maybe this can be easily resolved joining each result array in one
with nodes in documents order?
If so, maybe something like this would help (not tested). Or you are
thinking to sort results all together?
var precedes = ( document.documentElement.sourceIndex == 0 ) &&
function( a, b ) {
return a.sourceIndex < b.sourceIndex;
}
|| ( document.documentElement.compareDocumentPosition ) &&
function( a, b ) {
return !!( a.compareDocumentPosition(b) & 4 );
}
|| function( a, b ) {
if ( a === b || b.contains(a) )
return false
if ( a.contains(b) )
return true;
var c = a.parentNode;
while ( !c.contains(b) ) {
a = c;
c = c.parentNode;
}
var p = b.parentNode;
while ( p !== c ) {
b = p;
p = p.parentNode;
}
var nodes = c.childNodes;
for ( var i = 0, node = nodes[0]; node; node = nodes[+
+i] ) {
if ( node === a )
return true;
if ( node === b )
return false;
}
return false;
};
function joinResultsHelper( res, a, i, b, j ) {
if ( b[j] ) {
for ( var l = a.length; i < l; ++i ) {
if ( a[i] === b[j] )
++j;
else if ( precedes(a[i], b[j]) )
res.push( a[i] );
else {
res.push( b[j++] );
joinResultsHelper( res, b, j, a, i );
break;
}
}
} else {
for ( var l = a.length; i < l; ++i )
res.push( a[i] );
}
return res;
}
function joinResults( a, b ) {
if ( a.length === 0 )
return b;
if ( b.length === 0 )
return a;
return joinResultsHelper( [], a, 0, b, 0 );
}

My English is not so good so will be short.
I am not sure why the get() function exists. Because it is shorter
then toArray()? But my code would by more clear with an toArray
instead, An foo.get(index) is not clearer nor shorter then foo[index]
for me.
In my opinion the "get" function is not really necessary and would by
deprecated if an more explicit toArray would exists.
The implementation of toArray() would be banal:
jQuery.fn.toArray = function() { return Array.prototype.slice.apply
(this, arguments) };
or even:
jQuery.fn.toArray = Array.prototype.slice;
Thoughts? Am I disregarding something here?