The jquery plugins are young, and you can usually find answers to all these things in #jquery on freenode. I'm surprised they break your IE, because jquery is one of the few libraries that does some very extensive optimization for IE, unlike some of the other top dogs.
I think a common paradigm is to develop for firefox (because it's convenient to debug with firebug, etc.) and then test in IE and figure out where IE's issues are. You'll learn things that IE doesn't like and avoid them in the future. IE doesn't have some of Gecko's js features, like generators and array comprehensions, so don't touch those. Also, in IE, a trailing comma in an inline object declaration is a syntax error:
var x={0,};
//i find this syntax convenient, so that always pisses me off
The event object disappears if your event handler invokes something to be done on a fresh callstack, even if you still have a reference to the object itself:
function someHandler(e){ setTimeout(function(){alert(e);},0); }
//only lost when called via event invocation, and i'm not sure how widespread this problem is
Some DOM properties/attributes may be different/present/absent, but if you use jquery that'll be abstracted away. The event model in IE is lame (level 2 stuff), allowing you to attach only one listener per event per object, but jquery abstracts that away as well. What else... IE is known for leaking memory because each DOM element is actually a COM object, and cyclical references between the js engine and COM are undetected. There's a young tool called sIEve (currently v0.0.8) that can help you detect what leaked. anything else you want to know?
JQuery also fixes the memory leaks if you remember to call .empty() or .remove() on any dynamically created elements on unLoad(). It nulls out all event handlers and DOM references, recursively, breaking the cycles that make IE hang onto memory.
Also, plugins use $.data rather than directly attaching information to DOM elements, which was added to fix memory leak problems.
I think a common paradigm is to develop for firefox (because it's convenient to debug with firebug, etc.) and then test in IE and figure out where IE's issues are. You'll learn things that IE doesn't like and avoid them in the future. IE doesn't have some of Gecko's js features, like generators and array comprehensions, so don't touch those. Also, in IE, a trailing comma in an inline object declaration is a syntax error:
var x={0,}; //i find this syntax convenient, so that always pisses me off
The event object disappears if your event handler invokes something to be done on a fresh callstack, even if you still have a reference to the object itself:
function someHandler(e){ setTimeout(function(){alert(e);},0); } //only lost when called via event invocation, and i'm not sure how widespread this problem is
Some DOM properties/attributes may be different/present/absent, but if you use jquery that'll be abstracted away. The event model in IE is lame (level 2 stuff), allowing you to attach only one listener per event per object, but jquery abstracts that away as well. What else... IE is known for leaking memory because each DOM element is actually a COM object, and cyclical references between the js engine and COM are undetected. There's a young tool called sIEve (currently v0.0.8) that can help you detect what leaked. anything else you want to know?