jQuery 1.6.1 RC1 was released today, helping resolve the .attr() backwards compatibility issue along with a few other fixes.

jQuery.com released a nice chart on what .attr() and .prop() should be used for going forward from jQuery 1.6+. I thought I’d publish this for future reference. Note that all properties can still be accessed via 1.6.1, but not necessarily via 1.6.

According to jQuery.com 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 released a significant change to the way it handles DOM attributes and properties.

Take for example in version 1.5.2, the following code would return isCheckedAttr as “true”.

<input type="checkbox" checked="checked" />

<script type="text/javascript">
var isCheckedAttr = $('input').attr("checked");
</script>

In version 1.6 the addition of .prop() and .removeProp() changes what the .attr() method will return when referencing DOM properties. The following example will return isCheckedAttr as “” and isCheckedProp as “true”. Notice 1.5.2 returned “true” instead of “” for isCheckedAttr.

<input type="checkbox" checked="checked" />

<script type="text/javascript">
var isCheckedAttr = $('input').attr("checked");
var isCheckedProp = $('input').prop("checked");
</script>

Now… check this out. In HTML and XHTML you can set the checked property as an attribute. This example in jQuery 1.6 will return “checked” for isCheckedAttr (remember 1.5.2 returned “true”). The isCheckedProp will still return “true”.

<input type="checkbox" checked="checked" />

<script type="text/javascript">
var isCheckedAttr = $('input').attr("checked");
var isCheckedProp = $('input').prop("checked");
</script>

Try this case on for size… If I don’t set the checked attribute or property isCheckedAttr will always return “undefined” (not an empty string) and isCheckedProp will return false (until I click the checkbox which will make it true).

<input type="checkbox" />

<script type="text/javascript">
var isCheckedAttr = $('input').attr("checked");
var isCheckedProp = $('input').prop("checked");
</script>

This all makes sense, though a bit confusing since the attribute is basically converted into a property at DOM load making upgrading to version 1.6 much more difficult than most recent version upgrades, so be sure to do some extra testing.

Okay, ready for this, one more item to throw at you… if I’m reading the bug ticket right, if an attribute does not exist but the property does, the .attr() will bring back the property boolean value as the attribute in the next release (probably 1.6.1). This appears to be a backwards compatibility fix for reading properties, but not setting them.

UPDATE 5/9/2011: appendTo, a jQuery company I highly respect, released an executive brief on jQuery 1.6 stating that it recommends not upgrading to jQuery 1.6 until 1.6.1 is released. This version will return either the name of the attribute (if true) or undefined (if false) for .attr(BooleanAttribute) and could be released as early as Tuesday, May 10, 2011. It also has a good read on the rest of the features new to this version.

John Resig also released an example:

“Let’s pretend we’re working with a checkbox that isn’t checked at all:

<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

The user then checks the checkbox OR we set the check by doing .prop(“checked”, true) OR we set the check by doing [0].checked = true, the result would be:

$("#c").attr("checked") => true // 1.5.2
$("#c").attr("checked") => undefined // 1.6
$("#c").attr("checked") => "checked" // 1.6.1

Note that if we had done .attr(“checked”, “checked”) OR .attr(“checked”, true) to set the checked property then .attr(“checked”) would’ve returned “checked” in both 1.6 and 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.”

Lately I’ve had to deal with jQuery conflicting with Prototype.

For starters I was forced to upgrade from jQuery 1.4.2 to 1.5.2 to fix a conflict when doing clones.

But of course there’s always the ‘$’ conflict. So I wanted to come up with a slick way of keeping the ‘$’ alias available for use by jQuery code.

For starters the existing code looks like this:

<script src="prototype.js" type="text/javascript"></script>
<script src="jQuery.min.js" type="text/javascript"></script>
<script type="text/javascript">
	jQuery.noConflict();
	jQuery(document).ready(function(){
		/* js code here */
	});
</script>

The ‘jQuery.noConflict()’ statement kills off the jQuery ‘$’ alias for me. So to have ‘$’ available for my use I wrapped everything around a Self-Invoking Anonymous Function looking like this:

(function( $ ) {
	$(document).ready(function() {
		/* js code here */
	});
})(jQuery);

https://gist.github.com/firefighter990/5340332

Notice that the jQuery object is now being passed in via the $ argument inside a JavaScript closure. Thus everything I do inside the closure will not conflict with any other library.