
JQuery 1.3.2 Released. - azharcs
http://docs.jquery.com/Release:jQuery_1.3.2
======
zach
_The test suite has broken 1500 tests (1504, to be precise)._

Maybe "surpassed" would be a better verb here.

------
mcav
Those are some _very_ substantial speed improvements. Great to see, especially
since this was just a point release.

~~~
jeresig
We want to make sure there's some nice candy for those who upgrade. Getting
people to upgrade can be tricky - we do our best to reduce any outstanding
bugs (1.3.1 and 1.3.2 have helped here) but having a carrot on the end of the
stick helps a lot, as well.

~~~
sam_in_nyc
I love jQuery so much... it's exactly what a JS framework should be: easy ways
to select and modify DOM elements. The new visibility stuff is great! I've
always dreaded having to deal with "...but are its parents visible?"

There are some things jQuery isn't too great at (event normalization is slow
in IE, for example, and .remove() kills events and data), but I've never not
been able to easily extend jQuery to use my own implementation.

Thanks again for jQuery.

~~~
jeresig
Glad you're enjoying it so much!

As to the points you mention: "event normalization is slow in IE" Do you have
any information on this? This should've gotten faster in 1.3 - but it's
definitely something that we would want to improve, if that's not the case.

".remove() kills events and data" I agree that's lame. I have a new method
penciled in on the roadmap: .extract() - it removes an element from the DOM
but keeps all the data intact. I think this is what you're looking for!

~~~
sam_in_nyc
As per the IE performance... I usually feel the inclination to dig deeper and
figure out what the cause is, but not this time. It only reared its head
because it was on mousemove, which obviously gets fired a lot. I have a hunch
it's in computing the source element in certain cases, like floats or
absolutely positioned things.

To get around this, I use my own event normalization that seems to work across
all browsers and only normalizes what I need in any given project, for
example:

    
    
      var e = e || window.event;
      var fixed_e = {};
      fixed_e.pageX = document.all ? e.clientX + truebody.scrollLeft : e.pageX;
      fixed_e.pageY = document.all ? e.clientY + truebody.scrollTop : e.pageY;
      fixed_e.X = (e.offsetX ? e.offsetX : e.layerX) || 0;
      fixed_e.Y = (e.offsetY ? e.offsetY : e.layerY) || 0;
      fixed_e.source = e.target ? e.target : e.srcElement;
    

Another problem with jQuery events is unbinding is tricky.. I don't like how I
have to have a reference to the bound function laying around somewhere so that
I can unbind it. In my event system, adding an event returns a handle, which
allows you to simple call ".detach()" or ".attach()" or ".trigger()" .. it's
worked out very well for me.

As per the remove, I added a simple extension that's worked perfectly:

    
    
      $.fn.rm = function(){ 
        return this.each(
          function(){
            if (!this.parentNode) return;	//already removed.
            this.parentNode.removeChild(this); 
          }
        ); 
      }

~~~
jeresig
You can take a look at the event fixing code here:
<http://dev.jquery.com/browser/trunk/jquery/src/event.js#L285>

There's really not much to it - and it's really not much different from the
code that you show above. A lot has changed since 1.3 so if you're still
having problems, perhaps its not here and with some other aspect of the event
handling code. Any more input would definitely be appreciated.

"I don't like how I have to have a reference to the bound function laying
around somewhere so that I can unbind it."

Here are a couple ways to unbind an event handler without needing the original
function.

    
    
      $("div").bind("click", function(){});
      
      // Unbind all bound events
      $("div").unbind();
      
      // Unbind all click events
      $("div").unbind("click");
      
      $("div").bind("click.tmp", function(){});
      
      // Unbind all click events with the name 'tmp'
      $("div").unbind("click.tmp");
    

The last one is probably what you want.

~~~
sam_in_nyc
Sometime today I'll try to reproduce the conditions. It was definitely event
fixing (or something in jQuery) that did it, because even if I cleared out the
mousemove function, it would still be laggy. But if I didn't bind it, the lag
would go away.

You're right, the event namespacing was exactly what I was looking for.

BTW, is there a list of "reserved" words in jQuery? For example, jQuery has to
store this information somewhere... possibly it gets attached to the DOM
element itself. Where does ".data()" live? I often directly access the DOM
elements, and want to be sure I don't interfere with jQuery.

~~~
jeresig
We maintain all of the element data (including events, etc.) in an internal
data store. We attach a single expando to an element - whose name is randomly
generated (this allows jQuery to, not only, co-exist with other libraries but
also to coexist with other copies of jQuery, since there'll never be a
collision with the name). I hope this helps to clear it up.

------
Spyckie
This is a perfect example of how you should release new versions of code.

A well written explanation and good visualizations and statistics of what
changed (with the appropriate credit due).

It makes me want to upgrade instead of begrudgingly do so.

------
railsjedi
Extremely important update if you care about your IE users. In 1.3.1, ready()
was broke in IE so it only ran on window.load instead of DOM ready. I'd
recommend upgrading asap.

------
tocomment
I can't say enough good things about jQuery. I did a google search for "jQuery
changed my life" but not much came back :-(

------
jamongkad
truly the live callback has allowed me to do all sorts of crazy and creative
stuff with my apps. Thank you.

------
trezor
While all these updates seems welcome, I'm a tad sceptical against changing
API-behaviour in minor versions.

That way I can know an upgrade from 1.3.1 to 1.3.2 is safe across the board.

