4 ms·

Browsers have two concepts for "data that's attached to an element". There are traditional attributes, for example: <input type="text"/> - doing .getAttribute("

by jeresig 15y ago

Browsers have two concepts for "data that's attached to an element". There are traditional attributes, for example: <input type="text"/> - doing .getAttribute("type") will get you "text". Additionally there is the concept of DOM object properties - these are properties that exist solely on the JavaScript implementation of the DOM node. For example .selectedIndex is a property that exists on select elements but isn't actually an attribute. Previously jQuery conflated properties and attributes (sometimes using one, sometimes using another). Unfortunately, while this creates a result that is perhaps slightly more user friendly, it also creates lots of weird edge cases that are hard to define (such as the cases relating to value, outlined in the blog post). For this reason we've split apart the functionality into two realms: .attr()/.removeAttr() and .prop()/.removeProp(). How does this affect you and your applications? It probably (hopefully) won't. Continuing to use .attr()/.removeAttr() will probably be just fine. Using other jQuery helpers, like .val(), will help to cover over the last remaining bits of weirdness that exist. In short: Nothing much of serious consequence will likely change, but we're going to actively watch the response from this release and make sure we act appropriately, and swiftly, should major problems come up.

ThePinion 15y ago
An informative reply from Mr. Resig himself :) Thanks! I understand now. I generally use .attr to retrieve the id, class, or something like that, which isn't something that usually changes in my scripts. I mainly stick to .val() for inputs, so this definitely clears up my concerns. I'll go through my code a bit to see if I need to make any changes, but it doesn't seem that way now that it's all more clarified for me.. Besides a couple cases where I check the state of checkboxes. Thanks again for your help, and for jQuery in general. It's made my life/job easier in a completely indescribable way. (I used to be afraid of Javascript.)
crescentfresh 15y ago
> Continuing to use .attr()/.removeAttr() will probably be just fine Your blog post calls them "breaking changes" for a reason though. Code that does `if ($elem.attr('checked'))` needs to be rewritten to use .prop when upgrading. Saying "It probably (hopefully) won't [affect your applications]" is slightly contradictory.
mrchess 15y ago
Is prop('value') faster than val() now for reading dynamic input?
- jeresig 15y ago
  Probably - but that's mostly due to the fact that .val() does more to ensure that the value being returned is useful (such as turning selected options into arrays, etc.).
deleted 15y ago
[deleted]
peteot 15y ago
Honestly, I think that jQuery pre-1.6 did the right thing almost all the time and we all learned to deal with the boolean attribute edge case just fine. I feel like this change is taking jQuery in the wrong direction. We don't want to look back and say "1.6 is where the bloat began..."
timdown 15y ago
That's quite a simplified explanation which sidesteps the issue of properties that correspond to attributes, which is where most of the confusion is going to be. And I totally disagree with your description of things like Boolean attributes/properties as "weird edge cases": their behaviour in most browsers is well-defined, consistent and not really at all weird, particularly if you limit yourself to using properties rather than attributes, which is almost always the correct approach. Saying that it probably won't affect existing applications is just misleading. 1.6 fundamentally changes the behaviour of attr(), which is a very complicated and commonly used method. Furthermore, there's really no point in this if you're not going to encourage people to move to prop() rather than attr(). The messages coming from jQuery about this change seem very vague to me. If you're going to spring this kind of change on your users then they need to understand what it is that you've changed and why it's a good thing (I think it is, by the way), which one documented example and a hand-wavy assurance that it might probably be mostly OK doesn't do.

by jeresig 15y ago

ThePinion 15y ago

An informative reply from Mr. Resig himself :) Thanks! I understand now. I generally use .attr to retrieve the id, class, or something like that, which isn't something that usually changes in my scripts. I mainly stick to .val() for inputs, so this definitely clears up my concerns. I'll go through my code a bit to see if I need to make any changes, but it doesn't seem that way now that it's all more clarified for me.. Besides a couple cases where I check the state of checkboxes. Thanks again for your help, and for jQuery in general. It's made my life/job easier in a completely indescribable way. (I used to be afraid of Javascript.)

crescentfresh 15y ago

> Continuing to use .attr()/.removeAttr() will probably be just fine Your blog post calls them "breaking changes" for a reason though. Code that does `if ($elem.attr('checked'))` needs to be rewritten to use .prop when upgrading. Saying "It probably (hopefully) won't [affect your applications]" is slightly contradictory.

mrchess 15y ago

Is prop('value') faster than val() now for reading dynamic input?

jeresig 15y ago
Probably - but that's mostly due to the fact that .val() does more to ensure that the value being returned is useful (such as turning selected options into arrays, etc.).

deleted 15y ago

[deleted]

peteot 15y ago

Honestly, I think that jQuery pre-1.6 did the right thing almost all the time and we all learned to deal with the boolean attribute edge case just fine. I feel like this change is taking jQuery in the wrong direction. We don't want to look back and say "1.6 is where the bloat began..."

timdown 15y ago

That's quite a simplified explanation which sidesteps the issue of properties that correspond to attributes, which is where most of the confusion is going to be. And I totally disagree with your description of things like Boolean attributes/properties as "weird edge cases": their behaviour in most browsers is well-defined, consistent and not really at all weird, particularly if you limit yourself to using properties rather than attributes, which is almost always the correct approach. Saying that it probably won't affect existing applications is just misleading. 1.6 fundamentally changes the behaviour of attr(), which is a very complicated and commonly used method. Furthermore, there's really no point in this if you're not going to encourage people to move to prop() rather than attr(). The messages coming from jQuery about this change seem very vague to me. If you're going to spring this kind of change on your users then they need to understand what it is that you've changed and why it's a good thing (I think it is, by the way), which one documented example and a hand-wavy assurance that it might probably be mostly OK doesn't do.