This has been discussed before but I was just curious if this would affect anyone negatively. I'd like to make this change so that less bubbling has to occur (both documentElement and document no longer have to get hit). Roughly, the line in the .live implementation would end up being changed from: jQuery( this.context ) to: jQuery( this.context.body || this.context ) (Thus it would only use the body element on HTML documents, as well.) --John
An update here: http://dev.jquery.com/ticket/4097 This is the same problem that the ExtJS guys were running across recently. A reflow caused a resize which caused a reflow, etc. Supposed it's been fixed post-RC1. --John
Hey Everyone - Just finished up the last ticket for 1.3.2 and wanted to throw a copy out for people to try: http://code.jquery.com/nightlies/jquery-2009-02-16.js Please let me know if anything is breaking from 1.3.1 -> 1.3.2. There were some logic changes - specifically with cloning in IE (lots of bug fixes), how the selector engine, how :visible/:hidden work, .height()/.width(), and .ready() in IE - so watch those areas in particular. The current full ticket list can be found here: http://dev.jquery.com/report/33 Thanks! --John
Hey Everyone - jQuery 1.3rc2 is ready. This means that 1.3 is effectively finished barring a horrible bug between now and the final release on Wednesday (the 14th). You can grab the source here: http://code.jquery.com/jquery-1.3rc2.js Please let me know, personally, if you find some bad new bug and we can triage it together. A screenshot of the final test run can be found here (on 8 browsers): http://www.flickr.com/photos/jeresig/3192101251/ A couple bugs were found in last night's rc1 one (a problem with :not(:first) failing, and two problems with disconnected elements causing problems). As of right now users of the Validation plugin and jQuery UI will both need to upgrade to the latest release when they upgrade to jQuery 1.3. --John
Hi Everyone - I have the first round of jQuery 1.3 patches ready: http://dev.jquery.com/~john/jquery1.3/ This is in addition to the Sizzle selector engine patch which I posted a little bit ago (and which I'll be making an updated version of very soon). The patches are as follows: append.patch: Use DocumentFragment in .domManip. This is a large overhaul of .domManip (and moves some of the logic into jQuery.clean). The result is that manipulation code (append/prepend/etc.) is about 15x faster. During this overhaul I made a change to how scripts are executed. Roughly it means that scripts that are brought in as a string and inserted are executed - but scripts that exist as DOM nodes are not. This will solve the common problem wherein a script that already exists in the page will be dual-executed. Let me know if this affects your code - I suspect we'll learn more during the beta, as well. append-2.patch: Just in case, this is the same patch as above, but with the old-style of functionality intact. closest.patch: This adds a new method: .closest(selector). You can think of it as .firstSelfOrAncestor. This has been a commonly requested function and it will make implementing delegation code trivial. domready.patch: An overhaul of the ready code, removing the the "wait for stylesheets to load" logic. I did a bunch of testing on this and it really appears as if it's impossible to get proper stylesheet loading detection implemented (I wanted to have a "cssready" event for 1.3, but it's not looking likely). Instead we need to back off and simply provide normal DOM ready functionality in .ready(). This means that we need to educate users to include their stylesheets before their scripts in order for them to be accessible in time for DOM ready. multi-namespace.patch: This adds multiple-namespace support to events. Previously you could only do it with one namespace e.g. .bind("click.foo") or .trigger("click.foo"). The patch allows you to use any number of namespaces e.g. .bind("click.foo.bar").trigger("click.bar").unbind(".bar.foo"). selector.patch: Adds a new internal property that keeps track of the selector chain. $("div").find("span").filter(":hidden").parent().selector == "div span.filter(:hidden).parent()". This is meant to be used by plugins (like liveQuery), primarily. The implementation of selectors like .parent() will be coming in a follow-up patch along with Sizzle. strict.patch: Makes it so that we pass strict mode in Firefox 3. Only a few minor tweaks necessary. I have the following patches coming: - Landing Sizzle - Landing .parent()/.filter()/etc. selector implementation. - Native event delegation - Removing the remaining uses of jQuery.browser --John
Hey Everyone - I created a new Trac query that lets us see all the tickets that have attachments and aren't closed (specifically attachments that end in .patch or .diff). http://dev.jquery.com/report/29 We should probably do some triage and make sure that ones with test cases get landed, or rejected, here pretty quickly. --John
Hey Everyone - I've been working on a new selector engine for jQuery on-and-off again these past couple months and I finally have something ready to land: http://dev.jquery.com/ticket/3563 I've been working on the code for this project over here: http://github.com/jeresig/sizzle/tree/master (The end goal is to have this become the new default selector engine in a number of libraries - Prototype, MochiKit, Dojo, and TinyMCE have all expressed interest in using it, as well.) It passes the test suite in Firefox 3, Safari 3.1, and IE 6. There is one minor bug in Firefox 3.1 and another minor one in Opera 9.6 - both of which are specific browser bugs (and I'm filing appropriately) and neither of which are show stoppers. It's a considerable boost in performance over what we have now, in jQuery. I'll go into specific details later (once we're sure that there's no major bugs). Let me know if you have any questions and I'll be happy to answer them (although I'll be going out of town tomorrow for a week). --John
<div dir="ltr">Hi Guys - At the Ajax Experience we talked about possibly making a reusable function for helping to encapsulate much of the functionality commonly seen in jQuery plugins. The important points seemed to be: - Plugins need a way to maintain state from one call to the next (generally in the form of 'options'). - The state needs to be directly associated with the elements that they're called on - There needs to be a default set of options to load state from - Plugins need to clean-up any events or data that they bind to an element - All methods introduced by a plugin should have access to the same state I put my code up here: <a href="http://dev.jquery.com/~john/plugins/widget/">http://dev.jquery.com/~john/plugins/widget/</a> <a href="http://dev.jquery.com/~john/plugins/widget/widget.js">http://dev.jquery.com/~john/plugins/widget/widget.js</a> This is how you would use it: The most basic call: Adds a single method (.test()) whose 'this' represents an individual element wrapped in a jQuery set. An empty options object is provided, as well. <pre id="line1">jQuery.plugin("test", function(a, b){ this.options = a; this.hide(b); }); jQuery("div").test("woo", "slow"); </pre>Equivalent to the first style shown above. <pre id="line1">jQuery.plugin("test", { setup: function(a, b){ this.options = a; this.hide(b); } }); jQuery("div").test("woo", "slow"); </pre>Next step up: A default set of options is provided - which implies that the first argument to .test() will be an options object. <pre id="line1">jQuery.plugin("test", { options: { speed: "slow" }, setup: function(){ this.hide( this.options.speed ); } }); jQuery("div").test({ speed: "fast" }); </pre>Add in some related methods (related to the root setup method) that also have access to the instance and options. <pre id="line1">jQuery.plugin("test", { options: { speed: "slow" }, setup: function(){ this.hide( this.options.speed ); }, methods: { test2: function(){ this.show( this.options.speed ); } } }); jQuery("div").test({ speed: "fast" }).test2(); </pre> Remove some functionality added previously: <pre id="line1">jQuery.plugin("test", { options: { name: "test" }, setup: function(){ this.addClass( <a href="http://this.options.name">this.options.name</a> ); }, teardown: function(){ this.removeClass( <a href="http://this.options.name">this.options.name</a> ); } }); jQuery("div").test({ name: "blah" }); </pre> and the cleanup is triggered by (where 'test' is the name of the plugin that you wish to remove): <pre id="line1">jQuery("div").trigger("remove.test");</pre> It's not completely clear yet what will happen with the above plugin - I just wanted to put it out there since there was some interest in seeing it. <br clear="all">--John </div>
I'm curious: Are there any pieces of code that use jQuery, right now, that you feel are unelegant or ugly? (Presumably ones that've already been optimized to the best of their ability.) One area of improvement that I was thinking of was something along the lines of: // ugly $("#foo").val( $("#bar").val() ); // a bit better $("#foo").val( $("#bar") ); this would be an easy change, just make .attr() do something like: if ( arg.jquery ) val = arg.val() || arg.text() || ""; Any other thoughts? I wonder if there are common cases that could be improved with some simple code additions to core. --John
This seems feasible. --John ---------- Forwarded message ---------- From: Óscar Toledo G. <uno@biyubi.com> Date: Tue, Jul 22, 2008 at 11:14 AM Subject: jQuery enhancement To: jeresig@gmail.com John Resig: Hi, I noted that on jQuery, when it calculates jQuery.browser.version and not matches Mozilla, MSIE, Opera or Webkit, it puts the undefined value. That would of no harm, but Digg.com (on digg.js) uses this value as version.split('.'), so non-recognized browsers trigger a JS error, my suggestion is to change [])[1] to at least: [0,"1.0"])[1] or: userAgent.match(/\/([\d.]+)/))[1] So 'version' gets assigned a meaningful value. This would benefit new browsers. Thanks for your time. Óscar Toledo G. http://www.biyubi.com/
Hi Everyone - I'm working on that method and I think some improvements could be make if the API was tweaked a little bit - are any plugins using it? I'd rather not change it if code will break. Thanks! --John
So I really want event delegation in jQuery 1.3: http://docs.jquery.com/JQuery_1.3_Roadmap I've been thinking of ways that we can make it better and more jQuery like (especially with the new .selector property that I propose). I have a couple thoughts: Binds to $("#container") and watches for all clicks, filtering against the expression "div" - a fast LiveQuery substitute: $("#container div").delegate("click", function(){}); Binds to document look for all div: $("div").delegate("click", function(){}); Switch against multiple filter types, still bound to #container: $("#container (.open, .closed)").delegate("click", function(e){ switch(e.filter){ case: ".open": case: ".closed": } }); Or - First function handles .open, second handles .closed: $("#container (.open, .closed)").delegate("click", function(){}, function(){}); Naturally if there was more than one container then a delegation would be bound to each, individually: $("div > span").delegate("click", ...); And all of this will even work with the native methods! $("#container").children(".foo").delegate("click", ...); Naturally it won't be able to work directly with stuff like +, ~, parent, parents, next, nextAll, prev, and prevAll since they aren't actually contained within the original container. But this could work: $("#container").find("div").next().delegate("click", ...); If we wanted to, we could even explore firing DOM-related events (add/remove/modify) if a delegation method is bound: $("#container li").delegate("added", function(){ $(this).addClass("test"); // li now has a class of test }); I realize that this changes the actual meaning of "delegate" - we may want to use different terminology "awesomeBind" hehe. Thoughts? --John
Everyone - I'd like to take this opportunity to welcome Ariel Flesler to the jQuery Dev Team. He's put a ton of work in on the upcoming jQuery 1.2.4 release, in addition to releasing numerous plugins. His contributions have been quite valuable and it's an honor to have him aboard. His site: http://flesler.blogspot.com/ His Twitter Account: http://twitter.com/flesler --John (Note: Thanks to Ariel's help, the 1.2.4 release should be arriving within the next day or two - pending any final patches.)