JQuery 1.6 released
blog.jquery.com
blog.jquery.com
EDIT: It looks like the freeze on IE6 might be caused by FancyBox (http://fancybox.net/ ). Though it didn't freeze with any previous version of jQuery.
<html>
<head>
<script src="http://code.jquery.com/jquery-1.6.min.js"></script>
</head>
<body>
<script>
$('body').append(
'<span></span>',
'<span></span>',
'<span></span>'
)
</script>
</body>
</html>
Note the inner loop is clobbering the outer loop's "i" variable.
We're going to have a 1.6.1 release within the week. Thank you for your bug report!
Now we just have to wait for jQuery 1.6.1.
This helps us to help you! And remember, the future in San Dimas is excellent... so be excellent to each other.
(1) Except, you know, ie 7 and ie 8. So... half the internet.
The bug and commit are as follows: http://bugs.jquery.com/ticket/9079 https://github.com/jquery/jquery/commit/a9d9f8c5422f171d9c45...
You can start using this code right now with the following version of jQuery: http://code.jquery.com/jquery-git.js
Hope this helps!
Eg
$(optionElement)
.prop('selected', true)
.attr('selected'); // undefined in 1.6, "selected" in 1.6.1 <input type="checkbox" id="c"/>
$("#c").attr("checked") => false // 1.5.2
$("#c").attr("checked") => undefined // 1.6
$("#c").attr("checked") => undefined // 1.6.1
$("#c").attr("checked") => true // 1.5.2
$("#c").attr("checked") => undefined // 1.6
$("#c").attr("checked") => "checked" // 1.6.1
In short: In jQuery 1.6.1 .attr(BooleanAttribute) now returns either the name of the attribute (if true) or undefined (if false). Which is consistent with the rest of the API and with the DOM itself.
I should note that all of this is a moot point if you're using .prop("checked") - that will just return true/false consistently based upon the current checked state of the checkbox.
List compiled (partially) from http://stackoverflow.com/questions/706384/boolean-html-attri...
Really, most people reading the changelog care about "how do I make my existing code work with this"--and the details listed are conceptual, but not all practically relevant.
$.fn.setAttr = function(attr, bool) {
if(bool)
this.attr(attr, attr);
else
this.removeAttr(attr);
return this;
}
$.fn.disabled = function(bool) {
return this.setAttr('disabled', bool);
}
$.fn.checked = function(bool) {
return this.setAttr('checked', bool);
}
I think you should add two more helpers (like .val):
.checked() and .disabled() - with no parameters they return a boolean, and with a parameter you can pass in true/false to set the property.
Those two are probably the most commonly used properties and if you had them most people could probably ignore attr vs prop.
The doc reads: "The difference between attributes and properties can be important in specific situations. Before jQuery 1.6, the .attr() method sometimes took property values into account when retrieving some attributes, which could cause inconsistent behavior. As of jQuery 1.6, the .prop() method provides a way to explicitly retrieve property values, while .attr() only retrieves attributes.
For example, consider a DOM element defined by the HTML markup <input type="checkbox" checked="checked" />..."
The docs then go into the example on this thread.
Personally, I think that if this is the only specific situation we can think of, it probably wasn't worth introducing a method that parallels attr. As a higher-level library, jQuery ideally will do the right thing without the calling code thinking too hard about exactly what mechanism it's using to do it. (It does this with cross-browser issues, for example.) This was the case already with .attr("checked")...
So if I'm approaching jQuery for the first time, do I use prop or attr, and why?
I don't see how prop() is any different than just using data().
It's understandable though, because helpers and abstractions add bloat and latency to interactions with the various DOM interfaces. And this latency is the price we have to pay for the benefits these abstractions give us - which include a unified interface to the DOM of many browsers.
The balance of speed vs convenience is very difficult for frameworks like jQuery looking to work for as many people as possible... if you want the convenience at the sacrifice of speed or conversely prefer the speed to the convenience you have one option: build a library specific to your app or your needs.
The rest of us will use jQuery ;)
Although I'm honestly a bit confused on their explanation of .prop and .attr now... Maybe I should just re-read it slower, or give myself a little more time to wake up. Unless someone would care to explain it in simpler terms for me. ;)
Additionally there is the concept of DOM object properties - these are properties that exist solely on the JavaScript implementation of the DOM node. For example .selectedIndex is a property that exists on select elements but isn't actually an attribute.
Previously jQuery conflated properties and attributes (sometimes using one, sometimes using another). Unfortunately, while this creates a result that is perhaps slightly more user friendly, it also creates lots of weird edge cases that are hard to define (such as the cases relating to value, outlined in the blog post). For this reason we've split apart the functionality into two realms: .attr()/.removeAttr() and .prop()/.removeProp().
How does this affect you and your applications? It probably (hopefully) won't. Continuing to use .attr()/.removeAttr() will probably be just fine. Using other jQuery helpers, like .val(), will help to cover over the last remaining bits of weirdness that exist.
In short: Nothing much of serious consequence will likely change, but we're going to actively watch the response from this release and make sure we act appropriately, and swiftly, should major problems come up.
Your blog post calls them "breaking changes" for a reason though. Code that does `if ($elem.attr('checked'))` needs to be rewritten to use .prop when upgrading. Saying "It probably (hopefully) won't [affect your applications]" is slightly contradictory.
I'll go through my code a bit to see if I need to make any changes, but it doesn't seem that way now that it's all more clarified for me.. Besides a couple cases where I check the state of checkboxes. Thanks again for your help, and for jQuery in general. It's made my life/job easier in a completely indescribable way. (I used to be afraid of Javascript.)
Saying that it probably won't affect existing applications is just misleading. 1.6 fundamentally changes the behaviour of attr(), which is a very complicated and commonly used method. Furthermore, there's really no point in this if you're not going to encourage people to move to prop() rather than attr().
The messages coming from jQuery about this change seem very vague to me. If you're going to spring this kind of change on your users then they need to understand what it is that you've changed and why it's a good thing (I think it is, by the way), which one documented example and a hand-wavy assurance that it might probably be mostly OK doesn't do.
If you have: <input id="test" type="text" value="initial" />
On load, the page should show for $("#test") .prop("value") = "initial", .attr("value") = "initial"
Then, if you type in "current" into the 'test' input box, the page should show: .prop("value") = "current", .attr("value") = "initial" without any other events taking place that would update the value.
This is part of why I think .prop vs .attr is a regression. It makes me think twice before I use either--even if this is closer to how the DOM actually behaves, the point of jQuery used to be that it could hide those inane details from me.
Bottom line: use prop().