jQuery 1.6.1 RC 1 Released

Posted on by

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 get the code from the jQuery CDN:

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

$(“:checkbox”).attr(“checked”, true);
$(“option”).attr(“selected”, true);
$(“input”).attr(“readonly”, true);
$(“input”).attr(“disabled”, true);

or even:

if ( $(“:checkbox”).attr(“checked”) ) { /* Do something */ }

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():

autofocus, autoplay, async, checked, controls, defer, disabled,
hidden, loop, multiple, open, readonly, required, scoped, selected

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.

jQuery 1.6.1 RC 1 Change Log

The current change log of the 1.6.1 RC 1 release.

Attributes

  • #9079: .attr(“selected”) returns non-useful value in 1.6
  • #9089: 1.6 atrr() Inconsistant in IE7,8
  • #9094: Issue with jQuery 1.6: Can’t uncheck checkboxes
  • #9103: .attr(‘foo’, true) not setting related DOM property
  • #9123: Strange behavior of attr method when generate input element.
  • #9129: jQuery does not support enumerated attributes such as contenteditable
  • #9191: attr checked bug on radio

Data

  • #9124: Changes to $.data illogical in certain case
  • #9126: jquery breaks on use strict

Deferred

  • #9104: Returning null or undefined in a pipe filter function causes an exception

Effects

  • #9074: Cannot animate position and opacity at same time
  • #9100: Order of hide() callbacks has changed

Event

  • #9069: when hover over a child of an element, mouseleave fires when using live or delegate

Manipulation

  • #9072: jQuery 1.6 Crashes IE 6

Queue

  • #9147: Variable tmp in promise implicitly declared?

Selector

  • #7341: Slow .add() in IE
  • #9096: Selector or find bug in jQuery 1.6
  • #9154: :reset pseudo-selector broken

Support

  • #8763: Unhandled exception: document.defaultView.getComputedStyle(div, null) is null (FF, hidden iframe)
  • #9109: support.boxModel now false in IE6 even when not in quirks mode

26 thoughts on “jQuery 1.6.1 RC 1 Released”

  2. Razican on said:

    It’s a great improvement! but I was thinking of the .attr(‘disabled’, true). Should we continue using that or .prop()?

  4. alexander farkas on said:

    @Razican

    The table attr/prop table is a little bit misleading. There might be often some rules, to say that you have to use prop or attr with a specific attribute. But in some cases, you can use both and in some other cases it really depends on what you want to get.

    The HTML specification distinguishes not only between content attributes (HTML attributes) and idl attributes (properties), but also between reflecting and non reflecting. (http://www.w3.org/TR/html5/common-dom-interfaces.html#reflect)

    The checked, value and selected-attributes are non reflecting, so you have to use always prop.

    Most attributes like name (see @ http://www.w3.org/TR/html5/association-of-controls-and-forms.html#attr-fe-name), disabled (http://www.w3.org/TR/html5/association-of-controls-and-forms.html#attr-fe-disabled), id, title, required, controls etc. are reflecting, which means you can use attr/removeAttr or prop (and for those attributes there should be no jQuery rule, which says you have to use prop or attr).

    In case of the type attribute, the table seems to be a little bit odd. The property always returns the “calculated” type, while the content attribute might return something stupid.

    For example:

    //attr returns undefined and prop returns correctly text

    //or

    // attr returns TEXT and prop returns text

  6. Prestaul on said:

    Thanks for listening to your users and restoring attr. It is really nice to know that we aren’t just talking to ourselves. Great response, great release!

  7. Cristóvão Morgado on said:

    Nice i’ve been battling with query mobile problems in the checked prop problem…
    Hope everything works out as query + mobile + template are my daily tools :-)

  8. Alistair B on said:

    I am not convinced of the benefit of splitting out prop and attr. Isn’t jQuery meant to abstract away small nuances like this?

    Still, it is nice to have attr working across the board as o per 1.5, thanks.

    Also, if you could clarify the preferred usage and the benefits of prop that would be useful. Pretty much all the properties you list (eg ‘multiple’) can exist in the HTML so I am confused.

  9. alexander farkas on said:

    @Alistair B

    There was absolutley a need for splitting those two things, because jQuery can’t simply decide what kind of attribute the developer wants to get/set.

    But you are somehow also right: The old $.attr was designed to always use the property, if a property is available. Now there is the $.prop for this and $.attr is a mixture of old attr and a simple setAttribute. And although old jQuery used the property for setting the title attribute, they are now saying, I have to use $.attr and not $.prop. (a little bit confusing).

    From my standpoint, it would have been better, to introduce two new methods (prop and htmlAttr) and $.attr should only route to those new methods using the old distinction logic.

  10. timmywil on said:

    @Alistair

    Almost everything in the table is an attribute as well as a property. As you noted, you can see multiple in the html, but there’s also a property called multiple that you can’t see and that’s what you really want to set. The attribute itself only sets the default value. You want to set the current value, which is only settable by setting the property (which attr now does as well, but it will be faster if you use prop). This is only true of boolean attributes/properties. This is all explained in the post though.

    @afarkas

    I think you’re making it more complicated than it needs to be. attr was used to set the title in the past and attr should be used to set the title now. Only now, title is set in a way that complies with the spec and overall is at least twice as fast. I wouldn’t say the old attr was designed to always use the property, nor that the new is a mixture of the old and a “simple” setAttribute. Another function was not needed.

  11. alexander farkas on said:

    1. specification
    There is no part of the HTML specification, which says, that you should change the title attribute using setAttribute and that you are not allowed to set the title using the property/attribute idl.

    The specification describes how reflection works and this means, that a developer can choose to use either the property or the content attribute, in those cases. Most of the attributes in the table above are reflecting attributes and there is no reason, why a developer should prefer attr over prop in those cases.

    2. performance
    Yes 1.6.x $.attr is faster than jQuery 1.5.x $.attr, but this has nothing to do with property access versus content attribute access. In fact, setting/getting the title attribute using $.prop is about 20%-30% faster than setting/getting title with $.attr in any browser. http://jsperf.com/prop-vs-attr

    It’s absolutley O.k. to say attr worked with title in the past and also works now. But you say: Use $.attr for the title attribute and don’t use $.prop for the title attribute.

    But $.prop also complies to the spec and is faster and this is my problem.

    In case of the type attribute, I already made clear, that there will be some problems to use $.attr and you can only solve these issues by using prop. And no, I don’t want you to use the property in $.attr for getting the type attribute.

  12. Marco Pivetta on said:

    Still having issues with these changes, but didn’t have the chance to track down all issues coming from dependent libraries.
    Anyway, this looks great and makes a lot more sense! Thank you for the hard work you’re doing!

  13. kerwinche on said:

    scrollTop() and scrollLeft() has something problem in IE7 , I don’t know why scrollTop(),scrollLeft can not be read by ie7 and other explorer is no this problem…

  14. kerwinche on said:

    And it can be success run in jquery1.52 ,but when I upgrade to 1.6 it fail

  15. Kaitlyn on said:

    I haven’t looked at the code changes, so I have no sense of the overhead introduced.. but shouldn’t this attr “fix” NOT have been implmented?

    You guys made a decision to introduce prop() and in many ways it makes sense – though sucks it was introduced late…

    But now people will continue to use attr() for everything, and the code now will have some overhead to check/call prop() for this “special case”…

  16. Nao on said:

    @Kaitlyn

    There are two ways to see it. With jQuery 1.6, you’ll end up with a lot of plugins that aren’t compatible as long as they’re not updated — and a lot of websites that will break because they’ll upgrade to 1.6 without making sure to fix their code.
    With jQuery 1.6.1, updated plugins will use .prop() and thus not have any performance impacts, while outdated plugins will still work. Websites will keep working, too. I agree that it should have been done this way in v1.6. It takes balls to break a popular functionality when your library is used by millions. I’m impressed that jQuery did it — but I’m even more impressed that they went back and chose the wiser solution.

  17. Stun on said:

    Thanks a lot!
    I found a bit problem…
    jq1.6,jq1.6.1 have some memory leak on only IE9 ..
    other browser is OK (firefox,chrome, IE8 tested).

    1.load page!!! — 33MB
    2.F5 key press(reload) — 36MB
    3.F5 key press(reload) — 39MB
    …. increased allway!!!

  19. Yann Dìnendal on said:

    Cool! Much better without the breaking changes of 1.6. I only had a problem with a .attr(“defaultValue”) but it is indeed better with .prop().

  21. Radu Badea on said:

    What about ‘selectedIndex’ of a select control. It doesen’t seem to work even with version 1.6.1 but with versions below 1.6 it is working as expected.

  26. rahul on said:

    Hi, the table above is bit misleading. I’ve jQuery 1.6.4, when i tried attr(‘type’) it gives undefined but with prop i got ‘select-one’. Whereas in table type is ticked in attr column.