6 ms·

JQuery 1.6 released

320 points by potomak 16y ago

ThePinion 16y ago
I love how quickly they're pushing out these releases. It's awesome to have my applications constantly improving in speed without me having to do much. Although I'm honestly a bit confused on their explanation of .prop and .attr now... Maybe I should just re-read it slower, or give myself a little more time to wake up. Unless someone would care to explain it in simpler terms for me. ;)
- jeresig 16y 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 16y 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 16y 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 16y ago
    Is prop('value') faster than val() now for reading dynamic input?
    - jeresig 16y 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 16y 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 16y 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.
- morrow 16y ago
  If I understand correctly, .prop reflects the current state of the DOM, .attr reflects the state when loaded or last updated with javascript. If you have: <input id="test" type="text" value="initial" /> On load, the page should show for $("#test") .prop("value") = "initial", .attr("value") = "initial" Then, if you type in "current" into the 'test' input box, the page should show: .prop("value") = "current", .attr("value") = "initial" without any other events taking place that would update the value.
  - ThePinion 16y ago
    Thank you! The pure definition of simpler terms I was looking for. Going through my code now to see if I need to make changes!
    - mcrittenden 16y ago
      Note that in the above example, one should really be using .val() instead of .attr('value'), and if so, then nothing will need to be changed.
  - pak 16y ago
    Question: When would you ever want the .attr("value")=="initial" in real code? How often is it that you want the original value encoded in the HTML as opposed to the current value of the element as entered by the user? This is part of why I think .prop vs .attr is a regression. It makes me think twice before I use either--even if this is closer to how the DOM actually behaves, the point of jQuery used to be that it could hide those inane details from me.
    - timdown 16y ago
      The difference between attributes and properties is not an inane detail. It's fundamental, and if you don't understand it then you can't work reliably with the DOM, either with or without jQuery. Bottom line: use prop().
    - donalm 16y ago
      You could use it to test if the value has been changed.
rauljara 16y ago
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.
- troyk 16y 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 16y ago
    Which changes (I assume, to .attr()) are affecting you, in particular?
    - troyk 16y 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 16y 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...
wyday 16y ago
This release causes Internet Explorer 6 to freeze just by including the script in the page. This is a non-starter. I'll submit a bug report about it later today, just thought you guys would like to know in the meantime. EDIT: It looks like the freeze on IE6 might be caused by FancyBox (http://fancybox.net/ http://fancybox.net/ ). Though it didn't freeze with any previous version of jQuery.
- deleted 16y ago
  [deleted]
- jeresig 16y ago
  A reduced bug report would be good. We haven't seen any reports of this elsewhere (and the jQuery test suite runs to completion in IE 6) so I'm not entirely sure what could be happening here. Any insight you can provide (and a bug report) would be appreciated.
  - deleted 16y ago
    [deleted]
  - crescentfresh 16y ago
    Simple reproduce case: <html> <head> <script src="http://code.jquery.com/jquery-1.6.min.js"></script> </head> <body> <script> $('body').append( '<span></span>', '<span></span>', '<span></span>' ) </script> </body> </html> The bug is in this block: https://github.com/jquery/jquery/blob/1.6/src/manipulation.js#L652 https://github.com/jquery/jquery/blob/1.6/src/manipulation.j... Note the inner loop is clobbering the outer loop's "i" variable.
    - wyday 16y ago
      Fantastic find, crescentfresh! Changing "i" to "j" in the inner loop fixes the problem on IE6. Now we just have to wait for jQuery 1.6.1.
    - jeresig 16y ago
      Oof! That's no good, at all. We'll fix this right away. Thanks for the reduction. Just filed it here: http://bugs.jquery.com/ticket/9072 http://bugs.jquery.com/ticket/9072
sciolistse 16y ago
Seems to have caused using an array to specify easing in jQuery.animate to break. Was a bit surprising.
- jeresig 16y ago
  Do you have more details on this? Can you file a bug report? Thanks! http://bugs.jquery.com/ http://bugs.jquery.com/
  - deleted 16y ago
    [deleted]
imsky 16y ago
Switched to it and the animations really look smoother now. Sweet release, can't wait for 1.6.1!
deleted 16y ago
[deleted]
simonhamp 16y ago
I love how fast jQuery is progressing, but it does seem that ultimately the separations of various disciplines (particularly this .attr() and .prop() debate) is a step away from the convenience of jQuery-past. It's understandable though, because helpers and abstractions add bloat and latency to interactions with the various DOM interfaces. And this latency is the price we have to pay for the benefits these abstractions give us - which include a unified interface to the DOM of many browsers. The balance of speed vs convenience is very difficult for frameworks like jQuery looking to work for as many people as possible... if you want the convenience at the sacrifice of speed or conversely prefer the speed to the convenience you have one option: build a library specific to your app or your needs. The rest of us will use jQuery ;)
- timdown 16y ago
  In the case of attr(), the convenience jQuery was adding was an enormous fudge and attempted to gloss over the fundamental difference between attributes and properties, which has directly led to vast confusion and misunderstanding among developers. It was impossible for even jQuery core developers to explain what attr() was supposed to do. The pre-1.6 attr() was a design mistake that 1.6 is attempting to rectify, which must be a good thing (provided it's been done sensibly).
cubicle67 16y ago
it's broken Nivo Slider (2.5.1) but a global replace of '.attr(' with '.prop(' has fixed it. Not sure if this is the best thing to do, but it works

320 points by potomak 16y ago

I love how quickly they're pushing out these releases. It's awesome to have my applications constantly improving in speed without me having to do much. Although I'm honestly a bit confused on their explanation of .prop and .attr now... Maybe I should just re-read it slower, or give myself a little more time to wake up. Unless someone would care to explain it in simpler terms for me. ;)

jeresig 16y 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 16y 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 16y 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 16y ago
  Is prop('value') faster than val() now for reading dynamic input?
  - jeresig 16y 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 16y 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 16y 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.
morrow 16y ago
If I understand correctly, .prop reflects the current state of the DOM, .attr reflects the state when loaded or last updated with javascript. If you have: <input id="test" type="text" value="initial" /> On load, the page should show for $("#test") .prop("value") = "initial", .attr("value") = "initial" Then, if you type in "current" into the 'test' input box, the page should show: .prop("value") = "current", .attr("value") = "initial" without any other events taking place that would update the value.
- ThePinion 16y ago
  Thank you! The pure definition of simpler terms I was looking for. Going through my code now to see if I need to make changes!
  - mcrittenden 16y ago
    Note that in the above example, one should really be using .val() instead of .attr('value'), and if so, then nothing will need to be changed.
- pak 16y ago
  Question: When would you ever want the .attr("value")=="initial" in real code? How often is it that you want the original value encoded in the HTML as opposed to the current value of the element as entered by the user? This is part of why I think .prop vs .attr is a regression. It makes me think twice before I use either--even if this is closer to how the DOM actually behaves, the point of jQuery used to be that it could hide those inane details from me.
  - timdown 16y ago
    The difference between attributes and properties is not an inane detail. It's fundamental, and if you don't understand it then you can't work reliably with the DOM, either with or without jQuery. Bottom line: use prop().
  - donalm 16y ago
    You could use it to test if the value has been changed.

rauljara 16y ago

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.

troyk 16y 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 16y ago
  Which changes (I assume, to .attr()) are affecting you, in particular?
  - troyk 16y 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 16y 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...

wyday 16y ago

This release causes Internet Explorer 6 to freeze just by including the script in the page. This is a non-starter. I'll submit a bug report about it later today, just thought you guys would like to know in the meantime. EDIT: It looks like the freeze on IE6 might be caused by FancyBox (http://fancybox.net/ http://fancybox.net/ ). Though it didn't freeze with any previous version of jQuery.

deleted 16y ago
[deleted]
jeresig 16y ago
A reduced bug report would be good. We haven't seen any reports of this elsewhere (and the jQuery test suite runs to completion in IE 6) so I'm not entirely sure what could be happening here. Any insight you can provide (and a bug report) would be appreciated.
- deleted 16y ago
  [deleted]
- crescentfresh 16y ago
  Simple reproduce case: <html> <head> <script src="http://code.jquery.com/jquery-1.6.min.js"></script> </head> <body> <script> $('body').append( '<span></span>', '<span></span>', '<span></span>' ) </script> </body> </html> The bug is in this block: https://github.com/jquery/jquery/blob/1.6/src/manipulation.js#L652 https://github.com/jquery/jquery/blob/1.6/src/manipulation.j... Note the inner loop is clobbering the outer loop's "i" variable.
  - wyday 16y ago
    Fantastic find, crescentfresh! Changing "i" to "j" in the inner loop fixes the problem on IE6. Now we just have to wait for jQuery 1.6.1.
  - jeresig 16y ago
    Oof! That's no good, at all. We'll fix this right away. Thanks for the reduction. Just filed it here: http://bugs.jquery.com/ticket/9072 http://bugs.jquery.com/ticket/9072

sciolistse 16y ago

Seems to have caused using an array to specify easing in jQuery.animate to break. Was a bit surprising.

jeresig 16y ago
Do you have more details on this? Can you file a bug report? Thanks! http://bugs.jquery.com/ http://bugs.jquery.com/
- deleted 16y ago
  [deleted]

imsky 16y ago

Switched to it and the animations really look smoother now. Sweet release, can't wait for 1.6.1!

deleted 16y ago

[deleted]

simonhamp 16y ago

I love how fast jQuery is progressing, but it does seem that ultimately the separations of various disciplines (particularly this .attr() and .prop() debate) is a step away from the convenience of jQuery-past. It's understandable though, because helpers and abstractions add bloat and latency to interactions with the various DOM interfaces. And this latency is the price we have to pay for the benefits these abstractions give us - which include a unified interface to the DOM of many browsers. The balance of speed vs convenience is very difficult for frameworks like jQuery looking to work for as many people as possible... if you want the convenience at the sacrifice of speed or conversely prefer the speed to the convenience you have one option: build a library specific to your app or your needs. The rest of us will use jQuery ;)

timdown 16y ago
In the case of attr(), the convenience jQuery was adding was an enormous fudge and attempted to gloss over the fundamental difference between attributes and properties, which has directly led to vast confusion and misunderstanding among developers. It was impossible for even jQuery core developers to explain what attr() was supposed to do. The pre-1.6 attr() was a design mistake that 1.6 is attempting to rectify, which must be a good thing (provided it's been done sensibly).

cubicle67 16y ago

it's broken Nivo Slider (2.5.1) but a global replace of '.attr(' with '.prop(' has fixed it. Not sure if this is the best thing to do, but it works