Side navigation
#9316 closed feature (wontfix)
Opened May 17, 2011 03:28PM UTC
Closed June 06, 2011 06:49PM UTC
Make .delegate(null, 'type', fnHandler) behave like .bind('type', fnHandler)
| Reported by: | maranomynet | Owned by: | |
|---|---|---|---|
| Priority: | low | Milestone: | 1.7 |
| Component: | event | Version: | |
| Keywords: | Cc: | ||
| Blocked by: | Blocking: |
Description
There are circumstances where it would be incredibly handy if jQuery.fn.delegate would handle the special case of an empty/falsy selector parameter, and interpret it as a direct .bind() request on the collection.
The current behavior in jQuery happens to be almost like that, except that when the collection object is missing a selector property things start failing. I suspect there's some sort of a fallback on .live() going on - and causing those unpredictable results.
Adding this as a feature shouldn't add too much bloat to the core library, and would IMHO adhere to the principle of least surprise.
Attachments (0)
Change History (13)
Changed May 17, 2011 04:43PM UTC by comment:1
| component: | unfiled → event |
|---|---|
| status: | new → open |
Changed May 22, 2011 07:27PM UTC by comment:2
| keywords: | → 1.7-discuss |
|---|
Nominating ticket for 1.7 discussion.
Changed May 22, 2011 08:40PM UTC by comment:3
| description: | There are circumstances where it would be incredibly handy if `jQuery.fn.delegate` would handle the special case of an empty/falsy selector parameter, and interpret it as a direct `.bind()` request on the collection. \ \ The current behavior in jQuery happens to be almost like that, except that when the collection object is missing a `selector` property things start failing. I suspect there's some sort of a fallback on `.live()` going on - and causing those unpredictable results. \ \ Adding this as a feature shouldn't add too much bloat to the core library, and would IMHO adhere to the principle of least surprise. → There are circumstances where it would be incredibly handy if `jQuery.fn.delegate` would handle the special case of an empty/falsy selector parameter, and interpret it as a direct `.bind()` request on the collection.\ \ The current behavior in jQuery happens to be almost like that, except that when the collection object is missing a `selector` property things start failing. I suspect there's some sort of a fallback on `.live()` going on - and causing those unpredictable results.\ \ Adding this as a feature shouldn't add too much bloat to the core library, and would IMHO adhere to the principle of least surprise. |
|---|
+1, Falls under #9393
Changed May 23, 2011 12:54AM UTC by comment:4
-1, I dunno, seems to me like a very edgy case.
Changed May 23, 2011 04:57AM UTC by comment:5
-1, I'd prefer the other way around, and make .on() an alias for bind.
Changed May 23, 2011 10:10AM UTC by comment:6
I'd like to explain the events that lead to my filing this ticket.
I have a plugin that binds events to a container element. The plugin also accepts a target subselector option to limit the events to just certain elements.
My initial assumption was that passing an empty/null selector to .delegate would act just like .bind. So I tried it:
this.delegate( options.targets||'', 'click', handlerFunc );
...and everything worked perfectly just as I had assumed.
Then after a few weeks of happy use things started to randomly fail, it seemed. After a long and confusing debugging session I finally figured out that the cause was a seemingly aribtary lack of .selector property on the collection.
The following is the code I ended up reverting back to:
if ( options.targets ) {
this.delegate( options.targets, 'click', handlerFunc );
} else {
this.bind( 'click', handlerFunc );
}
...and it seems a lot less elegant than the original version.
Changed May 23, 2011 01:28PM UTC by comment:7
| description: | There are circumstances where it would be incredibly handy if `jQuery.fn.delegate` would handle the special case of an empty/falsy selector parameter, and interpret it as a direct `.bind()` request on the collection.\ \ The current behavior in jQuery happens to be almost like that, except that when the collection object is missing a `selector` property things start failing. I suspect there's some sort of a fallback on `.live()` going on - and causing those unpredictable results.\ \ Adding this as a feature shouldn't add too much bloat to the core library, and would IMHO adhere to the principle of least surprise. → There are circumstances where it would be incredibly handy if `jQuery.fn.delegate` would handle the special case of an empty/falsy selector parameter, and interpret it as a direct `.bind()` request on the collection. \ \ The current behavior in jQuery happens to be almost like that, except that when the collection object is missing a `selector` property things start failing. I suspect there's some sort of a fallback on `.live()` going on - and causing those unpredictable results. \ \ Adding this as a feature shouldn't add too much bloat to the core library, and would IMHO adhere to the principle of least surprise. |
|---|
I think this ticket should be closed in favor of #9393
Changed June 03, 2011 02:04PM UTC by comment:8
| description: | There are circumstances where it would be incredibly handy if `jQuery.fn.delegate` would handle the special case of an empty/falsy selector parameter, and interpret it as a direct `.bind()` request on the collection. \ \ The current behavior in jQuery happens to be almost like that, except that when the collection object is missing a `selector` property things start failing. I suspect there's some sort of a fallback on `.live()` going on - and causing those unpredictable results. \ \ Adding this as a feature shouldn't add too much bloat to the core library, and would IMHO adhere to the principle of least surprise. → There are circumstances where it would be incredibly handy if `jQuery.fn.delegate` would handle the special case of an empty/falsy selector parameter, and interpret it as a direct `.bind()` request on the collection.\ \ The current behavior in jQuery happens to be almost like that, except that when the collection object is missing a `selector` property things start failing. I suspect there's some sort of a fallback on `.live()` going on - and causing those unpredictable results.\ \ Adding this as a feature shouldn't add too much bloat to the core library, and would IMHO adhere to the principle of least surprise. |
|---|
-1, Ehh, why not just do that logic in your code?
Changed June 03, 2011 03:48PM UTC by comment:9
The point is: The feature is already there. Everything seems to work beautifully - but then it breaks down under specific rare (and seemingly random) circumstances.
Changed June 04, 2011 10:16PM UTC by comment:10
+1
Changed June 05, 2011 10:12PM UTC by comment:11
| description: | There are circumstances where it would be incredibly handy if `jQuery.fn.delegate` would handle the special case of an empty/falsy selector parameter, and interpret it as a direct `.bind()` request on the collection.\ \ The current behavior in jQuery happens to be almost like that, except that when the collection object is missing a `selector` property things start failing. I suspect there's some sort of a fallback on `.live()` going on - and causing those unpredictable results.\ \ Adding this as a feature shouldn't add too much bloat to the core library, and would IMHO adhere to the principle of least surprise. → There are circumstances where it would be incredibly handy if `jQuery.fn.delegate` would handle the special case of an empty/falsy selector parameter, and interpret it as a direct `.bind()` request on the collection. \ \ The current behavior in jQuery happens to be almost like that, except that when the collection object is missing a `selector` property things start failing. I suspect there's some sort of a fallback on `.live()` going on - and causing those unpredictable results. \ \ Adding this as a feature shouldn't add too much bloat to the core library, and would IMHO adhere to the principle of least surprise. |
|---|
-1, There are a number of cases in jQuery where dynamically building parameters to send to jQuery functions works ALMOST all the time, but due to some kind of data exception, undefined ends up getting passed and jQuery behaves unexpectedly. (undefined as context or the second argument to attr, for instance). Historically, we have not special cased these situations, and I don't think we should start now, especially given the .on enhancement that will handle this problem generically.
Changed June 06, 2011 03:13PM UTC by comment:12
| description: | There are circumstances where it would be incredibly handy if `jQuery.fn.delegate` would handle the special case of an empty/falsy selector parameter, and interpret it as a direct `.bind()` request on the collection. \ \ The current behavior in jQuery happens to be almost like that, except that when the collection object is missing a `selector` property things start failing. I suspect there's some sort of a fallback on `.live()` going on - and causing those unpredictable results. \ \ Adding this as a feature shouldn't add too much bloat to the core library, and would IMHO adhere to the principle of least surprise. → There are circumstances where it would be incredibly handy if `jQuery.fn.delegate` would handle the special case of an empty/falsy selector parameter, and interpret it as a direct `.bind()` request on the collection.\ \ The current behavior in jQuery happens to be almost like that, except that when the collection object is missing a `selector` property things start failing. I suspect there's some sort of a fallback on `.live()` going on - and causing those unpredictable results.\ \ Adding this as a feature shouldn't add too much bloat to the core library, and would IMHO adhere to the principle of least surprise. |
|---|
-1
Changed June 06, 2011 06:49PM UTC by comment:13
| description: | There are circumstances where it would be incredibly handy if `jQuery.fn.delegate` would handle the special case of an empty/falsy selector parameter, and interpret it as a direct `.bind()` request on the collection.\ \ The current behavior in jQuery happens to be almost like that, except that when the collection object is missing a `selector` property things start failing. I suspect there's some sort of a fallback on `.live()` going on - and causing those unpredictable results.\ \ Adding this as a feature shouldn't add too much bloat to the core library, and would IMHO adhere to the principle of least surprise. → There are circumstances where it would be incredibly handy if `jQuery.fn.delegate` would handle the special case of an empty/falsy selector parameter, and interpret it as a direct `.bind()` request on the collection. \ \ The current behavior in jQuery happens to be almost like that, except that when the collection object is missing a `selector` property things start failing. I suspect there's some sort of a fallback on `.live()` going on - and causing those unpredictable results. \ \ Adding this as a feature shouldn't add too much bloat to the core library, and would IMHO adhere to the principle of least surprise. |
|---|---|
| keywords: | 1.7-discuss |
| milestone: | 1.next → 1.7 |
| priority: | undecided → low |
| resolution: | → wontfix |
| status: | open → closed |
This will be dealt with in #9393
This will fall under the pending 1.7 event DRY out proposal