Related
So jQuery 1.6 has the new function prop().
$(selector).click(function(){
//instead of:
this.getAttribute('style');
//do i use:
$(this).prop('style');
//or:
$(this).attr('style');
})
or in this case do they do the same thing?
And if I do have to switch to using prop(), all the old attr() calls will break if i switch to 1.6?
UPDATE
selector = '#id'
$(selector).click(function() {
//instead of:
var getAtt = this.getAttribute('style');
//do i use:
var thisProp = $(this).prop('style');
//or:
var thisAttr = $(this).attr('style');
console.log(getAtt, thisProp, thisAttr);
});
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.6.0/jquery.min.js"></script>
<div id='id' style="color: red;background: orange;">test</div>
(see also this fiddle: http://jsfiddle.net/maniator/JpUF2/)
The console logs the getAttribute as a string, and the attr as a string, but the prop as a CSSStyleDeclaration, Why? And how does that affect my coding in the future?
Update 1 November 2012
My original answer applies specifically to jQuery 1.6. My advice remains the same but jQuery 1.6.1 changed things slightly: in the face of the predicted pile of broken websites, the jQuery team reverted attr() to something close to (but not exactly the same as) its old behaviour for Boolean attributes. John Resig also blogged about it. I can see the difficulty they were in but still disagree with his recommendation to prefer attr().
Original answer
If you've only ever used jQuery and not the DOM directly, this could be a confusing change, although it is definitely an improvement conceptually. Not so good for the bazillions of sites using jQuery that will break as a result of this change though.
I'll summarize the main issues:
You usually want prop() rather than attr().
In the majority of cases, prop() does what attr() used to do. Replacing calls to attr() with prop() in your code will generally work.
Properties are generally simpler to deal with than attributes. An attribute value may only be a string whereas a property can be of any type. For example, the checked property is a Boolean, the style property is an object with individual properties for each style, the size property is a number.
Where both a property and an attribute with the same name exists, usually updating one will update the other, but this is not the case for certain attributes of inputs, such as value and checked: for these attributes, the property always represents the current state while the attribute (except in old versions of IE) corresponds to the default value/checkedness of the input (reflected in the defaultValue / defaultChecked property).
This change removes some of the layer of magic jQuery stuck in front of attributes and properties, meaning jQuery developers will have to learn a bit about the difference between properties and attributes. This is a good thing.
If you're a jQuery developer and are confused by this whole business about properties and attributes, you need to take a step back and learn a little about it, since jQuery is no longer trying so hard to shield you from this stuff. For the authoritative but somewhat dry word on the subject, there's the specs: DOM4, HTML DOM, DOM Level 2, DOM Level 3. Mozilla's DOM documentation is valid for most modern browsers and is easier to read than the specs, so you may find their DOM reference helpful. There's a section on element properties.
As an example of how properties are simpler to deal with than attributes, consider a checkbox that is initially checked. Here are two possible pieces of valid HTML to do this:
<input id="cb" type="checkbox" checked>
<input id="cb" type="checkbox" checked="checked">
So, how do you find out if the checkbox is checked with jQuery? Look on Stack Overflow and you'll commonly find the following suggestions:
if ( $("#cb").attr("checked") === true ) {...}
if ( $("#cb").attr("checked") == "checked" ) {...}
if ( $("#cb").is(":checked") ) {...}
This is actually the simplest thing in the world to do with the checked Boolean property, which has existed and worked flawlessly in every major scriptable browser since 1995:
if (document.getElementById("cb").checked) {...}
The property also makes checking or unchecking the checkbox trivial:
document.getElementById("cb").checked = false
In jQuery 1.6, this unambiguously becomes
$("#cb").prop("checked", false)
The idea of using the checked attribute for scripting a checkbox is unhelpful and unnecessary. The property is what you need.
It's not obvious what the correct way to check or uncheck the checkbox is using the checked attribute
The attribute value reflects the default rather than the current visible state (except in some older versions of IE, thus making things still harder). The attribute tells you nothing about the whether the checkbox on the page is checked. See http://jsfiddle.net/VktA6/49/.
I think Tim said it quite well, but let's step back:
A DOM element is an object, a thing in memory. Like most objects in OOP, it has properties. It also, separately, has a map of the attributes defined on the element (usually coming from the markup that the browser read to create the element). Some of the element's properties get their initial values from attributes with the same or similar names (value gets its initial value from the "value" attribute; href gets its initial value from the "href" attribute, but it's not exactly the same value; className from the "class" attribute). Other properties get their initial values in other ways: For instance, the parentNode property gets its value based on what its parent element is; an element always has a style property, whether it has a "style" attribute or not.
Let's consider this anchor in a page at http://example.com/testing.html:
<a href='foo.html' class='test one' name='fooAnchor' id='fooAnchor'>Hi</a>
Some gratuitous ASCII art (and leaving out a lot of stuff):
+−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+
| HTMLAnchorElement |
+−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+
| href: "http://example.com/foo.html" |
| name: "fooAnchor" |
| id: "fooAnchor" |
| className: "test one" |
| attributes: |
| href: "foo.html" |
| name: "fooAnchor" |
| id: "fooAnchor" |
| class: "test one" |
+−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+
Note that the properties and attributes are distinct.
Now, although they are distinct, because all of this evolved rather than being designed from the ground up, a number of properties write back to the attribute they derived from if you set them. But not all do, and as you can see from href above, the mapping is not always a straight "pass the value on", sometimes there's interpretation involved.
When I talk about properties being properties of an object, I'm not speaking in the abstract. Here's some non-jQuery code:
var link = document.getElementById('fooAnchor');
alert(link.href); // alerts "http://example.com/foo.html"
alert(link.getAttribute("href")); // alerts "foo.html"
(Those values are as per most browsers; there's some variation.)
The link object is a real thing, and you can see there's a real distinction between accessing a property on it, and accessing an attribute.
As Tim said, the vast majority of the time, we want to be working with properties. Partially that's because their values (even their names) tend to be more consistent across browsers. We mostly only want to work with attributes when there is no property related to it (custom attributes), or when we know that for that particular attribute, the attribute and the property are not 1:1 (as with href and "href" above).
The standard properties are laid out in the various DOM specs:
DOM2 HTML (largely obsolete, see the HTML spec instead)
DOM2 Core (obsolete)
DOM3 Core (obsolete)
DOM4
These specs have excellent indexes and I recommend keeping links to them handy; I use them all the time.
Custom attributes would include, for instance, any data-xyz attributes you might put on elements to provide meta-data to your code (now that that's valid as of HTML5, as long as you stick to the data- prefix). (Recent versions of jQuery give you access to data-xyz elements via the data function, but that function is not just an accessor for data-xyz attributes [it does both more and less than that]; unless you actually need its features, I'd use the attr function to interact with data-xyz attribute.)
The attr function used to have some convoluted logic around getting what they thought you wanted, rather than literally getting the attribute. It conflated the concepts. Moving to prop and attr was meant to de-conflate them. Briefly in v1.6.0 jQuery went too far in that regard, but functionality was quickly added back to attr to handle the common situations where people use attr when technically they should use prop.
This change has been a long time coming for jQuery. For years, they've been content with a function named attr() that mostly retrieved DOM properties, not the result you'd expect from the name. The segregation of attr() and prop() should help alleviate some of the confusion between HTML attributes and DOM properties. $.fn.prop() grabs the specified DOM property, while $.fn.attr() grabs the specified HTML attribute.
To fully understand how they work, here's an extended explanation on the difference between HTML attributes and DOM properties.:
HTML Attributes
Syntax:
<body onload="foo()">
Purpose:
Allows markup to have data associated with it for events, rendering, and other purposes.
Visualization:
The class attribute is shown here on the body. It's accessible through the following code:
var attr;
attr = document.body.getAttribute("class");
//IE 8 Quirks and below
attr = document.body.getAttribute("className");
Attributes are returned in string form and can be inconsistent from browser to browser. However, they can be vital in some situations. As exemplified above, IE 8 Quirks Mode (and below) expects the name of a DOM property in get/set/removeAttribute instead of the attribute name. This is one of many reasons why it's important to know the difference.
DOM Properties
Syntax:
document.body.onload = foo;
Purpose:
Gives access to properties that belong to element nodes. These properties are similar to attributes, but are only accessible through JavaScript. This is an important difference that helps clarify the role of DOM properties. Please note that attributes are completely different from properties, as this event handler assignment is useless and won't receive the event (body doesn't have an onload event, only an onload attribute).
Visualization:
Here, you'll notice a list of properties under the "DOM" tab in Firebug. These are DOM properties. You'll immediately notice quite a few of them, as you'll have used them before without knowing it. Their values are what you'll be receiving through JavaScript.
Documentation
JavaScript: The Definitive Guide by
David Flanagan
HTML Attributes,
Mozilla Dev Center
DOM Element Properties, Mozilla Dev Center
Example
HTML: <textarea id="test" value="foo"></textarea>
JavaScript: alert($('#test').attr('value'));
In earlier versions of jQuery, this returns an empty string. In 1.6, it returns the proper value, foo.
Without having glanced at the new code for either function, I can say with confidence that the confusion has more to do with the difference between HTML attributes and DOM properties, than with the code itself. Hopefully, this cleared some things up for you.
-Matt
A property is in the DOM; an attribute is in the HTML that is parsed into the DOM.
Further detail
If you change an attribute, the change will be reflected in the DOM (sometimes with a different name).
Example: Changing the class attribute of a tag will change the className property of that tag in the DOM (That's because class is already used).
If you have no attribute on a tag, you still have the corresponding DOM property with an empty or a default value.
Example: While your tag has no class attribute, the DOM property className does exist with a empty string value.
edit
If you change the one, the other will be changed by a controller, and vice versa.
This controller is not in jQuery, but in the browser's native code.
It's just the distinction between HTML attributes and DOM objects that causes a confusion. For those that are comfortable acting on the DOM elements native properties such a this.src this.value this.checked etc, .prop is a very warm welcome to the family. For others, it's just an added layer of confusion. Let's clear that up.
The easiest way to see the difference between .attr and .prop is the following example:
<input blah="hello">
$('input').attr('blah'): returns 'hello' as expected. No suprises here.
$('input').prop('blah'): returns undefined -- because it's trying to do [HTMLInputElement].blah -- and no such property on that DOM object exists. It only exists in the scope as an attribute of that element i.e. [HTMLInputElement].getAttribute('blah')
Now we change a few things like so:
$('input').attr('blah', 'apple');
$('input').prop('blah', 'pear');
$('input').attr('blah'): returns 'apple' eh? Why not "pear" as this was set last on that element. Because the property was changed on the input attribute, not the DOM input element itself -- they basically almost work independently of each other.
$('input').prop('blah'): returns 'pear'
The thing you really need to be careful with is just do not mix the usage of these for the same property throughout your application for the above reason.
See a fiddle demonstrating the difference: http://jsfiddle.net/garreh/uLQXc/
.attr vs .prop:
Round 1: style
<input style="font:arial;"/>
.attr('style') -- returns inline styles for the matched element i.e. "font:arial;"
.prop('style') -- returns an style declaration object i.e. CSSStyleDeclaration
Round 2: value
<input value="hello" type="text"/>
$('input').prop('value', 'i changed the value');
.attr('value') -- returns 'hello' *
.prop('value') -- returns 'i changed the value'
* Note: jQuery for this reason has a .val() method, which internally is equivalent to .prop('value')
TL;DR
Use prop() over attr() in the majority of cases.
A property is the current state of the input element. An attribute is the default value.
A property can contain things of different types. An attribute can only contain strings
Dirty checkedness
This concept provides an example where the difference is observable: http://www.w3.org/TR/html5/forms.html#concept-input-checked-dirty
Try it out:
click the button. Both checkboxes got checked.
uncheck both checkboxes.
click the button again. Only the prop checkbox got checked. BANG!
$('button').on('click', function() {
$('#attr').attr('checked', 'checked')
$('#prop').prop('checked', true)
})
<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script>
<label>attr <input id="attr" type="checkbox"></label>
<label>prop <input id="prop" type="checkbox"></label>
<button type="button">Set checked attr and prop.</button>
For some attributes like disabled on button, adding or removing the content attribute disabled="disabled" always toggles the property (called IDL attribute in HTML5) because http://www.w3.org/TR/html5/forms.html#attr-fe-disabled says:
The disabled IDL attribute must reflect the disabled content attribute.
so you might get away with it, although it is ugly since it modifies HTML without need.
For other attributes like checked="checked" on input type="checkbox", things break, because once you click on it, it becomes dirty, and then adding or removing the checked="checked" content attribute does not toggle checkedness anymore.
This is why you should use mostly .prop, as it affects the effective property directly, instead of relying on complex side-effects of modifying the HTML.
All is in the doc:
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() retrieves attributes.
So use prop!
attributes are in your HTML text document/file (== imagine this is the result of your html markup parsed), whereas
properties are in HTML DOM tree (== basically an actual property of some object in JS sense).
Importantly, many of them are synced (if you update class property, class attribute in html will also be updated; and otherwise). But some attributes may be synced to unexpected properties - eg, attribute checked corresponds to property defaultChecked, so that
manually checking a checkbox will change .prop('checked') value, but will not change .attr('checked') and .prop('defaultChecked') values
setting $('#input').prop('defaultChecked', true) will also change .attr('checked'), but this will not be visible on an element.
Rule of thumb is: .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. (http://blog.jquery.com/2011/05/10/jquery-1-6-1-rc-1-released/)
And here is a table that shows where .prop() is preferred (even though .attr() can still be used).
Why would you sometimes want to use .prop() instead of .attr() where latter is officially adviced?
.prop() can return any type - string, integer, boolean; while .attr() always returns a string.
.prop() is said to be about 2.5 times faster than .attr().
.attr():
Get the value of an attribute for the first element in the set of matched elements.
Gives you the value of element as it was defined in the html on page load
.prop():
Get the value of a property for the first element in the set of matched elements.
Gives the updated values of elements which is modified via javascript/jquery
Usually you'll want to use properties.
Use attributes only for:
Getting a custom HTML attribute (since it's not synced with a DOM property).
Getting a HTML attribute that doesn't sync with a DOM property, e.g. get the "original value" of a standard HTML attribute, like <input value="abc">.
attributes -> HTML
properties -> DOM
Before jQuery 1.6 , the attr() method sometimes took property values into account when retrieving attributes, this caused rather inconsistent behavior.
The introduction of the prop() method provides a way to explicitly retrieve property values, while .attr() retrieves attributes.
The Docs:
jQuery.attr()
Get the value of an attribute for the first element in the set of matched elements.
jQuery.prop()
Get the value of a property for the first element in the set of matched elements.
One thing .attr() can do that .prop() can't: affect CSS selectors
Here's an issue I didn't see in the other answers.
CSS selector [name=value]
will respond to .attr('name', 'value')
but not always to .prop('name', 'value')
.prop() affects only a few attribute-selectors
input[name] (thanks #TimDown)
.attr() affects all attribute-selectors
input[value]
input[naame]
span[name]
input[data-custom-attribute] (neither will .data('custom-attribute') affect this selector)
Gently reminder about using prop(), example:
if ($("#checkbox1").prop('checked')) {
isDelete = 1;
} else {
isDelete = 0;
}
The function above is used to check if checkbox1 is checked or not, if checked: return 1; if not: return 0. Function prop() used here as a GET function.
if ($("#checkbox1").prop('checked', true)) {
isDelete = 1;
} else {
isDelete = 0;
}
The function above is used to set checkbox1 to be checked and ALWAYS return 1. Now function prop() used as a SET function.
Don't mess up.
P/S: When I'm checking Image src property. If the src is empty, prop return the current URL of the page (wrong), and attr return empty string (right).
1) A property is in the DOM; an attribute is in the HTML that is
parsed into the DOM.
2) $( elem ).attr( "checked" ) (1.6.1+) "checked" (String) Will
change with checkbox state
3) $( elem ).attr( "checked" ) (pre-1.6) true (Boolean) Changed
with checkbox state
Mostly we want to use for DOM object rather then custom attribute
like data-img, data-xyz.
Also some of difference when accessing checkbox value and href
with attr() and prop() as thing change with DOM output with
prop() as full link from origin and Boolean value for checkbox
(pre-1.6)
We can only access DOM elements with prop other then it gives undefined
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.6.0/jquery.min.js"></script>
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>prop demo</title>
<style>
p {
margin: 20px 0 0;
}
b {
color: blue;
}
</style>
</head>
<body>
<input id="check1" type="checkbox" checked="checked">
<label for="check1">Check me</label>
<p></p>
<script>
$("input").change(function() {
var $input = $(this);
$("p").html(
".attr( \"checked\" ): <b>" + $input.attr("checked") + "</b><br>" +
".prop( \"checked\" ): <b>" + $input.prop("checked") + "</b><br>" +
".is( \":checked\" ): <b>" + $input.is(":checked")) + "</b>";
}).change();
</script>
</body>
</html>
There are few more considerations in prop() vs attr():
selectedIndex, tagName, nodeName, nodeType, ownerDocument, defaultChecked, and defaultSelected..etc should be retrieved and set with the .prop() method. These do not have corresponding attributes and are only properties.
For input type checkbox
.attr('checked') //returns checked
.prop('checked') //returns true
.is(':checked') //returns true
prop method returns Boolean value for checked, selected, disabled,
readOnly..etc while attr returns defined string. So, you can directly
use .prop(‘checked’) in if condition.
.attr() calls .prop() internally so .attr() method will be slightly
slower than accessing them directly through .prop().
Gary Hole answer is very relevant to solve the problem if the code is written in such way
obj.prop("style","border:1px red solid;")
Since the prop function return CSSStyleDeclaration object, above code will not working properly in some browser(tested with IE8 with Chrome Frame Plugin in my case).
Thus changing it into following code
obj.prop("style").cssText = "border:1px red solid;"
solved the problem.
So jQuery 1.6 has the new function prop().
$(selector).click(function(){
//instead of:
this.getAttribute('style');
//do i use:
$(this).prop('style');
//or:
$(this).attr('style');
})
or in this case do they do the same thing?
And if I do have to switch to using prop(), all the old attr() calls will break if i switch to 1.6?
UPDATE
selector = '#id'
$(selector).click(function() {
//instead of:
var getAtt = this.getAttribute('style');
//do i use:
var thisProp = $(this).prop('style');
//or:
var thisAttr = $(this).attr('style');
console.log(getAtt, thisProp, thisAttr);
});
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.6.0/jquery.min.js"></script>
<div id='id' style="color: red;background: orange;">test</div>
(see also this fiddle: http://jsfiddle.net/maniator/JpUF2/)
The console logs the getAttribute as a string, and the attr as a string, but the prop as a CSSStyleDeclaration, Why? And how does that affect my coding in the future?
Update 1 November 2012
My original answer applies specifically to jQuery 1.6. My advice remains the same but jQuery 1.6.1 changed things slightly: in the face of the predicted pile of broken websites, the jQuery team reverted attr() to something close to (but not exactly the same as) its old behaviour for Boolean attributes. John Resig also blogged about it. I can see the difficulty they were in but still disagree with his recommendation to prefer attr().
Original answer
If you've only ever used jQuery and not the DOM directly, this could be a confusing change, although it is definitely an improvement conceptually. Not so good for the bazillions of sites using jQuery that will break as a result of this change though.
I'll summarize the main issues:
You usually want prop() rather than attr().
In the majority of cases, prop() does what attr() used to do. Replacing calls to attr() with prop() in your code will generally work.
Properties are generally simpler to deal with than attributes. An attribute value may only be a string whereas a property can be of any type. For example, the checked property is a Boolean, the style property is an object with individual properties for each style, the size property is a number.
Where both a property and an attribute with the same name exists, usually updating one will update the other, but this is not the case for certain attributes of inputs, such as value and checked: for these attributes, the property always represents the current state while the attribute (except in old versions of IE) corresponds to the default value/checkedness of the input (reflected in the defaultValue / defaultChecked property).
This change removes some of the layer of magic jQuery stuck in front of attributes and properties, meaning jQuery developers will have to learn a bit about the difference between properties and attributes. This is a good thing.
If you're a jQuery developer and are confused by this whole business about properties and attributes, you need to take a step back and learn a little about it, since jQuery is no longer trying so hard to shield you from this stuff. For the authoritative but somewhat dry word on the subject, there's the specs: DOM4, HTML DOM, DOM Level 2, DOM Level 3. Mozilla's DOM documentation is valid for most modern browsers and is easier to read than the specs, so you may find their DOM reference helpful. There's a section on element properties.
As an example of how properties are simpler to deal with than attributes, consider a checkbox that is initially checked. Here are two possible pieces of valid HTML to do this:
<input id="cb" type="checkbox" checked>
<input id="cb" type="checkbox" checked="checked">
So, how do you find out if the checkbox is checked with jQuery? Look on Stack Overflow and you'll commonly find the following suggestions:
if ( $("#cb").attr("checked") === true ) {...}
if ( $("#cb").attr("checked") == "checked" ) {...}
if ( $("#cb").is(":checked") ) {...}
This is actually the simplest thing in the world to do with the checked Boolean property, which has existed and worked flawlessly in every major scriptable browser since 1995:
if (document.getElementById("cb").checked) {...}
The property also makes checking or unchecking the checkbox trivial:
document.getElementById("cb").checked = false
In jQuery 1.6, this unambiguously becomes
$("#cb").prop("checked", false)
The idea of using the checked attribute for scripting a checkbox is unhelpful and unnecessary. The property is what you need.
It's not obvious what the correct way to check or uncheck the checkbox is using the checked attribute
The attribute value reflects the default rather than the current visible state (except in some older versions of IE, thus making things still harder). The attribute tells you nothing about the whether the checkbox on the page is checked. See http://jsfiddle.net/VktA6/49/.
I think Tim said it quite well, but let's step back:
A DOM element is an object, a thing in memory. Like most objects in OOP, it has properties. It also, separately, has a map of the attributes defined on the element (usually coming from the markup that the browser read to create the element). Some of the element's properties get their initial values from attributes with the same or similar names (value gets its initial value from the "value" attribute; href gets its initial value from the "href" attribute, but it's not exactly the same value; className from the "class" attribute). Other properties get their initial values in other ways: For instance, the parentNode property gets its value based on what its parent element is; an element always has a style property, whether it has a "style" attribute or not.
Let's consider this anchor in a page at http://example.com/testing.html:
<a href='foo.html' class='test one' name='fooAnchor' id='fooAnchor'>Hi</a>
Some gratuitous ASCII art (and leaving out a lot of stuff):
+−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+
| HTMLAnchorElement |
+−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+
| href: "http://example.com/foo.html" |
| name: "fooAnchor" |
| id: "fooAnchor" |
| className: "test one" |
| attributes: |
| href: "foo.html" |
| name: "fooAnchor" |
| id: "fooAnchor" |
| class: "test one" |
+−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+
Note that the properties and attributes are distinct.
Now, although they are distinct, because all of this evolved rather than being designed from the ground up, a number of properties write back to the attribute they derived from if you set them. But not all do, and as you can see from href above, the mapping is not always a straight "pass the value on", sometimes there's interpretation involved.
When I talk about properties being properties of an object, I'm not speaking in the abstract. Here's some non-jQuery code:
var link = document.getElementById('fooAnchor');
alert(link.href); // alerts "http://example.com/foo.html"
alert(link.getAttribute("href")); // alerts "foo.html"
(Those values are as per most browsers; there's some variation.)
The link object is a real thing, and you can see there's a real distinction between accessing a property on it, and accessing an attribute.
As Tim said, the vast majority of the time, we want to be working with properties. Partially that's because their values (even their names) tend to be more consistent across browsers. We mostly only want to work with attributes when there is no property related to it (custom attributes), or when we know that for that particular attribute, the attribute and the property are not 1:1 (as with href and "href" above).
The standard properties are laid out in the various DOM specs:
DOM2 HTML (largely obsolete, see the HTML spec instead)
DOM2 Core (obsolete)
DOM3 Core (obsolete)
DOM4
These specs have excellent indexes and I recommend keeping links to them handy; I use them all the time.
Custom attributes would include, for instance, any data-xyz attributes you might put on elements to provide meta-data to your code (now that that's valid as of HTML5, as long as you stick to the data- prefix). (Recent versions of jQuery give you access to data-xyz elements via the data function, but that function is not just an accessor for data-xyz attributes [it does both more and less than that]; unless you actually need its features, I'd use the attr function to interact with data-xyz attribute.)
The attr function used to have some convoluted logic around getting what they thought you wanted, rather than literally getting the attribute. It conflated the concepts. Moving to prop and attr was meant to de-conflate them. Briefly in v1.6.0 jQuery went too far in that regard, but functionality was quickly added back to attr to handle the common situations where people use attr when technically they should use prop.
This change has been a long time coming for jQuery. For years, they've been content with a function named attr() that mostly retrieved DOM properties, not the result you'd expect from the name. The segregation of attr() and prop() should help alleviate some of the confusion between HTML attributes and DOM properties. $.fn.prop() grabs the specified DOM property, while $.fn.attr() grabs the specified HTML attribute.
To fully understand how they work, here's an extended explanation on the difference between HTML attributes and DOM properties.:
HTML Attributes
Syntax:
<body onload="foo()">
Purpose:
Allows markup to have data associated with it for events, rendering, and other purposes.
Visualization:
The class attribute is shown here on the body. It's accessible through the following code:
var attr;
attr = document.body.getAttribute("class");
//IE 8 Quirks and below
attr = document.body.getAttribute("className");
Attributes are returned in string form and can be inconsistent from browser to browser. However, they can be vital in some situations. As exemplified above, IE 8 Quirks Mode (and below) expects the name of a DOM property in get/set/removeAttribute instead of the attribute name. This is one of many reasons why it's important to know the difference.
DOM Properties
Syntax:
document.body.onload = foo;
Purpose:
Gives access to properties that belong to element nodes. These properties are similar to attributes, but are only accessible through JavaScript. This is an important difference that helps clarify the role of DOM properties. Please note that attributes are completely different from properties, as this event handler assignment is useless and won't receive the event (body doesn't have an onload event, only an onload attribute).
Visualization:
Here, you'll notice a list of properties under the "DOM" tab in Firebug. These are DOM properties. You'll immediately notice quite a few of them, as you'll have used them before without knowing it. Their values are what you'll be receiving through JavaScript.
Documentation
JavaScript: The Definitive Guide by
David Flanagan
HTML Attributes,
Mozilla Dev Center
DOM Element Properties, Mozilla Dev Center
Example
HTML: <textarea id="test" value="foo"></textarea>
JavaScript: alert($('#test').attr('value'));
In earlier versions of jQuery, this returns an empty string. In 1.6, it returns the proper value, foo.
Without having glanced at the new code for either function, I can say with confidence that the confusion has more to do with the difference between HTML attributes and DOM properties, than with the code itself. Hopefully, this cleared some things up for you.
-Matt
A property is in the DOM; an attribute is in the HTML that is parsed into the DOM.
Further detail
If you change an attribute, the change will be reflected in the DOM (sometimes with a different name).
Example: Changing the class attribute of a tag will change the className property of that tag in the DOM (That's because class is already used).
If you have no attribute on a tag, you still have the corresponding DOM property with an empty or a default value.
Example: While your tag has no class attribute, the DOM property className does exist with a empty string value.
edit
If you change the one, the other will be changed by a controller, and vice versa.
This controller is not in jQuery, but in the browser's native code.
It's just the distinction between HTML attributes and DOM objects that causes a confusion. For those that are comfortable acting on the DOM elements native properties such a this.src this.value this.checked etc, .prop is a very warm welcome to the family. For others, it's just an added layer of confusion. Let's clear that up.
The easiest way to see the difference between .attr and .prop is the following example:
<input blah="hello">
$('input').attr('blah'): returns 'hello' as expected. No suprises here.
$('input').prop('blah'): returns undefined -- because it's trying to do [HTMLInputElement].blah -- and no such property on that DOM object exists. It only exists in the scope as an attribute of that element i.e. [HTMLInputElement].getAttribute('blah')
Now we change a few things like so:
$('input').attr('blah', 'apple');
$('input').prop('blah', 'pear');
$('input').attr('blah'): returns 'apple' eh? Why not "pear" as this was set last on that element. Because the property was changed on the input attribute, not the DOM input element itself -- they basically almost work independently of each other.
$('input').prop('blah'): returns 'pear'
The thing you really need to be careful with is just do not mix the usage of these for the same property throughout your application for the above reason.
See a fiddle demonstrating the difference: http://jsfiddle.net/garreh/uLQXc/
.attr vs .prop:
Round 1: style
<input style="font:arial;"/>
.attr('style') -- returns inline styles for the matched element i.e. "font:arial;"
.prop('style') -- returns an style declaration object i.e. CSSStyleDeclaration
Round 2: value
<input value="hello" type="text"/>
$('input').prop('value', 'i changed the value');
.attr('value') -- returns 'hello' *
.prop('value') -- returns 'i changed the value'
* Note: jQuery for this reason has a .val() method, which internally is equivalent to .prop('value')
TL;DR
Use prop() over attr() in the majority of cases.
A property is the current state of the input element. An attribute is the default value.
A property can contain things of different types. An attribute can only contain strings
Dirty checkedness
This concept provides an example where the difference is observable: http://www.w3.org/TR/html5/forms.html#concept-input-checked-dirty
Try it out:
click the button. Both checkboxes got checked.
uncheck both checkboxes.
click the button again. Only the prop checkbox got checked. BANG!
$('button').on('click', function() {
$('#attr').attr('checked', 'checked')
$('#prop').prop('checked', true)
})
<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script>
<label>attr <input id="attr" type="checkbox"></label>
<label>prop <input id="prop" type="checkbox"></label>
<button type="button">Set checked attr and prop.</button>
For some attributes like disabled on button, adding or removing the content attribute disabled="disabled" always toggles the property (called IDL attribute in HTML5) because http://www.w3.org/TR/html5/forms.html#attr-fe-disabled says:
The disabled IDL attribute must reflect the disabled content attribute.
so you might get away with it, although it is ugly since it modifies HTML without need.
For other attributes like checked="checked" on input type="checkbox", things break, because once you click on it, it becomes dirty, and then adding or removing the checked="checked" content attribute does not toggle checkedness anymore.
This is why you should use mostly .prop, as it affects the effective property directly, instead of relying on complex side-effects of modifying the HTML.
All is in the doc:
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() retrieves attributes.
So use prop!
attributes are in your HTML text document/file (== imagine this is the result of your html markup parsed), whereas
properties are in HTML DOM tree (== basically an actual property of some object in JS sense).
Importantly, many of them are synced (if you update class property, class attribute in html will also be updated; and otherwise). But some attributes may be synced to unexpected properties - eg, attribute checked corresponds to property defaultChecked, so that
manually checking a checkbox will change .prop('checked') value, but will not change .attr('checked') and .prop('defaultChecked') values
setting $('#input').prop('defaultChecked', true) will also change .attr('checked'), but this will not be visible on an element.
Rule of thumb is: .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. (http://blog.jquery.com/2011/05/10/jquery-1-6-1-rc-1-released/)
And here is a table that shows where .prop() is preferred (even though .attr() can still be used).
Why would you sometimes want to use .prop() instead of .attr() where latter is officially adviced?
.prop() can return any type - string, integer, boolean; while .attr() always returns a string.
.prop() is said to be about 2.5 times faster than .attr().
.attr():
Get the value of an attribute for the first element in the set of matched elements.
Gives you the value of element as it was defined in the html on page load
.prop():
Get the value of a property for the first element in the set of matched elements.
Gives the updated values of elements which is modified via javascript/jquery
Usually you'll want to use properties.
Use attributes only for:
Getting a custom HTML attribute (since it's not synced with a DOM property).
Getting a HTML attribute that doesn't sync with a DOM property, e.g. get the "original value" of a standard HTML attribute, like <input value="abc">.
attributes -> HTML
properties -> DOM
Before jQuery 1.6 , the attr() method sometimes took property values into account when retrieving attributes, this caused rather inconsistent behavior.
The introduction of the prop() method provides a way to explicitly retrieve property values, while .attr() retrieves attributes.
The Docs:
jQuery.attr()
Get the value of an attribute for the first element in the set of matched elements.
jQuery.prop()
Get the value of a property for the first element in the set of matched elements.
One thing .attr() can do that .prop() can't: affect CSS selectors
Here's an issue I didn't see in the other answers.
CSS selector [name=value]
will respond to .attr('name', 'value')
but not always to .prop('name', 'value')
.prop() affects only a few attribute-selectors
input[name] (thanks #TimDown)
.attr() affects all attribute-selectors
input[value]
input[naame]
span[name]
input[data-custom-attribute] (neither will .data('custom-attribute') affect this selector)
Gently reminder about using prop(), example:
if ($("#checkbox1").prop('checked')) {
isDelete = 1;
} else {
isDelete = 0;
}
The function above is used to check if checkbox1 is checked or not, if checked: return 1; if not: return 0. Function prop() used here as a GET function.
if ($("#checkbox1").prop('checked', true)) {
isDelete = 1;
} else {
isDelete = 0;
}
The function above is used to set checkbox1 to be checked and ALWAYS return 1. Now function prop() used as a SET function.
Don't mess up.
P/S: When I'm checking Image src property. If the src is empty, prop return the current URL of the page (wrong), and attr return empty string (right).
1) A property is in the DOM; an attribute is in the HTML that is
parsed into the DOM.
2) $( elem ).attr( "checked" ) (1.6.1+) "checked" (String) Will
change with checkbox state
3) $( elem ).attr( "checked" ) (pre-1.6) true (Boolean) Changed
with checkbox state
Mostly we want to use for DOM object rather then custom attribute
like data-img, data-xyz.
Also some of difference when accessing checkbox value and href
with attr() and prop() as thing change with DOM output with
prop() as full link from origin and Boolean value for checkbox
(pre-1.6)
We can only access DOM elements with prop other then it gives undefined
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.6.0/jquery.min.js"></script>
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>prop demo</title>
<style>
p {
margin: 20px 0 0;
}
b {
color: blue;
}
</style>
</head>
<body>
<input id="check1" type="checkbox" checked="checked">
<label for="check1">Check me</label>
<p></p>
<script>
$("input").change(function() {
var $input = $(this);
$("p").html(
".attr( \"checked\" ): <b>" + $input.attr("checked") + "</b><br>" +
".prop( \"checked\" ): <b>" + $input.prop("checked") + "</b><br>" +
".is( \":checked\" ): <b>" + $input.is(":checked")) + "</b>";
}).change();
</script>
</body>
</html>
There are few more considerations in prop() vs attr():
selectedIndex, tagName, nodeName, nodeType, ownerDocument, defaultChecked, and defaultSelected..etc should be retrieved and set with the .prop() method. These do not have corresponding attributes and are only properties.
For input type checkbox
.attr('checked') //returns checked
.prop('checked') //returns true
.is(':checked') //returns true
prop method returns Boolean value for checked, selected, disabled,
readOnly..etc while attr returns defined string. So, you can directly
use .prop(‘checked’) in if condition.
.attr() calls .prop() internally so .attr() method will be slightly
slower than accessing them directly through .prop().
Gary Hole answer is very relevant to solve the problem if the code is written in such way
obj.prop("style","border:1px red solid;")
Since the prop function return CSSStyleDeclaration object, above code will not working properly in some browser(tested with IE8 with Chrome Frame Plugin in my case).
Thus changing it into following code
obj.prop("style").cssText = "border:1px red solid;"
solved the problem.
So jQuery 1.6 has the new function prop().
$(selector).click(function(){
//instead of:
this.getAttribute('style');
//do i use:
$(this).prop('style');
//or:
$(this).attr('style');
})
or in this case do they do the same thing?
And if I do have to switch to using prop(), all the old attr() calls will break if i switch to 1.6?
UPDATE
selector = '#id'
$(selector).click(function() {
//instead of:
var getAtt = this.getAttribute('style');
//do i use:
var thisProp = $(this).prop('style');
//or:
var thisAttr = $(this).attr('style');
console.log(getAtt, thisProp, thisAttr);
});
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.6.0/jquery.min.js"></script>
<div id='id' style="color: red;background: orange;">test</div>
(see also this fiddle: http://jsfiddle.net/maniator/JpUF2/)
The console logs the getAttribute as a string, and the attr as a string, but the prop as a CSSStyleDeclaration, Why? And how does that affect my coding in the future?
Update 1 November 2012
My original answer applies specifically to jQuery 1.6. My advice remains the same but jQuery 1.6.1 changed things slightly: in the face of the predicted pile of broken websites, the jQuery team reverted attr() to something close to (but not exactly the same as) its old behaviour for Boolean attributes. John Resig also blogged about it. I can see the difficulty they were in but still disagree with his recommendation to prefer attr().
Original answer
If you've only ever used jQuery and not the DOM directly, this could be a confusing change, although it is definitely an improvement conceptually. Not so good for the bazillions of sites using jQuery that will break as a result of this change though.
I'll summarize the main issues:
You usually want prop() rather than attr().
In the majority of cases, prop() does what attr() used to do. Replacing calls to attr() with prop() in your code will generally work.
Properties are generally simpler to deal with than attributes. An attribute value may only be a string whereas a property can be of any type. For example, the checked property is a Boolean, the style property is an object with individual properties for each style, the size property is a number.
Where both a property and an attribute with the same name exists, usually updating one will update the other, but this is not the case for certain attributes of inputs, such as value and checked: for these attributes, the property always represents the current state while the attribute (except in old versions of IE) corresponds to the default value/checkedness of the input (reflected in the defaultValue / defaultChecked property).
This change removes some of the layer of magic jQuery stuck in front of attributes and properties, meaning jQuery developers will have to learn a bit about the difference between properties and attributes. This is a good thing.
If you're a jQuery developer and are confused by this whole business about properties and attributes, you need to take a step back and learn a little about it, since jQuery is no longer trying so hard to shield you from this stuff. For the authoritative but somewhat dry word on the subject, there's the specs: DOM4, HTML DOM, DOM Level 2, DOM Level 3. Mozilla's DOM documentation is valid for most modern browsers and is easier to read than the specs, so you may find their DOM reference helpful. There's a section on element properties.
As an example of how properties are simpler to deal with than attributes, consider a checkbox that is initially checked. Here are two possible pieces of valid HTML to do this:
<input id="cb" type="checkbox" checked>
<input id="cb" type="checkbox" checked="checked">
So, how do you find out if the checkbox is checked with jQuery? Look on Stack Overflow and you'll commonly find the following suggestions:
if ( $("#cb").attr("checked") === true ) {...}
if ( $("#cb").attr("checked") == "checked" ) {...}
if ( $("#cb").is(":checked") ) {...}
This is actually the simplest thing in the world to do with the checked Boolean property, which has existed and worked flawlessly in every major scriptable browser since 1995:
if (document.getElementById("cb").checked) {...}
The property also makes checking or unchecking the checkbox trivial:
document.getElementById("cb").checked = false
In jQuery 1.6, this unambiguously becomes
$("#cb").prop("checked", false)
The idea of using the checked attribute for scripting a checkbox is unhelpful and unnecessary. The property is what you need.
It's not obvious what the correct way to check or uncheck the checkbox is using the checked attribute
The attribute value reflects the default rather than the current visible state (except in some older versions of IE, thus making things still harder). The attribute tells you nothing about the whether the checkbox on the page is checked. See http://jsfiddle.net/VktA6/49/.
I think Tim said it quite well, but let's step back:
A DOM element is an object, a thing in memory. Like most objects in OOP, it has properties. It also, separately, has a map of the attributes defined on the element (usually coming from the markup that the browser read to create the element). Some of the element's properties get their initial values from attributes with the same or similar names (value gets its initial value from the "value" attribute; href gets its initial value from the "href" attribute, but it's not exactly the same value; className from the "class" attribute). Other properties get their initial values in other ways: For instance, the parentNode property gets its value based on what its parent element is; an element always has a style property, whether it has a "style" attribute or not.
Let's consider this anchor in a page at http://example.com/testing.html:
<a href='foo.html' class='test one' name='fooAnchor' id='fooAnchor'>Hi</a>
Some gratuitous ASCII art (and leaving out a lot of stuff):
+−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+
| HTMLAnchorElement |
+−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+
| href: "http://example.com/foo.html" |
| name: "fooAnchor" |
| id: "fooAnchor" |
| className: "test one" |
| attributes: |
| href: "foo.html" |
| name: "fooAnchor" |
| id: "fooAnchor" |
| class: "test one" |
+−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+
Note that the properties and attributes are distinct.
Now, although they are distinct, because all of this evolved rather than being designed from the ground up, a number of properties write back to the attribute they derived from if you set them. But not all do, and as you can see from href above, the mapping is not always a straight "pass the value on", sometimes there's interpretation involved.
When I talk about properties being properties of an object, I'm not speaking in the abstract. Here's some non-jQuery code:
var link = document.getElementById('fooAnchor');
alert(link.href); // alerts "http://example.com/foo.html"
alert(link.getAttribute("href")); // alerts "foo.html"
(Those values are as per most browsers; there's some variation.)
The link object is a real thing, and you can see there's a real distinction between accessing a property on it, and accessing an attribute.
As Tim said, the vast majority of the time, we want to be working with properties. Partially that's because their values (even their names) tend to be more consistent across browsers. We mostly only want to work with attributes when there is no property related to it (custom attributes), or when we know that for that particular attribute, the attribute and the property are not 1:1 (as with href and "href" above).
The standard properties are laid out in the various DOM specs:
DOM2 HTML (largely obsolete, see the HTML spec instead)
DOM2 Core (obsolete)
DOM3 Core (obsolete)
DOM4
These specs have excellent indexes and I recommend keeping links to them handy; I use them all the time.
Custom attributes would include, for instance, any data-xyz attributes you might put on elements to provide meta-data to your code (now that that's valid as of HTML5, as long as you stick to the data- prefix). (Recent versions of jQuery give you access to data-xyz elements via the data function, but that function is not just an accessor for data-xyz attributes [it does both more and less than that]; unless you actually need its features, I'd use the attr function to interact with data-xyz attribute.)
The attr function used to have some convoluted logic around getting what they thought you wanted, rather than literally getting the attribute. It conflated the concepts. Moving to prop and attr was meant to de-conflate them. Briefly in v1.6.0 jQuery went too far in that regard, but functionality was quickly added back to attr to handle the common situations where people use attr when technically they should use prop.
This change has been a long time coming for jQuery. For years, they've been content with a function named attr() that mostly retrieved DOM properties, not the result you'd expect from the name. The segregation of attr() and prop() should help alleviate some of the confusion between HTML attributes and DOM properties. $.fn.prop() grabs the specified DOM property, while $.fn.attr() grabs the specified HTML attribute.
To fully understand how they work, here's an extended explanation on the difference between HTML attributes and DOM properties.:
HTML Attributes
Syntax:
<body onload="foo()">
Purpose:
Allows markup to have data associated with it for events, rendering, and other purposes.
Visualization:
The class attribute is shown here on the body. It's accessible through the following code:
var attr;
attr = document.body.getAttribute("class");
//IE 8 Quirks and below
attr = document.body.getAttribute("className");
Attributes are returned in string form and can be inconsistent from browser to browser. However, they can be vital in some situations. As exemplified above, IE 8 Quirks Mode (and below) expects the name of a DOM property in get/set/removeAttribute instead of the attribute name. This is one of many reasons why it's important to know the difference.
DOM Properties
Syntax:
document.body.onload = foo;
Purpose:
Gives access to properties that belong to element nodes. These properties are similar to attributes, but are only accessible through JavaScript. This is an important difference that helps clarify the role of DOM properties. Please note that attributes are completely different from properties, as this event handler assignment is useless and won't receive the event (body doesn't have an onload event, only an onload attribute).
Visualization:
Here, you'll notice a list of properties under the "DOM" tab in Firebug. These are DOM properties. You'll immediately notice quite a few of them, as you'll have used them before without knowing it. Their values are what you'll be receiving through JavaScript.
Documentation
JavaScript: The Definitive Guide by
David Flanagan
HTML Attributes,
Mozilla Dev Center
DOM Element Properties, Mozilla Dev Center
Example
HTML: <textarea id="test" value="foo"></textarea>
JavaScript: alert($('#test').attr('value'));
In earlier versions of jQuery, this returns an empty string. In 1.6, it returns the proper value, foo.
Without having glanced at the new code for either function, I can say with confidence that the confusion has more to do with the difference between HTML attributes and DOM properties, than with the code itself. Hopefully, this cleared some things up for you.
-Matt
A property is in the DOM; an attribute is in the HTML that is parsed into the DOM.
Further detail
If you change an attribute, the change will be reflected in the DOM (sometimes with a different name).
Example: Changing the class attribute of a tag will change the className property of that tag in the DOM (That's because class is already used).
If you have no attribute on a tag, you still have the corresponding DOM property with an empty or a default value.
Example: While your tag has no class attribute, the DOM property className does exist with a empty string value.
edit
If you change the one, the other will be changed by a controller, and vice versa.
This controller is not in jQuery, but in the browser's native code.
It's just the distinction between HTML attributes and DOM objects that causes a confusion. For those that are comfortable acting on the DOM elements native properties such a this.src this.value this.checked etc, .prop is a very warm welcome to the family. For others, it's just an added layer of confusion. Let's clear that up.
The easiest way to see the difference between .attr and .prop is the following example:
<input blah="hello">
$('input').attr('blah'): returns 'hello' as expected. No suprises here.
$('input').prop('blah'): returns undefined -- because it's trying to do [HTMLInputElement].blah -- and no such property on that DOM object exists. It only exists in the scope as an attribute of that element i.e. [HTMLInputElement].getAttribute('blah')
Now we change a few things like so:
$('input').attr('blah', 'apple');
$('input').prop('blah', 'pear');
$('input').attr('blah'): returns 'apple' eh? Why not "pear" as this was set last on that element. Because the property was changed on the input attribute, not the DOM input element itself -- they basically almost work independently of each other.
$('input').prop('blah'): returns 'pear'
The thing you really need to be careful with is just do not mix the usage of these for the same property throughout your application for the above reason.
See a fiddle demonstrating the difference: http://jsfiddle.net/garreh/uLQXc/
.attr vs .prop:
Round 1: style
<input style="font:arial;"/>
.attr('style') -- returns inline styles for the matched element i.e. "font:arial;"
.prop('style') -- returns an style declaration object i.e. CSSStyleDeclaration
Round 2: value
<input value="hello" type="text"/>
$('input').prop('value', 'i changed the value');
.attr('value') -- returns 'hello' *
.prop('value') -- returns 'i changed the value'
* Note: jQuery for this reason has a .val() method, which internally is equivalent to .prop('value')
TL;DR
Use prop() over attr() in the majority of cases.
A property is the current state of the input element. An attribute is the default value.
A property can contain things of different types. An attribute can only contain strings
Dirty checkedness
This concept provides an example where the difference is observable: http://www.w3.org/TR/html5/forms.html#concept-input-checked-dirty
Try it out:
click the button. Both checkboxes got checked.
uncheck both checkboxes.
click the button again. Only the prop checkbox got checked. BANG!
$('button').on('click', function() {
$('#attr').attr('checked', 'checked')
$('#prop').prop('checked', true)
})
<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script>
<label>attr <input id="attr" type="checkbox"></label>
<label>prop <input id="prop" type="checkbox"></label>
<button type="button">Set checked attr and prop.</button>
For some attributes like disabled on button, adding or removing the content attribute disabled="disabled" always toggles the property (called IDL attribute in HTML5) because http://www.w3.org/TR/html5/forms.html#attr-fe-disabled says:
The disabled IDL attribute must reflect the disabled content attribute.
so you might get away with it, although it is ugly since it modifies HTML without need.
For other attributes like checked="checked" on input type="checkbox", things break, because once you click on it, it becomes dirty, and then adding or removing the checked="checked" content attribute does not toggle checkedness anymore.
This is why you should use mostly .prop, as it affects the effective property directly, instead of relying on complex side-effects of modifying the HTML.
All is in the doc:
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() retrieves attributes.
So use prop!
attributes are in your HTML text document/file (== imagine this is the result of your html markup parsed), whereas
properties are in HTML DOM tree (== basically an actual property of some object in JS sense).
Importantly, many of them are synced (if you update class property, class attribute in html will also be updated; and otherwise). But some attributes may be synced to unexpected properties - eg, attribute checked corresponds to property defaultChecked, so that
manually checking a checkbox will change .prop('checked') value, but will not change .attr('checked') and .prop('defaultChecked') values
setting $('#input').prop('defaultChecked', true) will also change .attr('checked'), but this will not be visible on an element.
Rule of thumb is: .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. (http://blog.jquery.com/2011/05/10/jquery-1-6-1-rc-1-released/)
And here is a table that shows where .prop() is preferred (even though .attr() can still be used).
Why would you sometimes want to use .prop() instead of .attr() where latter is officially adviced?
.prop() can return any type - string, integer, boolean; while .attr() always returns a string.
.prop() is said to be about 2.5 times faster than .attr().
.attr():
Get the value of an attribute for the first element in the set of matched elements.
Gives you the value of element as it was defined in the html on page load
.prop():
Get the value of a property for the first element in the set of matched elements.
Gives the updated values of elements which is modified via javascript/jquery
Usually you'll want to use properties.
Use attributes only for:
Getting a custom HTML attribute (since it's not synced with a DOM property).
Getting a HTML attribute that doesn't sync with a DOM property, e.g. get the "original value" of a standard HTML attribute, like <input value="abc">.
attributes -> HTML
properties -> DOM
Before jQuery 1.6 , the attr() method sometimes took property values into account when retrieving attributes, this caused rather inconsistent behavior.
The introduction of the prop() method provides a way to explicitly retrieve property values, while .attr() retrieves attributes.
The Docs:
jQuery.attr()
Get the value of an attribute for the first element in the set of matched elements.
jQuery.prop()
Get the value of a property for the first element in the set of matched elements.
One thing .attr() can do that .prop() can't: affect CSS selectors
Here's an issue I didn't see in the other answers.
CSS selector [name=value]
will respond to .attr('name', 'value')
but not always to .prop('name', 'value')
.prop() affects only a few attribute-selectors
input[name] (thanks #TimDown)
.attr() affects all attribute-selectors
input[value]
input[naame]
span[name]
input[data-custom-attribute] (neither will .data('custom-attribute') affect this selector)
Gently reminder about using prop(), example:
if ($("#checkbox1").prop('checked')) {
isDelete = 1;
} else {
isDelete = 0;
}
The function above is used to check if checkbox1 is checked or not, if checked: return 1; if not: return 0. Function prop() used here as a GET function.
if ($("#checkbox1").prop('checked', true)) {
isDelete = 1;
} else {
isDelete = 0;
}
The function above is used to set checkbox1 to be checked and ALWAYS return 1. Now function prop() used as a SET function.
Don't mess up.
P/S: When I'm checking Image src property. If the src is empty, prop return the current URL of the page (wrong), and attr return empty string (right).
1) A property is in the DOM; an attribute is in the HTML that is
parsed into the DOM.
2) $( elem ).attr( "checked" ) (1.6.1+) "checked" (String) Will
change with checkbox state
3) $( elem ).attr( "checked" ) (pre-1.6) true (Boolean) Changed
with checkbox state
Mostly we want to use for DOM object rather then custom attribute
like data-img, data-xyz.
Also some of difference when accessing checkbox value and href
with attr() and prop() as thing change with DOM output with
prop() as full link from origin and Boolean value for checkbox
(pre-1.6)
We can only access DOM elements with prop other then it gives undefined
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.6.0/jquery.min.js"></script>
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>prop demo</title>
<style>
p {
margin: 20px 0 0;
}
b {
color: blue;
}
</style>
</head>
<body>
<input id="check1" type="checkbox" checked="checked">
<label for="check1">Check me</label>
<p></p>
<script>
$("input").change(function() {
var $input = $(this);
$("p").html(
".attr( \"checked\" ): <b>" + $input.attr("checked") + "</b><br>" +
".prop( \"checked\" ): <b>" + $input.prop("checked") + "</b><br>" +
".is( \":checked\" ): <b>" + $input.is(":checked")) + "</b>";
}).change();
</script>
</body>
</html>
There are few more considerations in prop() vs attr():
selectedIndex, tagName, nodeName, nodeType, ownerDocument, defaultChecked, and defaultSelected..etc should be retrieved and set with the .prop() method. These do not have corresponding attributes and are only properties.
For input type checkbox
.attr('checked') //returns checked
.prop('checked') //returns true
.is(':checked') //returns true
prop method returns Boolean value for checked, selected, disabled,
readOnly..etc while attr returns defined string. So, you can directly
use .prop(‘checked’) in if condition.
.attr() calls .prop() internally so .attr() method will be slightly
slower than accessing them directly through .prop().
Gary Hole answer is very relevant to solve the problem if the code is written in such way
obj.prop("style","border:1px red solid;")
Since the prop function return CSSStyleDeclaration object, above code will not working properly in some browser(tested with IE8 with Chrome Frame Plugin in my case).
Thus changing it into following code
obj.prop("style").cssText = "border:1px red solid;"
solved the problem.
Expressions like Element.getAttribute("id") and Element.id return the same thing.
Which one should be used when we need attributes of an HTMLElement object?
Is there any cross browser issue with these methods like getAttribute() and setAttribute()?
Or any impact on performance between directly accessing object properties vs using these attribute methods?
getAttribute retrieves the attribute of a DOM element, while el.id retrieves the property of this DOM element. They are not the same.
Most of the time, DOM properties are synchronized with attributes.
However, the synchronization does not guarantee the same value. A classic example is between el.href and el.getAttribute('href') for an anchor element.
For example:
<script>
var a = document.getElementById('hey')
a.getAttribute('href') // "/"
a.href // Full URL except for IE that keeps '/'
</script>
This behavior happens because according to the W3C, the href property must be a well-formed link. Most browsers respect this standard (guess who doesn't?).
There is another case for the input's checked property. The DOM property returns true or false while the attribute returns the string "checked" or an empty string.
And then, there are some properties that are synchronized one-way only. The best example is the value property of an input element. Changing its value through the DOM property will not change the attribute (edit: check the first comment for more precision).
Because of these reasons, I'd suggest you keep using the DOM properties, and not the attributes, as their behavior differs between the browsers.
In reality, there are only two cases where you need to use the attributes:
A custom HTML attribute, because it is not synced to a DOM property.
To access a built-in HTML attribute, which is not synced from the property, and you are sure you need the attribute (for example, the original value of an input element).
If you want a more detailed explaination, I strongly suggest you read this page. It will take you a few minutes only, but you will be delighted by the information (which I summed up here).
getAttribute('attribute') normally returns the attribute value as a string, exactly as defined in the HTML source of the page.
However, element.attribute could return a normalized or calculated value of the attribute. Examples:
a.href will contain full URL
<input type="checkbox" checked>
input.checked will be true (boolean)
<input type="checkbox" checked="bleh">
input.checked will be true (boolean)
<img src='http://dummyimage.com/64x64/000/fff'>
img.width will be 0 (number) before the image is loaded
img.width will be 64 (number) when image (or first few bytes of it) is loaded
<img src='http://dummyimage.com/64x64/000/fff' width="50%">
img.width will be the calculated 50%
<img src='http://dummyimage.com/32x32/000/fff' style='width: 50px'>
img.width will be 50 (number)
<div style='background: lime;'></div>
div.style will be an object
According to this jsPerf test getAttribute is more slow than id property.
PS
Oddly enough both statements perform very bad on IE8 (compared to other browsers).
Always use the properties unless you have a specific reason not to.
getAttribute() and setAttribute() are broken in older IE (and compatibility mode in later versions)
properties are more convenient (in particular, those corresponding to boolean attributes)
There are some exceptions:
accessing attributes of <form> elements
accessing custom attributes (although I'd discourage using custom attributes at all)
I've written about this subject a few times on SO:
https://stackoverflow.com/a/7010268/96100
https://stackoverflow.com/a/4456805/96100
.id saves the function call overhead. (which is very small, but you asked. )
Try below example to understand this completely. For the below DIV
<div class="myclass"></div>
The Element.getAttribute('class') will return myclass but you have to use Element.className which retrieves it from the DOM property.
One area where this makes a big difference is with css styling based on attributes.
Consider the following:
const divs = document.querySelectorAll('div');
divs[1].custom = true;
divs[2].setAttribute('custom', true);
div {
border: 1px solid;
margin-bottom: 8px;
}
div[custom] {
background: #36a;
color: #fff;
}
<div>A normal div</div>
<div>A div with a custom property set directly.</div>
<div>A div with a custom attribute set with `setAttribute`</div>
The div with the custom property set directly doesn't reflect the value to the attribute, and is not selected by our attribute selector (div[custom]) in the css.
The div with the custom attribute set using setAttribute, however, is able to be selected using a css attribute selector, and styled accordingly.
So I'm learning to manipulate the DOM and I noticed one interesting thing:
Let's say I want to set the name attribute of an element by using the "." dot notation:
element.name = "someName";
console.log(document.getElementsByName("someName")[0]); // returns "undefined"??
However if I use the document.setAttribute() method, it works fine:
element.setAttribute("name", "someName");
console.log(document.getElementsByName("someName")[0]); // returns the element like it should.
Not sure why the dot notation method doesn't work in the first case.
Why does this happen?
My guess (because you didn't specify the element type) is the element normally does not have a name attribute, so setting the DOM property like that won't work.
For example, setting the name property on an input element will work. Setting it on a div will not.
It will work, however, with setAttribute().
jsFiddle.
To extend the answers provided by some of the others ...
The attribute 'name' is only considered valid DOM for a few specific objects. According to https://developer.mozilla.org/en-US/docs/DOM/element.name those objects are:
<a>, <applet>, <button>, <form>, <frame>, <iframe>, <img>, <input>,
<map>, <meta>, <object>, <param>, <select>, and <textarea>
For these objects you can set, get and change the name attribute using object.name BUT FOR ANY OTHER DOM OBJECT the attribute 'name' is a custom attribute and must be created using SetAttribute() or by adding it to the HTML declaration. Once it is created, you can acces it using setAttribute() and getAttribute() or you can refer to its value directly using object.attributes.name.value take a look at http://jsfiddle.net/radiotrib/yat72/1/ for an example. BTW - the alert box on load is intentional - check the code to see why ...
(Attempting to explain part of the above post a better, separately, since it is already went into -ve rating, and belief in that post will be less. Help improve this further if not better.)
*** The property
When you use, element.name, you are accessing an existing property named "name" or setting its value.
Example 1:
var div1 = document.getElementById("div1");
div1.textContent = "2";
*** The attribute
but, while using, element.setAttribute('name','someName'), you are actually setting the attribute named 'name'.
This attribute can be an existing property OR a custom one we want:
Example 2:
var h1 = document.getElementById("H1");
h1.setAttribute("class", "democlass");
Example 3:
var d = document.getElementById("d1");
d.setAttribute("name1", "value1");
when you use, element.name, you are accessing the property/creating a property named "name" and setting its value.
when you use, element.name, you are accessing the property/creating a property named "name" and setting its value.
but,
while using, element.setAttribute('name','someName'), you are actually setting the attribute 'name'.
IE8 and below treats the property and attribute as same, the bug has been fixed in IE9 and above.
Safari, FireFox, Chrome treat property and attribute differently.
However, you can always create a new property of your choice if you wish to do so.
<head>
<script>
function test($count) {
document.getElementById("test1").setAttribute("name","file-upload_" + $count);
}
</script>
</head>
<body>
<p>some content</p>
<input id="test1" type="file" name="file-upload" id="file-upload" />
<p>some other content</p>
<script>test(1);</script>
</body>