Hi there, you may not know me, but my name is Nate, and I am a designer/programmer.

 I’ve been helping a bit with looking for bugs, and with site design stuff, and though I’m not on the team list, I started helping a bit after the list was written.

 Anyways, to help get the word about jQuery out there in the world, I’ve gone ahead and created some minimalistic wallpapers to adorn your desktop.

 You can download the files here:

jQuery MNML v1. (resoltions in zip: 640×480 through 1600×1200)
jQuery MNML v2. (resoltions in zip: 640×480 through 1600×1200)
jQuery MNML v3. (resoltions in zip: 640×480 through 1600×1200)

jQuery MNML v1

jQuery MNML v2

jQuery MNML v3

Enjoi!

Note: Jack went ahead and fixed virtually everything mentioned in this post – great job!

---

We’ve been holding off on talking about the speed of the jQuery selectors for the new 1.1 release until our release was closer to being ready – however, it seems as if that process has already been expedited. So with that already out of the bag, lets look at the selector speeds of jQuery.

In short: For jQuery 1.1 we worked really really hard to make its selectors really fast. In fact, according to all our tests we were faster than any other selector library. Working on the 1.1 release, Dean Edwards’ cssQuery far out-performed any other selector library. It’s really comprehensive, and really fast.

Today, Jack Slocum announced his new DOMQuery selector library. In short: The bar has been raised. His library is very very fast. Quite possibly the fastest available today.

However, in the comparison between his library and ours, some mistakes were made that we’d like to clear up. (By both Jack and jQuery) (For reference, here’s the comparision suite that I used for my tests.)

jQuery completely supports all attribute selectors.
For example, [@foo], [@foo=bar], etc. The notable difference is that jQuery uses the XPath-style syntax in this situation. Since this was not accounted for in Jack’s test, it appeared as if we failed for all of the attribute selector tests.

Our “elem:empty” works just fine.
You can see in Jack’s test that all selectors (but DOMQuery) fail :empty – that’s more due to the fact that he compares the results against DOMQuery, which gets the result wrong. The specification states that something is empty if it doesn’t contain any child elements or text nodes. That doesn’t seem to be accounted for in this case.

[foo!=bar], :first, :last aren’t part of any specification.
…and yet they’re in the test suite. Incidentally, jQuery does implement :first and :last – but not [foo!=bar] (which appears to be only in cssQuery?). In all, its very strange to compare yourself against others when its not something that you’re designed to do.

What does span:not(span.hl-code) match?
This is a strange gray area that I haven’t seen talked about anywhere, and the specification doesn’t help to clear it up at all. Should the resulting set be all spans that don’t have a class of hl-code – or nothing, since you’ve filtered out all the spans. For example:

// Finds nothing in both
span:not(span)
=> []

// Finds spans that don't have a class of 'foo', in both
span:not(.foo)
=> [ <span>, <span>, ... ]

// jQuery's interpretation of the combination:
$("span:not(span.foo)")
=> []

// DOMQuery's interpretation of the combination:
Ext.select("span:not(span.foo")
=> [ <span>, <span>, ... ]

We’ll fully concede that we may be very wrong on this point – but I’m curious to hear what others have to say, and what they’re interpretations of the spec, are.

DOMQuery doesn’t account for duplicates.
Currently, doing Ext.select(“div div”) returns MORE elements than doing just Ext.select(“div”) – and doing Ext.select(“div div div”) returns yet another different set of elements, but still more than just doing Ext.select(“div”). In fact, accounting for duplicates is a huge problem in JavaScript selector libraries – and currently, jQuery is the only one that gets it right.

A big point of this is that accounting for duplicates can be really expensive (computationally) – so the fact that DOMQuery doesn’t account for duplicates gives the appearance of a speed boost. For example:

// DOMQuery
Ext.select("div").elements.length
=> 246
Ext.select("div div").elements.length
=> 624
Ext.select("div div div").elements.length
=> 523

// jQuery
jQuery("div").length
=> 246
jQuery("div div").length
=> 243
jQuery("div div div").length
=> 239

DOMQuery doesn’t support multiple filters: elem.foo[foo=bar] or elem.foo.bar
Until this is implemented, a comparison with any other library simply isn’t fair. Building a library that’s fully capable of handling aspects like that (see: cssQuery, jQuery) comes at a great cost. (Whether it be in code size or speed cost.)

DOMQuery’s #id selectors don’t check for context
You’ll notice if you try to do a query like:

Ext.select("div #badid").elements
=> [div#badid]

That you’ll get an element by “badid” — even if that element isn’t actually inside of a div. Since no check for validity is actually made in the DOMQuery code, it’s blazing fast – and very wrong.

I should mention that until 1.1, jQuery was wrong on this point too, so its an easy issue to overlook.

Where’d the root element go?
You’ll find that searches for “html” and “*” in DOMQuery are strangely missing one obvious thing: The HTML element. seems kind of weird to exclude the root DOM element from all queries; especially since this is perfectly valid: “html > body *”.

…and to make it fair – here’s one for us :-)

Our :nth-child(even/odd) is flawed.
Currently it seems to only select one element (!?). I made a ticket for this and it should be resolved for this Sunday’s 1.1 release.

In all, its great to see the speed leaps that’ve been made by DOMQuery. Selector speed is one area where competition is truly warranted; every time a new speed increase is made, everyone wins (users, developers – everyone).

In fact, looking over his code, I already have some more ideas on how to increase the speed of jQuery!

So, to Jack: Thanks for helping to keep us on our toes – we’re looking forward to seeing your library improve, and everyone win.

We’re nearly ready for the big 1.1 release, this Sunday – but to hold you over, here’s another set of bug fixes to test upon. The jQuery dev team has been working long-and-hard to fix all the support requests that’ve been coming in this week, and we’ve been pretty successful in fixing just about everything that’s come across our plate.

We’d really appreciate it if you’d take the time to test the new 1.1b with your code, and if you spot any bugs, to please submit them to the bug tracker.

It’s not all bug fixes, however; we do have something new for you to try: The jQuery 1.0 Compatibility Plugin. As promised, this plugin provides all of the methods and selectors that were present in the last 1.0.4 release. So, theoretically, you should be able to drop in jQuery 1.1, and the new compatibility plugin and everything should work seamlessly.

This is how you would use the compatibility plugin with jQuery 1.1:

<html>
<head>
  <script src="jquery-1.1.js"></script>
  <script src="jquery.compat-1.0.js"></script>
  <script>
    $(document).ready(function(){
        // Your old 1.0-centric code
    });
  </script>
</head>
<body></body>
</html>

So, while its fully possible to continue using the compatibility plugin into the foreseeable future, it is highly recommended that you follow the upgrade plans mentioned before.

So, again; please help us test this beta release! The more you help test, the better the final 1.1 release is going to be. Thanks for all your help!

Download

• Download 1.1b Uncompressed (Testing Only!)
• Download 1.0 Compatibility Plugin (Makes 1.1 have the same API as 1.0)
• Please submit new bug reports here: New Bug Report

Update: There’s a couple things that I forgot to mention (that’s what I get for posting a release at 4am in the morning):

• .filter([“.foo”, “.bar”]) is now .filter(“.foo, .bar”): A much simpler solution – and a fix is already in the compatibility plugin.
• .We decided to keep .height() and .width(). They’re back in, as they’re quite useful.
• The documentation is updated to 1.1b (so for those of you who still saw .filter([…]) or didn’t see .height() and .width() – it’s fixed now.)

As previously announced, today we’re bringing you the alpha release of jQuery 1.1. We’d really appreciate it if you could help us test this alpha, so that we can have a stand-up release this weekend – just in time for jQuery’s 1 Year Anniversary! (January 14th)

This is going to be a fantastic release. In fact, this release is so good that we’re going to be taking this entire week to tell you about what’s new and how you can best use it. The Evangelism team has a bunch of stuff lined up to get you introduced and ready to use this great new version of jQuery.

Here’s the quick-and-dirty on jQuery 1.1:

• Its selectors are 10-20x faster than those in jQuery 1.0.4.
• The documentation has been completely revamped.
• The complexity of the API has dropped by 47%.
• It has a ton of bug fixes.
• It has a bunch of great new features.
• … and it’s still the small 19KB that you’ve come to expect.

We’re going to have the full run down during the next couple days, but for right now, it’s shaping up to be a great release.

Download

• Download Uncompressed (Testing Only!)
• Please submit new bug reports here: New Bug Report

API Changes

NOTE: We will release a backwards compatibility plugin together with the full release of jQuery 1.1, when it is released this weekend.

It’s important to note that there’s been a lot of API changes. Some in the form of additions, some in the form of reorganization. If you’d like to help us test this alpha release, please keep these changes in mind:

:nth-child() now starts at 1, instead of 0. Our implementation of the CSS 3 selector started its numbering at 0, instead of 1. This is a bug fix, but one that may effect your code.

// 1.0.x: Get the first column from a table
$("td:nth-child(0)")

// 1.1: Get the first column from a table
$("td:nth-child(1)")

The following methods have been renamed/reorganized in this version, here is how you can continue to use them, as you would expect:

Old Way (1.0.x)	New Way (1.1)
.ancestors()	.parents()
.width()	.css(“width”)
.height()	.css(“height”)
.top()	.css(“top”)
.left()	.css(“left”)
.position()	.css(“position”)
.float()	.css(“float”)
.overflow()	.css(“overflow”)
.color()	.css(“color”)
.background()	.css(“background”)
.id()	.attr(“id”)
.title()	.attr(“title”)
.name()	.attr(“name”)
.href()	.attr(“href”)
.src()	.attr(“src”)
.rel()	.attr(“rel”)
.oneblur(fn)	.one(“blur”,fn)
.onefocus(fn)	.one(“focus”,fn)
.oneload(fn)	.one(“load”,fn)
.oneresize(fn)	.one(“resize”,fn)
.onescroll(fn)	.one(“scroll”,fn)
.oneunload(fn)	.one(“unload”,fn)
.oneclick(fn)	.one(“click”,fn)
.onedblclick(fn)	.one(“dblclick”,fn)
.onemousedown(fn)	.one(“mousedown”,fn)
.onemouseup(fn)	.one(“mouseup”,fn)
.onemousemove(fn)	.one(“mousemove”,fn)
.onemouseover(fn)	.one(“mouseover”,fn)
.onemouseout(fn)	.one(“mouseout”,fn)
.onechange(fn)	.one(“change”,fn)
.onereset(fn)	.one(“reset”,fn)
.oneselect(fn)	.one(“select”,fn)
.onesubmit(fn)	.one(“submit”,fn)
.onekeydown(fn)	.one(“keydown”,fn)
.onekeypress(fn)	.one(“keypress”,fn)
.onekeyup(fn)	.one(“keyup”,fn)
.oneerror(fn)	.one(“error”,fn)
.unblur(fn)	.unbind(“blur”,fn)
.unfocus(fn)	.unbind(“focus”,fn)
.unload(fn)	.unbind(“load”,fn)
.unresize(fn)	.unbind(“resize”,fn)
.unscroll(fn)	.unbind(“scroll”,fn)
.ununload(fn)	.unbind(“unload”,fn)
.unclick(fn)	.unbind(“click”,fn)
.undblclick(fn)	.unbind(“dblclick”,fn)
.unmousedown(fn)	.unbind(“mousedown”,fn)
.unmouseup(fn)	.unbind(“mouseup”,fn)
.unmousemove(fn)	.unbind(“mousemove”,fn)
.unmouseover(fn)	.unbind(“mouseover”,fn)
.unmouseout(fn)	.unbind(“mouseout”,fn)
.unchange(fn)	.unbind(“change”,fn)
.unreset(fn)	.unbind(“reset”,fn)
.unselect(fn)	.unbind(“select”,fn)
.unsubmit(fn)	.unbind(“submit”,fn)
.unkeydown(fn)	.unbind(“keydown”,fn)
.unkeypress(fn)	.unbind(“keypress”,fn)
.unkeyup(fn)	.unbind(“keyup”,fn)
.unerror(fn)	.unbind(“error”,fn)

I realize that’s a long list – but you’d be surprised how much of that no one was using. By removing all of those methods we’ve been able to reduce the size of the jQuery API by 47%. We’re going to have more information about the API changes in particular, but for now, this list should help you to sort out any major differences in your code.

If you have any questions, feel free to post them here in the comments and we’ll get them answered right away.

Just a quick update so that everyone knows what’s going on: The jQuery Dev Team is currently working on the upcoming 1.1 release of jQuery. So SVN is going to be changing rather significantly during the next couple weeks. Here’s the current game plan:

• jQuery 1.1a January 7th – A quick alpha release to help everyone test their code and get it moved over to the upcoming 1.1 release.
• jQuery 1.1 January 14th – This will be the official release, to coincide with jQuery’s 1 year anniversary.

It’s important to note that jQuery 1.1 will not be backwards compatible with 1.0. The changes will occur in different ways, but so far, this is what is planned to change:

• Methods like .oneclick() and .unclick() will be going away in favor of .one(“click”) (new) and .unbind(“click”). We found that these methods weren’t used enough to warrant the 70+ API entries that they required.
• Selectors :nth-child(), :gt(), :lt(), and :eq() will all be starting count at 1 instead of 0, in line with the CSS specification. (This is a bug fix, but causes an incidental API change)
• Some CSS helper methods are going away, like: .color() and .background(). You should start moving over to using .css(“color”) and .css(“background”) instead.
• Some attribute helper methods like .title() and .rel() are going away. You should start using .attr(“title”) and .attr(“rel”) instead.

A lot of this is being done to help reduce the magnitude of methods that are included in the jQuery API. Having 70+ less entries will significantly reduce the size of the documentation, along with making it easier to maintain and read.

If you’re interested in the direction that the jQuery code base is heading in, please feel free to subscribe to the jQuery Dev Mailing List where the jQuery Dev Team discusses all of these issues in depth.

Update: I forgot to mention that there will be a compatibility plugin that’ll help you transition over to jQuery 1.1. This way, you can continue to use .oneclick() (and all the other methods) into the foreseeable future (even though it may not be in the jQuery core).

I would like to take this opportunity to introduce everyone to the people behind jQuery. Not enough has been said about who works for the project and what they do to help out. This fact, combined with a recent re-organization, makes for the perfect time to show you how jQuery works, behind the scenes.

jQuery is an incredible undertaking, with 11 people directly donating their time to furthering jQuery (and countless others contributing plugins, bug fixes, and knowledge). It is important that attention be drawn to the work of all those who help with the project, considering that their work is incalculably valuable.

Expect to see many advancements being made to the jQuery project in the upcoming month (leading up to Jan. 14th – jQuery’s one year “birthday”).

This is a great time to get involved in the jQuery project. Find a team that interests, hop on their mailing list – and get involved. Help is always appreciated. If you don’t have any time to give to the project, financial contributions are always appreciated (and help to maintain the server and level of quality that you expect in the project).

So, without any more hassle, I present to you: The People Behind jQuery.

Development Team

The development team maintains the core aspect of jQuery: The very code itself; pushing the project forward since its inception. It’s been slowly growing, in recent months, keeping up with the demand for features and bug fixes.

The purpose of the development team is just that: To improve the quality of the jQuery code base (by adding in new features) and to fix existing problems (creating a more stable library for everyone to use). Additionally, the team is in charge of documenting all of the jQuery API, building a stable test suite and maintaining the jQuery build system (through which all jQuery code, documentation, and tests are constructed).

John Resig (Massachusetts, United States)

John is a programmer and author living in Boston, Massachusetts. He’s in charge of managing the direction of the jQuery library. This involves taking a critical look at existing (and expected) features and making informed decisions about them. He’s also in charge of managing development resources and time spent on the different aspects of the project.

Jörn Zaefferer (Bergneustadt, Germany)

Jörn is a programmer living in Germany. He’s a driving force of the jQuery development process, contributing numerous bug fixes and pushing out many of the 1.0.x releases. He’s also responsible for completely re-building the jQuery test suite and writing a majority of the test cases. He has been the driving force behind the jQuery development process these past few months, helping to bring jQuery closer to an excellent 1.1 release.

Brandon Aaron (Texas, United States)

Brandon is a developer living in Texas, and a new addition to the development team. Having contributed numerous bug fixes for the 1.0.x releases, he’s now taking a critical look at the Animation and CSS/DOM aspects of the jQuery core. He’s looking to provide significant increases in code speed and clarity. This will give us the ability to do things like pause/resume animations.

Paul Bakaus (Mainz, Germany)

Paul is a programmer living in Germany, and a sponsored contributor to jQuery. His work with jQuery has been focused on transforming jQuery into a high-speed library capable of handling difficult large-scale drag-and-drop operations. He was largely responsible for creating the recent dimensions plugin and for suggesting numerous improvements to the CSS methods of jQuery. All of his work is tied back to the Interface Plugin and attempting to create a high-speed drag-and-drop solution.

Stefan Petre (Romania)

Stefan is a developer living in Romania and the creator of the Interface Plugin. His work with the plugin has been led by the desire to create fast, interactive, web-based applications. Interface has been adopted as an officially-sponsored jQuery plugin (along with a few other high-quality plugins). Paul and Stefan are currently working together to improve the overall quality of the Interface plugin (both in speed and quality of code).

Mike Alsup (New York, United States)

Mike is a developer living in New York and is responsible for maintaining the official form plugin for jQuery. He has worked quite extensively to unify and test the Ajax-form-submission process into a single plugin. Additionally, much of his work has trickled back into improving the quality, and consistency, of the core jQuery Ajax code.

Evangelism Team

This is a brand new jQuery team. The focus of this group is to watch the pulse of the jQuery community (both at home and at large) and help in any way that they can. Frequently, this means building new tutorials, explaining difficult problems, or communicating to the other teams what needs to be updated or changed.

This group can be thought of as a sort of developer relations – communicating the desires of the jQuery users back to the dev/web/design teams, while at the same time, going out of their way to bring jQuery to users who haven’t found it yet.

Rey Bango (Florida, United States)

Rey Bango is a consultant living in South Florida, specializing in the development of Rich Internet Applications. He’s been working with jQuery for a while now, and evangelizing its benefits to a large number of people. He’s already helped to convert a number of prominent Cold Fusion developers. He was also responsible for starting and helping to run the jQuery Button Contest.

Karl Swedberg (Michigan, United States)

Karl is a developer living in Michigan who maintains the web site Learning jQuery. He writes numerous tutorials and helps people to better understand how jQuery works. He is a frequent of the jQuery mailing list, helping new users get adjusted to using the library. As a member of the evangelist team he will be continuing his work, finding people who need help understanding the finer points of the library and giving them the resources that they need to get up to speed.

Web Team

The web team is fully responsible for creating the new jQuery web site. This is a team that’s been in the planning for a long time, but is finally starting to come to light. Much of this has been due to the fact that it’s such a daunting project.

In short, many new features are going to be rolled out in the upcoming weeks. The whole process is going to take some time, but the results will be very rewarding. The first features that you can expect are a proper discussion area (hooked in to the existing mailing list) and a proper repository for all the plugins that exist.

All of this will be built using the Drupal CMS. Recently, we helped Drupal convert over to using jQuery as their primary JavaScript library (powering all Drupal-based sites in the upcoming 5.0 release). In working with the Drupal development team, they’ve been most gracious in offering help in any way that they can, with the new site. In addition to this offer of support, the Drupal engine is fantastically powerful, providing nearly every feature that we need to power the new site.

In addition to the Drupal development team, the following Drupal users have offered to donate their time and effort to help build the new jQuery site.

Mike Hostetler (Colorado, United States)

Mike is a developer living in Colorado. He has significant experience setting up Drupal-based sites. What’s of particular interest is that he already setup a Drupal community and plugin area for another Open Source project: QCodo. He’s already begun work, setting up the base area in which the web team is going to work – and working to integrate the SVN plugin repository directly into the web-based plugin repository (for unified access to all who want it). His work will serve as the base for the rest of the web team’s development efforts.

Tane Piper (Edinburgh, UK)

Tane is a developer living in the UK. He has extensive experience with both PHP and Drupal. Tane recently setup the website getjQuery.org (using Drupal) – at which time I saw the opportunity to bring him in, helping to add many of his desired features to the official jQuery site (like the discussion area and plugin repository, to name a few).

Design Team

The design team is another recent addition to the jQuery development process. The goal of the team is to implement the complete redesign of the jQuery web site, along with all of its upcoming sub-sections (this is working in conjunction with the web team, implementing the design for their work).

There are many individual aspects to this team (such as icon design, branding, graphic design, and XHTML/CSS composition) that will be tied together through the different web projects.

Bradley Sepos (Ohio, United States)

Bradley is an independent designer living in Ohio. He has already started some fine work, creating some excellent mock ups of the new jQuery.com design. He is going to be working on finishing up a solid design for the main jQuery landing page. He will also be in charge of devising a solid branding and design guideline for the rest of the site (and the jQuery project as a whole).

Skye Giordano (Missouri, United States)

Skye is a professor, teaching web design, living in Missouri. He has already been collaborating with Bradley on the design of the new site. In the upcoming weeks he will be focusing on a particular section of the site to completely design from the ground, up. (Such as the discussion area, or the plugin area – this has yet to be decided.)

Some recent articles have discussed the need for having “really good” tutorials for JavaScript libraries.

As always, we’re working to make the jQuery documentation better and more useful, so I want to pose the following question: What are some tutorials that would help you better use or learn jQuery? Make sure it’s something simple (like “Building a drop-down menu.”) and not something really complex (like “Building a complete shopping cart system”). Feel free to post your suggestions here in the comments, it’ll help to give us a good idea of what people want and what needs better explaining.

We’ve recently started working on the reorganization of the jQuery documentation wiki. Right now it’s quite messy and all over the place. As you can see from the new wiki’s structure, however, is that we’re going for a much more thorough representation of jQuery itself. Within each of these topics we want to include a number of useful “common case” tutorials that will help you to better understand the functions in the jQuery API.

So please: (Taking into account what you see of the new wiki’s structure) What would help you better learn, and use, jQuery?

Another fantastic release of jQuery is ready for your consumption. This release includes a number of bug fixes (as usual) along with some much-needed improvements to jQuery’s Ajax functionality.

As always, if you have any questions or concerns with new release, please feel free to discuss it on the jQuery Mailing List. If you think you’ve spotted a bug, please add it to the bug tracker.

So, without further ado, here’s jQuery 1.0.4:

Download

• Compressed JavaScript (Recommended Download!)
• Uncompressed JavaScript
• 1.0.4 Documentation
• 1.0.4 Test Suite
• Full Release (jQuery, Test Suite, Documentation)
• Build Files (Compile your own version of jQuery 1.0.4)

Changes and Features

• Tons of bug fixes (Full List)
• Extensions to $.ajax(): $.ajax accepts additional options: beforeSend, async and processData; returns XMLHttpRequest to allow manual aborting of requests, see docs for details.

  Example: Add extra headers to an Ajax request using beforeSend

  $.ajax({
    type: "POST",
    url: "/files/add/",
    beforeSend: function(xhr) {
      xhr.setRequestHeader( "Content-type", "text/plain" );
    },
    data: "This is the contents of my text file."
  });

  Example: Perform a synchronous Ajax request.

  // Get the HTML of a web page and save it 
  // to a variable (the browser will freeze until the 
  // entire request is completed).
  var html = $.ajax({
    type: "GET",
    url: "test.html",
    async: false
  }).responseText;
  
  // Add the HTML into the page
  $("#list").html( html );

  Example: Sending a JavaScript object using processData.

  // The data to send to the server
  var params = {
    name: "John",
    city: "Boston"
  };
  
  // Send the data, but have it be converted into
  // a format the server can understand (w/ processData)
  $.ajax({
    type: "POST",
    url: "/user/add/",
    data: params,
    processData: true
  });

  Example: Aborting an Ajax request after a specific delay in time.

  // Perform a simple Ajax request
  var req = $.ajax({
    type: "GET",
    url: "/user/list/",
    success: function(data) {
      // Do something with the data...
      // Then remove the request.
      req = null;
    }
  });
  
  // Wait for 5 seconds
  setTimeout(function(){
    // If the request is still running, abort it.
    if ( req ) req.abort();
  }, 5000);

• AJAX module: The public $.ajax API is now used internally (for $.get/$.post etc.); loading scripts works now much more reliably in all browsers (with the exception of Safari, which is a work in progress).
• New global Ajax handler: ajaxSend – called before an Ajax request is sent.

  Example: Add extra headers to all Ajax requests using the ajaxSend event.

  $(document).ajaxSend(function(xhr){
    xhr.setRequestHeader("X-Web-Request", "MySite.com");
  });

• Extensions to global Ajax handlers: ajaxSend, ajaxSuccess, ajaxError and ajaxComplete get XMLHttpRequest and settings passed as arguments.

  Example: Prevent any POST requests that are sending too much data.

  $(document).ajaxSend(function(xhr,options){
    if ( options.type == "POST" && options.data.length > 1024 )
      xhr.abort();
  });

  Example: Show a special message for requests submitted using an Ajax POST.

  $("#dataSent").ajaxSend(function(xhr,options){
    if ( options.type == "POST" )
      $(this).show();
  });

• Extensions to event handling: pageX and pageY are available in all browsers now. (IE does not provide native pageX/Y).

  Example: Have a tooltip follow a user’s mouse around the page.

  $(document).mousemove(function(e){
    $("#mousetip").css({
      top: e.pageY + "px",
      left: e.pageX + "px"
    });
  });

• Improved docs: $(String) method has now two separate descriptions, one for selecting elements, one for creating html on-the-fly.
• FX module: Most inline styles added by animations are now removed when the animation is complete, eg. height style when animating height (exception: display styles).

Rich Manalang, one of the regulars on the jQuery mailing list, took the initiative and with a little help has gotten the jQuery API posted up on gotAPI.com. If you haven’t been over to gotAPI, its a great online documentation resource that provides a comprehensive API listing for most popular programming languages and frameworks. Great job Rich!

Joshua Eichorn will be giving a talk about jQuery at the Pheonix azPHP user group tonight. You can get more details here:

jQuery at AZPhp