It is working great in all browsers EXCEPT Internet Explorer (all versions 6.0+, as far as I can tell.) Here is a URL that you can use to see the problem. If you open this URL in Firefox, Safari or Chrome and use Firebug or Web Inspector, no jQuery issues.
Open the page up in google chrome and check the console. Are you getting any warnings about jquery.js being transferred as some weird mime-type, such as text or html? I've been seeing a lot of that lately.
It is really simple. You need the jQuery to load before you start using it. When you document.write it all, it all gets parsed at the same time and not in order. Have it write a reference to another file that has the noConflict in it. That way it has to complete the parse of the jQuery before it tries to use jQuery.
One of your sales guys asked me to take a look at this so I checked your link and it seemed to be working fine in IE9. I did a little testing and I think the problem is that you are using the "true" parameter in your no conflict call. By passing the true parameter you are making the jQuery variable unavailable to jQuery libraries. You can read about it here. http://api.jquery.com/jQuery.noConflict/ So my guess is that subsequent to your no conflict call you are calling a library which is trying to use the jQuery variable which you have left undefined. So change your
var hcjq = jQuery.noConflict(true); line to
var hcjq = jQuery.noConflict(); and try again. I think that should clear up your problem.
Hi guys, thanks so much for all the responses. Some of these answers are on the right track, so I appreciate the help. So here's a couple things to note:
whitefrog: The order doesn't seem to make any difference, just FYI.
There, we were trying to figure out why IE (only) had this bizarre behavior that jQuery would suspend itself half way through, run jQuery-UI (which would fail since jQuery wasn't fully defined), and then come back to jQuery. Turns out it's because jQuery modifies the DOM during its support feature tests, and this triggers this behavior in IE that tells it to go look for other ready-to-execute scripts.
That same behavior could explain why you are seeing this. I'm not 100% positive, but I'm like 99.9% positive it's the same culprit.
Problem is, there's no super-simple solution/work-around. It's a fairly complex issue.