

JQuery 1.6 released - potomak
http://blog.jquery.com/2011/05/03/jquery-16-released/

======
wyday
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/> ). Though it didn't freeze with any previous version
of jQuery.

~~~
jeresig
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.

~~~
crescentfresh
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.j...](https://github.com/jquery/jquery/blob/1.6/src/manipulation.js#L652)

Note the inner loop is clobbering the outer loop's "i" variable.

~~~
jeresig
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>

~~~
jeresig
The issue has been fixed and integrated into the current build of jQuery:
<http://code.jquery.com/jquery-git.js>

We're going to have a 1.6.1 release within the week. Thank you for your bug
report!

~~~
DTrejo
He gets a reward!

<http://rewardjs.com/>

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

~~~
troyk
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
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-
attri...](http://stackoverflow.com/questions/706384/boolean-html-
attributes/707702#707702)

~~~
pak
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.

------
simonhamp
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
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).

------
ThePinion
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
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.

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

~~~
jeresig
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.).

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

~~~
jeresig
Do you have more details on this? Can you file a bug report? Thanks!

<http://bugs.jquery.com/>

------
cubicle67
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

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

