3 ms·

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 upgra

by troyk 15y ago

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

jeresig 15y ago
Which changes (I assume, to .attr()) are affecting you, in particular?
- troyk 15y ago
  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.
  - crescentfresh 15y ago
    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'. List compiled (partially) from http://stackoverflow.com/questions/706384/boolean-html-attributes/707702#707702 http://stackoverflow.com/questions/706384/boolean-html-attri...
    - pak 15y ago
      This should be linked to or listed directly in the OP. 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.
- ars 15y ago
  I have this code: $.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 assume I should change all attr to prop? 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.
  - dmethvin 15y ago
    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!
jeresig 15y ago
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). The bug and commit are as follows: http://bugs.jquery.com/ticket/9079 http://bugs.jquery.com/ticket/9079 https://github.com/jquery/jquery/commit/a9d9f8c5422f171d9c451385fcfd7ed1661ec514 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 http://code.jquery.com/jquery-git.js Hope this helps!
- crescentfresh 15y ago
  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? Eg $(optionElement) .prop('selected', true) .attr('selected'); // undefined in 1.6, "selected" in 1.6.1
  - jeresig 15y ago
    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.
    - deleted 15y ago

by troyk 15y ago

jeresig 15y ago

Which changes (I assume, to .attr()) are affecting you, in particular?

troyk 15y ago
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.
- crescentfresh 15y ago
  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'. List compiled (partially) from http://stackoverflow.com/questions/706384/boolean-html-attributes/707702#707702 http://stackoverflow.com/questions/706384/boolean-html-attri...
  - pak 15y ago
    This should be linked to or listed directly in the OP. 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.
ars 15y ago
I have this code: $.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 assume I should change all attr to prop? 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.
- dmethvin 15y ago
  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!

jeresig 15y ago

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). The bug and commit are as follows: http://bugs.jquery.com/ticket/9079 http://bugs.jquery.com/ticket/9079 https://github.com/jquery/jquery/commit/a9d9f8c5422f171d9c451385fcfd7ed1661ec514 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 http://code.jquery.com/jquery-git.js Hope this helps!

crescentfresh 15y ago
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? Eg $(optionElement) .prop('selected', true) .attr('selected'); // undefined in 1.6, "selected" in 1.6.1
- jeresig 15y ago
  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.
  - deleted 15y ago