[jquery-dev] Clear ASP.Net label control using Jquery...
I have a asp.net label control . The label is inside the control Panel and the page also has a master page. The label ID is lbErrorList. The label gets rendered as "ctl00_ctl00_SubApp1_SubContent_lbErrorList" The page also contains many textbox which needs to be populated by user. I am trying to check if the user has filled all the textbox. If the user does not fill the text box , the user needs to be notified by adding corresponding error to the lbErrorList. I am trying to append the error messages to label as $("#ctl00_ctl00_SubApp1_SubContent_lbErrorList").append(errorList); // errorList is a temporary variable which has the error information. problem is the label gets appended with error list content every time I try to submit the form and if the validation goes wrong. I would like to clear the label whenever the submit button is clicked, so that if error happens then only needed error messages is displayed. How can I archive this...?? In brief my question is how can I clear the lbErrorList using jquery...??? Thanks in advance... -- You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: Making backgroud inactive and blur when a popup panel loads
Here is the solution.. 1. Take 2 DIV containers name them (for example) as OuterDIV and InnerDIV. InnderDIV inside OuterDIV. 2. Assign class OuterDivClass to OuterDIV . 3. Assign class InnerDivClass to InnerDIV. Observe that when OuterDIV gets displayed it occupies complete screen due to height and width set to 100%. For your project put the Panel withing InnerDIV. Adjust the InnderDiv height and width according to panel. Don't forget include InnerDIV within OuterDIV. It should work. .InnerDivClass { background-color: #E6E6FF; border-style: outset; display:none; width: 400px; height: 300px; top: 25%; left: 35%; position: relative; } .OuterDIVClass { font-family: arial,helvetica,clean,sans-serif; font-size: small; display: block; position: fixed; opacity: 0.75; filter: alpha(opacity=95); height: 100%; width: 100%; background-color: #33; top: 0%; left: 0%; } Good luck... On Nov 4, 5:52 am, Priya wrote: > Hello, > > In my project,i am handling popup messages through the asp panel and > div controls.when that popup comes by clicking a button say btnsend, > the background ie the page should become inactive,no button click or > any other functionality should not be done.. > > The popup panel's css class is popupcurve > > .popupcurve > { > width:45%; > > color: #00 !important; > border: 15px solid #cecdbb; > background-color: #FF; > position: fixed !important; > top: 40%; > left: 25%; > z-index: 105; > > } > > The page is like this > > > Visible="false"> > > > > > > > > > > > > > > Please help me -- You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: Will the live() method be improved in 1.4?
I've also been among those clamoring for an optimized $.live method and have a offered similar hack around in the past (via Paul Irish's Anti-Patterns). Last night on the flight to jsconf, I hacked up a more formal patch which puts optimized live and die methods into the jQuery root and aliases them back to the jQuery instances. http://github.com/furf/jquery-live/blob/master/jquery.live.js Unless I'm missing something, I really haven't modified much and these changes could be integrated into jQuery with two copies and two pastes. Hope that helps. -- You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: Will the live() method be improved in 1.4?
I wonder why there would be an $.live with document as the only interesting context. Something like $(document).zombi(selector, type, ...) would be more flexible (I know, "zombi" is not nice, but I have no inspirations about a more suitable name). To avoid to repeat selector on multiple bindings, I suggest something like: $(document).make(selector) .zombi(type, ...) .zombi(type, ...) An possible implementation of that: http://gist.github.com/227508 Maybe this is only a silly idea for majority of users (now), but I am really of idea that this have even more sense then the current $.fn.live. On Nov 5, 2:44 am, xwisdom wrote: > Hello, > > Just wondering if version 1.4 will include improvements to live() > events. > > See example > here:http://www.zachleat.com/web/2009/05/08/performance-caveat-with-jquery... -- You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Is selecting custom JavaScript objects ok?
I little while ago I had a situation where I thought it would be useful to bind jQuery events to custom JavaScript objects. I didn't think it should work, as I thought you could only select DOM nodes. But as you probably know - that's not true. You can select objects too (boring details here... http://www.mrspeaker.net/2009/10/28/using-jquery-on-javascript-objects/). The bit of jQuery code that let's you do this seems to be in the init function where objects fall through to the final path of selector code: return this.setArray(jQuery.isArray( selector ) ? selector : jQuery.makeArray(selector)); So it puts the object in an array and you can call some jQuery functions on it: like bind and data and even include the selections in plugin code. The data stores in the cache object and so seems like a good way to store arbitrary data if you don't want to store it in the object itself (for example 3rd party map applications give you JavaScript objects for markers, but you can't rely on the map provider not to change names and you overwrite properties etc) My question is: is this functionality intentional, and can I rely on it - or is it just "accidental" that objects get caught this way? Thanks! -- You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: Will the live() method be improved in 1.4?
How about $("#something").delegate(".thing","click", func). It almost makes too much sense :). On Nov 5, 6:31 pm, Robert Katić wrote: > I wonder why there would be an $.live with document as the only > interesting context. > > Something like > > $(document).zombi(selector, type, ...) > > would be more flexible (I know, "zombi" is not nice, but I have no > inspirations about a more suitable name). > > To avoid to repeat selector on multiple bindings, I suggest something > like: > > $(document).make(selector) > .zombi(type, ...) > .zombi(type, ...) > > An possible implementation of that:http://gist.github.com/227508 > > Maybe this is only a silly idea for majority of users (now), but I am > really of idea that this have even more sense then the current > $.fn.live. > > On Nov 5, 2:44 am, xwisdom wrote: > > > > > Hello, > > > Just wondering if version 1.4 will include improvements to live() > > events. > > > See example > > here:http://www.zachleat.com/web/2009/05/08/performance-caveat-with-jquery... -- You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Fix-less events
The fix function is rather expensive for things like mousemove and mouseover. Can we make it possible that events won't be fixed for certain events? If you like this idea, I'll submit a patch. -- You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Re: Will the live() method be improved in 1.4?
Meyer, "delegate" was my first candidate too but I was worry that it was overused :). Seams that I was wrong. Will update it with "delegate" ASAP. --Robert On 6. stu. 2009., at 02:42, Justin Meyer wrote: > How about $("#something").delegate(".thing","click", func). > > It almost makes too much sense :). > > On Nov 5, 6:31 pm, Robert Katić wrote: >> I wonder why there would be an $.live with document as the only >> interesting context. >> >> Something like >> >> $(document).zombi(selector, type, ...) >> >> would be more flexible (I know, "zombi" is not nice, but I have no >> inspirations about a more suitable name). >> >> To avoid to repeat selector on multiple bindings, I suggest something >> like: >> >> $(document).make(selector) >> .zombi(type, ...) >> .zombi(type, ...) >> >> An possible implementation of that:http://gist.github.com/227508 >> >> Maybe this is only a silly idea for majority of users (now), but I am >> really of idea that this have even more sense then the current >> $.fn.live. >> >> On Nov 5, 2:44 am, xwisdom wrote: >> >> >> >>> Hello, >> >>> Just wondering if version 1.4 will include improvements to live() >>> events. >> >>> See example here:http://www.zachleat.com/web/2009/05/08/ >>> performance-caveat-with-jquery... > > -- > > You received this message because you are subscribed to the Google > Groups "jQuery Development" group. > To post to this group, send email to jquery-...@googlegroups.com. > To unsubscribe from this group, send email to > jquery-dev+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/jquery-dev?hl=en > . > > -- You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Fix-less events
The only case where that sort-of makes sense is for custom events. I mean, there's not much point in not-fixing the event object for some events - might as well do it for no events then. ...unless there's something else that you were considering? --John On Fri, Nov 6, 2009 at 2:43 AM, Justin Meyer wrote: > The fix function is rather expensive for things like mousemove and > mouseover. Can we make it possible that events won't be fixed for > certain events? > > If you like this idea, I'll submit a patch. > > -- > > You received this message because you are subscribed to the Google Groups > "jQuery Development" group. > To post to this group, send email to jquery-...@googlegroups.com. > To unsubscribe from this group, send email to > jquery-dev+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/jquery-dev?hl=en. > > > -- You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: Will the live() method be improved in 1.4?
I don't think that the method name is at question here, but rather the unnecessary performance cost of querying a selector before DOMReady (or even after), ie. $('#anything'), when it is not needed for the event delegation pattern. The .live method uses only the .selector property of the jQuery instance and not the actual collection of DOM elements, so there is no reason to query the DOM, especially before it is even available. Also, @robert, my solution supports the following notation, similar to yours but using the familiar jQuery syntax (before/after DOMReady): $.live("#mySelector", "click", fn1) .live("#mySelector", "mouseover", fn2) ...; as well as (after DOMReady): $("#mySelector").css("color", "#ff") .live("click", fn1) .live("mouseover", fn2); -- You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Re: Will the live() method be improved in 1.4?
> Also, @robert, my solution supports the following notation, similar to > yours but using the familiar jQuery syntax (before/after DOMReady): > $.live("#mySelector", "click", fn1) > .live("#mySelector", "mouseover", fn2) > ...; I understand the logic behind you wanting a $.live method (for the edge cases where, presumably, you have hundreds or thousands of elements that you're trying to match - and you don't want to run the initial selector). Although there's a lot that I don't like about it: - You are now passing in a selector to a non $(...) or .foo() method. This goes against all the conventions that the library has - when you interact with DOM elements, stay within the jQuery set. - The only case where this matters is in a fringe case (namely, only when you use both a complicated selector AND run it in IE < 8, since all other browsers are using querySelectorAll) - but the existence of the method in jQuery would remove the need to ever use the one method that everyone should use. - Presumably since you're in a situation where you're really caring about performance - then why are you using .live to begin with? Shouldn't you be binding lower in the document? This is why the closest method was added, to make tasks like this even easier. I would simply recommend: If you're in a situation where you're starting with a critical number of elements on your page, enough to ruin your pages' overall performance, then you should use a basic form of event delegation, like so: $("#someRootTable").click(function(e){ $(e.target).closest("td.foo").each(function(){ // Your code goes here. }); }); Which is really what you should be doing anyway (live method or not). --John -- You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Is selecting custom JavaScript objects ok?
It was unintentional - way back in the day - but we've come to embrace it. Expect those aforementioned methods (bind/unbind and data) to continue to work on plain JavaScript object. --John On Fri, Nov 6, 2009 at 1:31 AM, Mr Speaker wrote: > I little while ago I had a situation where I thought it would be > useful to bind jQuery events to custom JavaScript objects. I didn't > think it should work, as I thought you could only select DOM nodes. > But as you probably know - that's not true. You can select objects too > (boring details here... > http://www.mrspeaker.net/2009/10/28/using-jquery-on-javascript-objects/). > > The bit of jQuery code that let's you do this seems to be in the init > function where objects fall through to the final path of selector > code: return this.setArray(jQuery.isArray( selector ) ? selector : > jQuery.makeArray(selector)); > > So it puts the object in an array and you can call some jQuery > functions on it: like bind and data and even include the selections in > plugin code. The data stores in the cache object and so seems like a > good way to store arbitrary data if you don't want to store it in the > object itself (for example 3rd party map applications give you > JavaScript objects for markers, but you can't rely on the map provider > not to change names and you overwrite properties etc) > > My question is: is this functionality intentional, and can I rely on > it - or is it just "accidental" that objects get caught this way? > > Thanks! > > -- > > You received this message because you are subscribed to the Google Groups > "jQuery Development" group. > To post to this group, send email to jquery-...@googlegroups.com. > To unsubscribe from this group, send email to > jquery-dev+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/jquery-dev?hl=en. > > > -- You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] jquery.validate flagging invalid when not
jQuery JavaScript Library v1.3.2 jQuery validation plug-in 1.5.5 I'm working on a form with a bunch of fields with MaxLength validators. When a field with contents are erased the jquery.validate element function kicks in, sees one validator (for max length), which, when evaluated returns "dependency-mismatch", that results in an undefined result, that then causes the field to be flagged as invalid, but with no explanation as to why it is invalid. This code in "element: function(element)" seems to be the problem: var result = this.check(element); if (result) { delete this.invalid[element.name]; } else { this.invalid[element.name] = true; Because, if result isn't true the element gets added to the list of invalid elements. I have a local work around which seems reasonable to me: var result = this.check(element); if (result !== undefined) { if (result) { delete this.invalid[element.name]; } else { this.invalid[element.name] = true; } } Am I missing something? Is this a valid change? Thanks, -- You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Re: Will the live() method be improved in 1.4?
What about something like this: $.live = function(selector, type, callback) { $.fn.live.call({ selector: selector }, type, callback); } On Thu, Nov 5, 2009 at 7:13 AM, xwisdom wrote: > Hi John, > > Thanks for the quick feedback > > IMO, I think it would be handy to have something like $.live as I can > see where it would be of great benefit when working with a lot of > elements. > > -- > > You received this message because you are subscribed to the Google Groups > "jQuery Development" group. > To post to this group, send email to jquery-...@googlegroups.com. > To unsubscribe from this group, send email to > jquery-dev+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/jquery-dev?hl=en. > > > -- You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Re: Will the live() method be improved in 1.4?
$("#someRootTable").delegate("td.foo", "click", function(e){ // Your code goes here. }); Would be easer and safer because the event will be handlet only by "td.foo" elements inside "#someRootTable". --Robert On 6. stu. 2009., at 04:56, John Resig wrote: > $("#someRootTable").click(function(e){ > $(e.target).closest("td.foo").each(function(){ >// Your code goes here. > }); > }); -- You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Re: Will the live() method be improved in 1.4?
If you want to limit, just do this (using the nightlies): $("#someRootTable").click(function(e){ $(e.target).closest("td.foo", this).each(function(){ // Your code goes here. }); }); Still pretty simple and requires no additional functionality. I may just write this up as an example and add it to the live and closest docs. --John On Fri, Nov 6, 2009 at 5:22 AM, Robert Katić wrote: > $("#someRootTable").delegate("td.foo", "click", function(e){ > // Your code goes here. > }); > Would be easer and safer because the event will be handlet only by "td.foo" > elements inside "#someRootTable". > > --Robert > On 6. stu. 2009., at 04:56, John Resig wrote: > > $("#someRootTable").click(function(e){ > $(e.target).closest("td.foo").each(function(){ > // Your code goes here. > }); > }); > > -- > > You received this message because you are subscribed to the Google Groups > "jQuery Development" group. > To post to this group, send email to jquery-...@googlegroups.com. > To unsubscribe from this group, send email to > jquery-dev+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/jquery-dev?hl=en. > -- You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Re: Will the live() method be improved in 1.4?
I suppose you will need an "return false;" too at the end of the handler... --Robert On 6. stu. 2009., at 05:29, John Resig wrote: > If you want to limit, just do this (using the nightlies): > > $("#someRootTable").click(function(e){ > $(e.target).closest("td.foo", this).each(function(){ > // Your code goes here. > }); > }); > > Still pretty simple and requires no additional functionality. I may > just write this up as an example and add it to the live and closest > docs. > > --John > > > > On Fri, Nov 6, 2009 at 5:22 AM, Robert Katić > wrote: >> $("#someRootTable").delegate("td.foo", "click", function(e){ >>// Your code goes here. >> }); >> Would be easer and safer because the event will be handlet only by >> "td.foo" >> elements inside "#someRootTable". >> >> --Robert >> On 6. stu. 2009., at 04:56, John Resig wrote: >> >> $("#someRootTable").click(function(e){ >> $(e.target).closest("td.foo").each(function(){ >>// Your code goes here. >> }); >> }); >> >> -- >> >> You received this message because you are subscribed to the Google >> Groups >> "jQuery Development" group. >> To post to this group, send email to jquery-...@googlegroups.com. >> To unsubscribe from this group, send email to >> jquery-dev+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/jquery-dev?hl=en. >> > > -- > > You received this message because you are subscribed to the Google > Groups "jQuery Development" group. > To post to this group, send email to jquery-...@googlegroups.com. > To unsubscribe from this group, send email to > jquery-dev+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/jquery-dev?hl=en > . > > -- You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Re: Will the live() method be improved in 1.4?
No you will not. My Mistake --Robert On 6. stu. 2009., at 05:29, John Resig wrote: > If you want to limit, just do this (using the nightlies): > > $("#someRootTable").click(function(e){ > $(e.target).closest("td.foo", this).each(function(){ > // Your code goes here. > }); > }); > > Still pretty simple and requires no additional functionality. I may > just write this up as an example and add it to the live and closest > docs. > > --John > > > > On Fri, Nov 6, 2009 at 5:22 AM, Robert Katić > wrote: >> $("#someRootTable").delegate("td.foo", "click", function(e){ >>// Your code goes here. >> }); >> Would be easer and safer because the event will be handlet only by >> "td.foo" >> elements inside "#someRootTable". >> >> --Robert >> On 6. stu. 2009., at 04:56, John Resig wrote: >> >> $("#someRootTable").click(function(e){ >> $(e.target).closest("td.foo").each(function(){ >>// Your code goes here. >> }); >> }); >> >> -- >> >> You received this message because you are subscribed to the Google >> Groups >> "jQuery Development" group. >> To post to this group, send email to jquery-...@googlegroups.com. >> To unsubscribe from this group, send email to >> jquery-dev+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/jquery-dev?hl=en. >> > > -- > > You received this message because you are subscribed to the Google > Groups "jQuery Development" group. > To post to this group, send email to jquery-...@googlegroups.com. > To unsubscribe from this group, send email to > jquery-dev+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/jquery-dev?hl=en > . > > -- You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] ajaxComplete doesn't fire on 404 (should it?)
I searched around for this, but couldn't find any mention of it... which seems a bit spooky, but I'll post it anyway. In this code: $("#complete").ajaxComplete( function(){ $(this).text("complete"); }); $("#start") .ajaxStart(function(){$(this).text("start")}) .ajaxStop(function(){$(this).text("Stop")}); $.ajax({ type:"get", url:"iDontExist.php" }); If the request 404's, then neither the ajaxComplete or ajaxStop events fire. In the jQuery ajax code (line 455 in 1.4pre) it says: // Send the data try { xhr.send( type === "POST" || type === "PUT" ? s.data : null ); } catch(e) { jQuery.handleError(s, xhr, null, e); } But nothing is done to call the complete() method. If I whack a call to complete() in the catch block then everyone looks happy (perhaps... I don't know if you can get the status of the request as 404?). Anyhoo... my question is - is this expected behaviour? That is, does "ajaxComplete" not fire because technically the request didn't complete or something? Thanks! Earle. -- You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: Will the live() method be improved in 1.4?
Regarding improving live(), I would note two things about liveHandler: 1. Calling closest, context argument still is not used. I was unable to find the proper ticket. Would I open one? 2. Storing "how much a parent is close to an element" with data API is an big overhead. An jQuery.lastCloser or something similar would be enough. Also it would speed up sorting inside liveHandler with somethin like this: ... elems.push({ elem: elem, fn: fn, closer: jQuery.lastCloser }); elems.sort(function( a, b ) { return a.closer - b.closer; }); -- You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.