I wasn't entirely sold on the splitting up of attributes and properties at first. After all, a big part of jQuery is adding convenience, and this does remove a certain amount of convenience at the end of the day, even if only a little. Then I got to the performance graphs at the end. Those are some impressive speed ups for almost all the browsers (1). The speed + more logical separation seems totally worth it.
(1) Except, you know, ie 7 and ie 8. So... half the internet.
I'd prefer the convenience, as I have yet to code up some jquery and think "damn, .attr is a dog", and now I have to refactor a bunch of code before I can upgrade, and the reality of it is that I won't. jQuery is awesome, but this is the first release that I've not wanted to jump all over
I thought about this discussion a lot more today, discussed the points with the rest of the jQuery core team, and we decided to land an improvement to bring back the boolean attribute handling (with virtually no performance overhead).
Trying to get some clarity around this commit. As I understand it this addresses usecases where an element's boolean property is set to true, and .attr() is called as a getter for said property, correct?
.attr('selected'); // undefined in 1.6, "selected" in 1.6.1
Yes, I've since read other comments and have a better understanding of the reasoning behind .attr and .prop, so I'm a little less bah-humbug about having to refactor before upgrading. It appears that search/replace .attr('value') => .val(), .attr('checked') => .prop('checked') are the big offenders, but probably need to look closer at .attr('enabled') and .attr('disabled') as well.
Relying on the following attributes as returned from .attr() will break, and should get ported to use .prop() instead: 'checked', 'disabled', 'readonly', 'selected' (for <option>s), 'multiple' (for <select>s), 'ismap' (for <img>s), 'defer', 'noresize' (for <frame>s), 'nowrap'.
The blog entry mentions this, but perhaps without enough detail. Your `.setAttr()` exactly matches the same as the `.attr()` method's new behavior when it's passed a Boolean argument to set. The other two would be great suggestions for 1.7!
I don't think it's clear at all what the purpose of each is, especially if you were coming into jQuery fresh. I would have interpreted .prop as something more like .data.
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?