You can help us by dropping that code into your existing application and letting us know that if anything no longer works. Please file a bug and be sure to mention that you’re testing against jQuery 1.6.4.

We want to encourage everyone from the community to try and get involved in contributing back to jQuery core. We’ve set up a full page of information dedicated towards becoming more involved with the team. The team is here and ready to help you help us!

jQuery 1.6.4 Change Log

The current change log of the 1.6.4 release.

Data

#10194: Data attribute names with single dash-surrounded letters cannot be accessed by the camel-case name

Event

#10208: $(“form”).live(“submit”, fn) not fired from <button type=”submit”> in IE8

You can help us by dropping that code into your existing application and letting us know if anything no longer works. Please file a bug and be sure to mention that you’re testing against jQuery 1.6.3.

Many thanks to all the people who reported bugs, submitted patches, and otherwise helped with this release! We want to encourage everyone from the community to get involved in contributing back to jQuery core. We’ve set up a full page of information dedicated towards becoming more involved with the team. The team is here and ready to help you help us!

Highlights

Fix an XSS attack vector: User ma.la reported a common pattern that many sites are using to select elements using location.hash that allows someone to inject script into the page. This practice seemed widespread enough that we decided to modify the selector recognition to prevent script injection for the most common case. Any string passed to $() cannot contain HTML tags (and thus no script) if it has a “#” character preceding them. See the ticket linked above for more information and a test case.

No more animation “worm holes”: We had high hopes for the browser’s requestAnimationFrame API when we added support into version 1.6. However, one of the highest-volume complaints we’ve received since then relates to the way requestAnimationFrame acts when a tab is not visible. All the animations initiated when the tab is invisible “stack” and are not executed until the tab is brought back into focus. Then they all animate at warp speed! We’ve removed support for this API (which has no impact on the way you call jQuery’s animation features) and plan to incorporate it into a future version of jQuery.

Better handling of HTML5 data attribute names: The $().data() API serves double-duty, handling data for the internal use of jQuery and plugins in addition to reading initial values of HTML5 data- attributes. We’ve improved the ability to use HTML5 conventions such as converting camel-case to camelCase when needed. Remember, however, that the $().data() API only reads the HTML5 data- attributes initially, and does not keep subsequent data changes in sync with attributes for performance reasons. To update the actual attributes in the HTML markup, use .attr().

jQuery 1.6.3 Change Log

The change log of the 1.6.3 release:

Ajax

#9255: jQuery.parseXML error handling does not work in webkit browsers

You can feel free to include the above URLs directly into your site and you will get the full performance benefits of a quickly-loading jQuery.

You can help us by dropping that code into your existing application and letting us know that if anything no longer works. Please file a bug and be sure to mention that you’re testing against jQuery 1.6.2.

We want to encourage everyone from the community to try and get involved in contributing back to jQuery core. We’ve set up a full page of information dedicated towards becoming more involved with the team. The team is here and ready to help you help us!

You can help us by dropping that code into your existing application and letting us know that if anything no longer works. Please file a bug and be sure to mention that you’re testing against jQuery 1.6.2 RC 1.

We want to encourage everyone from the community to try and get involved in contributing back to jQuery core. We’ve set up a full page of information dedicated towards becoming more involved with the team. The team is here and ready to help you help us!

Support

Back in 2007 we released the jQuery Color Plugin, and it has been providing you with color-based animations ever since. We are now preparing a second version of this plugin which adds an API, RGBA, HSLA, and many other features. It is time for a beta! The repository for this plugin can be found at github.com/jquery/jquery-color. There are also uncompressed and minified versions available on code.jquery.com.

New Feature Overview:

RGBA

We now support RGBA color values. In browsers that don’t support RGBA, the nearest backgroundColor to the element will be used to calculate a “blended” approximation of the color. Although this isn’t “true” alpha, it will at least provide the illusion of alpha when dealing with solid background colors. This is a screenshot of Opera 10, Chrome 10, Firefox 3.6, and IE 6 all running this demonstration of alpha blending:

HSLA

We also now support using HSLA color values across all browsers, with the execption of alpha, which uses the same techniques described above.

Easy-to-use API

Instead of a simple group of private utility methods, $.Color() now creates a new Color object. The new Color object can be initialized in a few different ways: color names, hexidecimal color codes, css style rgba/hsla, an array of rgba values, or an object with the color properties. There are now helper methods for each color property, like .red() and .hue() that can get or set the particular value. Combined with helper functions like .toRgbString(), .transition() and .is(), $.Color can now handle whatever color needs you might have. Refer to the README on github.com/jquery/jquery-color for an overview of all the new functions available. No longer is jQuery.Color just providing you with animation of simple colors, you can now use its API to do complex color calculations and animations!

You can help us by dropping that code into your existing application and letting us know that if anything no longer works. Please file a bug and be sure to mention that you’re testing against jQuery 1.6.1.

We want to encourage everyone from the community to try and get involved in contributing back to jQuery core. We’ve set up a full page of information dedicated towards becoming more involved with the team. The team is here and ready to help you help us!

Upgrading From 1.5.2 to 1.6.1

With the introduction of the new .prop() method and the changes to the .attr() method, jQuery 1.6 sparked a discussion about the difference between attributes and properties and how they relate to each other. It also came with some backwards compatibility issues that have been fixed in 1.6.1. When updating from 1.5.2 to 1.6.1, you should not have to change any attribute code.

Below is a description of the changes to the Attributes module in jQuery 1.6 and 1.6.1, as well as the preferred usage of the .attr() method and the .prop() method. However, as previously stated, jQuery 1.6.1 will allow you to use .attr() just as it was used before in all situations.

Note that the changes described in the 1.6 release notes regarding the .data() method have been worked around and now work seamlessly between 1.5.2 and 1.6.1.

What’s Changed

The changes to the Attributes module removed the ambiguity between attributes and properties, but caused some confusion in the jQuery community, since all versions of jQuery prior to 1.6 have handled attributes and properties in one method(.attr()). The old .attr() method had many bugs and was hard to maintain.

jQuery 1.6.1 comes with several bug fixes as well as an update to the Attributes module.

Specifically, boolean attributes such as checked, selected, readonly, and disabled in 1.6.1 will be treated just as they used to be treated in jQuery versions prior to 1.6. This means that code such as

will not need to be changed in 1.6.1 in order to work as previously expected.

To make the changes to .attr() in jQuery 1.6 clear, here are some examples of the use cases of .attr() that worked in previous versions of jQuery that should be switched to use .prop() instead:

.attr()

Proper .prop() usage

$(window).attr…

$(window).prop…

$(document).attr…

$(document).prop…

$(“:checkbox”).attr(“checked”, true);

$(“:checkbox”).prop(“checked”, true);

$(“option”).attr(“selected”, true);

$(“option”).prop(“selected”, true);

First, using the .attr() method on the window or document did not work in jQuery 1.6 because the window and document cannot have attributes. They contain properties (such as location or readyState) that should be manipulated with .prop() or simply with raw javascript. In jQuery 1.6.1, the .attr() will defer to the .prop() method for both the window and document instead of throwing an error.

Next, checked, selected, and other boolean attributes previously mentioned are receiving special treatment because of the special relationship between these attributes and their corresponding properties. Basically, an attribute is what you see in the html:

<input type=”checkbox” checked=”checked”>

Boolean attributes such as checked only set the default or initial value. In the case of a checkbox, the checked attribute sets whether the checkbox should be checked when the page loads.

Properties are what the browser uses to keep track of the current values. Normally, properties reflect their corresponding attributes (if they exist). This is not the case with boolean attributes. Boolean properties stay up to date when the user clicks a checkbox or selects an option in a select element. The corresponding boolean attributes do not. As was stated above, they are used by the browser only to store the initial value.

$(“:checkbox”).get(0).checked = true;
// Is the same as $(":checkbox:first").prop(“checked”, true);

In jQuery 1.6, setting checked with

$(“:checkbox”).attr(“checked”, true);

would not check the checkbox because it was the property that needed to be set and all you were setting was the initial value.

However, once jQuery 1.6 was released, the jQuery team understood that it was not particularly useful to set something that the browser was only concerned with on page load. Therefore, in the interest of backwards compatibility and the usefulness of the .attr() method, we will continue to be able to get and set these boolean attributes with the .attr() method in jQuery 1.6.1.

The most common boolean attributes are checked, selected, disabled, and readOnly, but here is a full list of boolean attributes/properties that jQuery 1.6.1 supports dynamically getting and setting with .attr():

It is still recommended that .prop() be used when setting these boolean attributes/properties, but your code will continue working in jQuery 1.6.1 even if these use cases are not switched to use the .prop() method.

Below is a list of some attributes and properties and which method should normally be used when getting or setting them. This is the preferred usage, but the .attr() method will work in all attribute cases.

Note that some DOM Element properties are also listed below – but will only work with the new .prop() method.

Attribute/Property

.attr()

.prop()

accesskey

✓

align

✓

async

✓

✓

autofocus

✓

✓

checked

✓

✓

class

✓

contenteditable

✓

defaultValue

✓

draggable

✓

href

✓

id

✓

label

✓

location *

✓

✓

multiple

✓

✓

nodeName

✓

nodeType

✓

readOnly

✓

✓

rel

✓

selected

✓

✓

selectedIndex

✓

src

✓

style

✓

tabindex

✓

tagName

✓

title

✓

type

✓

width **

✓

* For example, with window.location
** If needed over .width()

Neither .attr() nor .prop() should be used for getting/setting value. Use the .val() method instead (although using .attr(“value”, “somevalue”) will continue to work, as it did before 1.6).

Summary of Preferred Usage

The .prop() method should be used for boolean attributes/properties and for properties which do not exist in html (such as window.location). All other attributes (ones you can see in the html) can and should continue to be manipulated with the .attr() method.

We’re nearing the first update to jQuery 1.6 – and we’re pleased to announce the release of the first release candidate! Barring any major bugs this should be the code that we end up shipping for jQuery 1.6.1 (which will be happening this week).

You can help us by dropping that code into your existing application and letting us know that if anything no longer works. Please file a bug and be sure to mention that you’re testing against jQuery 1.6.1 RC 1.

We want to encourage everyone from the community to try and get involved in contributing back to jQuery core. We’ve set up a full page of information dedicated towards becoming more involved with the team. The team is here and ready to help you help us!

Upgrading From 1.5.2 to 1.6.1

With the introduction of the new .prop() method and the changes to the .attr() method, jQuery 1.6 sparked a discussion about the difference between attributes and properties and how they relate to each other. It also came with some backwards compatibility issues that have been fixed in 1.6.1. When updating from 1.5.2 to 1.6.1, you should not have to change any code.

Below is a description of the changes to the Attributes module in jQuery 1.6 and 1.6.1, as well as the preferred usage of the .attr() method and the .prop() method. However, as previously stated, jQuery 1.6.1 will allow you to use .attr() just as it was used before in all situations.

What’s Changed

The changes to the Attributes module removed the ambiguity between attributes and properties, but caused some confusion in the jQuery community, since all versions of jQuery prior to 1.6 have handled attributes and properties in one method(.attr()). The old .attr() method had many bugs and was hard to maintain.

jQuery 1.6.1 comes with several bug fixes as well as an update to the Attributes module.

Specifically, boolean attributes such as checked, selected, readonly, and disabled in 1.6.1 will be treated just as they used to be treated in jQuery versions prior to 1.6. This means that code such as

will not need to be changed in 1.6.1 in order to work as previously expected.

To make the changes to .attr() in jQuery 1.6 clear, here are some examples of the use cases of .attr() that worked in previous versions of jQuery that should be switched to use .prop() instead:

.attr()

Proper .prop() usage

$(window).attr…

$(window).prop…

$(document).attr…

$(document).prop…

$(“:checkbox”).attr(“checked”, true);

$(“:checkbox”).prop(“checked”, true);

$(“option”).attr(“selected”, true);

$(“option”).prop(“selected”, true);

First, using the .attr() method on the window or document did not work in jQuery 1.6 because the window and document cannot have attributes. They contain properties (such as location or readyState) that should be manipulated with .prop() or simply with raw javascript. In jQuery 1.6.1, the .attr() will defer to the .prop() method for both the window and document instead of throwing an error.

Next, checked, selected, and other boolean attributes previously mentioned are receiving special treatment because of the special relationship between these attributes and their corresponding properties. Basically, an attribute is what you see in the html:

<input type=”checkbox” checked=”checked”>

Boolean attributes such as checked only set the default or initial value. In the case of a checkbox, the checked attribute sets whether the checkbox should be checked when the page loads.

Properties are what the browser uses to keep track of the current values. Normally, properties reflect their corresponding attributes (if they exist). This is not the case with boolean attributes. Boolean properties stay up to date when the user clicks a checkbox or selects an option in a select element. The corresponding boolean attributes do not. As was stated above, they are used by the browser only to store the initial value.

$(“:checkbox”).get(0).checked = true;
// Is the same as $(":checkbox:first").prop(“checked”, true);

In jQuery 1.6, setting checked with

$(“:checkbox”).attr(“checked”, true);

would not check the checkbox because it was the property that needed to be set and all you were setting was the initial value.

However, once jQuery 1.6 was released, the jQuery team understood that it was not particularly useful to set something that the browser was only concerned with on page load. Therefore, in the interest of backwards compatibility and the usefulness of the .attr() method, we will continue to be able to get and set these boolean attributes with the .attr() method in jQuery 1.6.1.

The most common boolean attributes are checked, selected, disabled, and readOnly, but here is a full list of boolean attributes/properties that jQuery 1.6.1 supports dynamically getting and setting with .attr():

It is still recommended that .prop() be used when setting these boolean attributes/properties, but your code will continue working in jQuery 1.6.1 even if these use cases are not switched to use the .prop() method.

Below is a list of some attributes and properties and which method should normally be used when getting or setting them. This is the preferred usage, but the .attr() method will work in all cases.

Attribute/Property

.attr()

.prop()

accesskey

✓

align

✓

async

✓

✓

autofocus

✓

✓

checked

✓

✓

class

✓

contenteditable

✓

draggable

✓

href

✓

id

✓

label

✓

location ( i.e. window.location )

✓

✓

multiple

✓

✓

readOnly

✓

✓

rel

✓

selected

✓

✓

src

✓

tabindex

✓

title

✓

type

✓

width ( if needed over .width() )

✓

Neither .attr() nor .prop() should be used for getting/setting value. Use the .val() method instead (although using .attr(“value”, “somevalue”) will continue to work, as it did before 1.6).

Summary of Preferred Usage

The .prop() method should be used for boolean attributes/properties and for properties which do not exist in html (such as window.location). All other attributes (ones you can see in the html) can and should continue to be manipulated with the .attr() method.

We want to encourage everyone from the community to try and get involved in contributing back to jQuery core. We’ve set up a full page of information dedicated towards becoming more involved with the team. The team is here and ready to help you help us!

In fact, we’re already getting started working on jQuery 1.7. We’re welcoming feature proposals for jQuery 1.7. If you have any suggestions please submit them using the aforementioned form.

jQuery 1.6 Change Log

Breaking Changes

In most releases we try to main compatibility with existing code. However, there are a few cases where jQuery 1.6 may require changes to existing code:

Case-mapping of data- attributes

jQuery 1.5 introduced a feature in the .data() method to automatically import any data- attributes that were set on the element and convert them to JavaScript values using JSON semantics. In jQuery 1.6 we have updated this feature to match the W3C HTML5 spec with regards to camel-casing data attributes that have embedded dashes. So for example in jQuery 1.5.2, an attribute of data-max-value="15" would create a data object of { max-value: 15 } but as of jQuery 1.6 it sets { maxValue: 15 }.

.prop(), .removeProp(), and .attr()

In the 1.6 release we’ve split apart the handling of DOM attributes and DOM properties into separate methods. The new .prop() method sets or gets properties on DOM elements, and .removeProp() removes properties. In the past, jQuery has not drawn a clear line between properties and attributes. Generally, DOM attributes represent the state of DOM information as retrieved from the document, such as the value attribute in the markup <input type="text" value="abc">. DOM properties represent the dynamic state of the document; for example if the user clicks in the input element above and types def the .prop("value") is abcdef but the .attr("value") remains abc.

In most cases, the browser treats the attribute value as the starting value for the property, but Boolean attributes such as checked or disabled have unusual semantics.

For example, consider the markup <input type="checkbox" checked>. The presence of the checked attribute means that the DOM .checked property is true, even though the attribute does not have a value. In the code above, the checked attribute value is an empty string (or undefined if no attribute was specified) but the checked property value is true.

Before jQuery 1.6, .attr("checked") returned the Boolean property value (true) but as of jQuery 1.6 it returns the actual value of the attribute (an empty string), which doesn’t change when the user clicks the checkbox to change its state.

There are several alternatives for checking the currently-checked state of a checkbox. The best and most performant is to use the DOM property directly, as in this.checked inside an event handler when this references the element that was clicked. In code that uses jQuery 1.6 or newer, the new method $(this).prop("checked") retrieves the same value as this.checked and is relatively fast. Finally, the expression $(this).is(":checked") works for all versions of jQuery.

CSS

Relative CSS

We’ve ported the functionality from the .animate() method, giving you the ability to update CSS properties using relative values. You can now prefix a CSS value with “+=” or “-=” to update the property relatively, in relation to the current value.

Data

Performance Improvements

Large performance improvements to .data() were achieved by improving the performance of event triggering. jQuery’s .data() method triggers getData and setData events which allow for greater levels of extensibility for plugins, improving how they’re triggered allows .data() to become even faster.

Effects

Synced Animations

In jQuery you can have multiple animations running simultaneously (even multiple on the same element, animating different properties). In 1.6 we’ve introduced an enhancement that ensures that all animations are synced to the same timer interval. This had the potential to create problems before as animations could become slightly out-of-sync (even by a couple milliseconds) resulting in slightly “off” animations.

Smoother Animations

Additionally jQuery is now using the new requestAnimationFrame method provided by browsers to make our animations even smoother. We can use this functionality to avoid calling timers and instead depend upon the browser to provide the best possible animation experience.

.promise()

Just like $.ajax() before it, $.animate() gets “deferred”. jQuery objects can now return a Promise to observe when all animations on a collection have completed:

Support

Traversing

find(), closest(), and is() now all take DOM elements and jQuery objects

In jQuery 1.6 we’ve ensured that find(), closest(), and is() can all take DOM elements and jQuery objects as arguments. This gives you alternatives for filtering sets of elements based upon the passed-in elements.

You can help us by dropping that code into your existing application and letting us know that if anything no longer works. Please file a bug and be sure to mention that you’re testing against jQuery 1.6 RC 1.

We want to encourage everyone from the community to try and get involved in contributing back to jQuery core. We’ve set up a full page of information dedicated towards becoming more involved with the team. The team is here and ready to help you help us!

Barely six months ago, we announced that we were adopting three plugins developed chiefly at Microsoft – Templating, Data Link, and Globalization – as official plugins, to be developed in accordance with the standards of and supported by the jQuery project. Today, we’d like to take an opportunity to share what we’ve learned in the interim and announce a change in course for these and the rest of jQuery’s “Official Plugins.”

There never has been a dedicated jQuery team for supporting Official Plugins. Prior to the adoption of Microsoft’s contributions, the plugins that the jQuery project supported – Color, Easing, bgiframe, Mousewheel, Metadata, and Cookie – were dead-simple, effective plugins for achieving a particular utilitarian end. They required little maintenance, stalwartly serving with little fuss from version to version of jQuery core. In recent months, as we noticed an uptick in questions related to the three new plugins, we realized there was a disconnect. Though development on beta versions of the plugins continued at Microsoft, the planned jQuery sub-team that was meant to collaborate with and adopt Microsoft’s work never formed.

As demand has grown, based on the existence of the beta versions of the plugins as well as promises made in the posts, we’ve sensed the rumbles, the confusion, and the confused exclamations: “I thought templating was going to be in 1.5!” Because of your concerns and ours, we’ve decided to eliminate the notion of Official Plugins altogether. It’s a difference that’s both semantic and symbolic, but this is its material impact:

Many of the original supported jQuery plugins (Color, Easing, and Mousewheel) will continue to be supported and maintained by the jQuery Core Dev Team. The Metadata plugin will be deprecated, in favor of similar functionality provided by jQuery 1.4.3 and above. The Cookie plugin will continue to be maintained by Klaus Hartl.

The jQuery UI project will take ownership over plugins on which it has a current or future dependency: Templating, Globalization, and bgiframe. The jQuery UI team plans to begin work anew on templating and globalization, starting with the normal process for UI plugins: Collaborative development on a spec. While some may perceive this as a setback, given existing progress on the current jquery-tmpl plugin, it is really an opportunity for us to work in tandem with the community — Microsoft included — to develop an implementation that will be effective and flexible. The “official plugins” Microsoft has been developing have always been in a beta state, subject to change and with significant revisions planned for the Beta 2 release, but we recognize (and appreciate) those of you who have jumped in and started to experiment and use them in your applications. The UI team is still in the early planning stages for the Templating and Globalization plugins, and we invite you to visit the planning wiki and share your thoughts about development.

Microsoft will continue to develop and support the Data Link plugin independently, and will take ownership of hosting the documentation for the existing plugins. In the short term, however, we’ll keep the documentation for these plugins on api.jquery.com, in order preserve a reference for anyone who needs it. For more on Microsoft’s plans for Data Link, please read their Official Plugins Update. We value Microsoft’s ongoing contribution to jQuery, providing developer time and financial support for a number of efforts, including the jQuery UI Grid and the jQuery conferences.

We realize that some of these details may seem in flux or merely organizational, but we know that it’s important to tell the community of changes like these as they’re happening so that you can make the best decisions for your applications as soon as possible. We hope you understand why we’ve had to make these shifts and encourage you to get involved and help us push these important projects along!

Addendum: So Why Weren’t Templates in 1.5?

Though we initially announced that the jquery-tmpl plugin would be part of jQuery Core in version 1.5, the plugin was, as it is today, still in the Beta 1 stage. Thus, when the time came last December to really evaluate new features for 1.5, it was not really considered ready for inclusion. Given what we’ve explained above, we hope it’s clear that we don’t plan to include templating directly in Core in the near future. The jQuery UI Templating plugin will be a standalone plugin with no dependencies on any other part of jQuery UI, and will become the only templating solution “officially” supported by the project, though jQuery will, of course, continue to work with any JavaScript templating engine that spits out good, old-fashioned strings of HTML.