Jcrop was primarily developed under Firefox. I was pleased to see that only minor modifications were needed to achieve the same functionality in Safari and Opera. However, early versions would not function in Internet Explorer. The difference between getting it working in Safari and Opera was that arguably those were bug fixes. Getting it to work in IE involved straight-up hacking!
Isn't it amusing that one day, not so many years ago, everything was designed for IE5 or IE6, and it was the "other" browsers that weren't compatible? And now today, the only way to get anything advanced to work in IE is to hack perfectly beautiful code with a bunch of IE-specific workarounds. Just to get it to work. And yet, everyone BUT the largest software company in the world is now offering a browser that works and plays in a standard way.
One thing that seems unforgivable about Internet Explorer is that it doesn't seem possible to run both IE6 and IE7 on the same machine. How stupid! Considering IE6 is possibly the most wide-spread browser in use even today, it doesn't seem conscionable that as a developer I could upgrade to IE7 then. Luckily, fixing Jcrop to run on IE6 also fixed it for IE7 (I had someone else check)...so we're good to go.
Read on for the finer points...
Getting Jcrop functional under Internet Explorer involved some bizarre workarounds. Hopefully this information helps someone else having these issues, or answers some questions about why Jcrop is a bit quirky under IE...
First of all, you can't attach a handler to an element that IE thinks is empty, which was why it was totally non-responsive to the mouse in early versions. However, if the element has a background color set, then you can attach handlers. The obvious, if undesirable, solution here was to add CSS rules for IE that set the background color for the tracking elements, but set their opacity to 0.
Another odd behavior in IE is that a div cannot be "shorter" than the height of the font. So, I had to add CSS rules for font-size: 1px, which seems to be the accepted hack. Get with it Bill!
Unfortunately, these CSS rules were added with the infamous *-rule hack for IE. Sorry about that (but do take note of these issues if you're trying to skin Jcrop).
Jcrop also performs some minor CSS hacks at runtime under IE.
The biggest problem with Jcrop under IE is bizarre selection behavior that results if you drag too far off the image with the mouse button down.
It creates ugly effects like this:
trackDocument disabled by default for IE. The potential solution to the selection problems is to attach the mouse events to the document/window. However, for some reason (these things become comical at some point), the performance suffers miserably if this is done. This setting can be overridden, but this is not advised as doing so currently breaks IE compatibility.
Out of all the browsers I've tested, the performance is worst in IE. Sometimes when you're dragging the handles it will flicker the cursor a bit, which seems to degrade the responsiveness. Then you can click on the same handle again, and the behavior is "normal" and the cursor does not flicker. However, I believe Jcrop is acceptably functional in IE6/7 if you don't get too crazy.
keySupport disabled by default for IE. I'm not sure if this helps the performance or not, but the keyboard support under IE is less consistent anyway, so Jcrop disables keySupport under IE unless you explicitly set the option keySupport: true
With IE8 lurking, I'd like to think this page could be eliminated, but likely it will only get longer. I will continue to tweak Jcrop to improve IE compatibility. Some issues may have answers, and some may not. If you have any ideas you'd like to share, please contact me.