While trying to implement my CodeDodger loader script, (a fresh look at dynamic DOM injection for script and link tags using DocumentFragment) I noticed the JavaScript and CSS was not processed in IE. I did a lot of research and testing just to find out that IE does not treat an appended DocumentFragment the same as an appended element.

When comparing my script to that of a simpler script to load css/js dynamically on Dynamic Drive, I found virtually no difference in methodology except DocumentFragment. I still tested every possible way to construct the link/style tag but all had the same results. Strangely, the IE developer tool reports the DOM was modified successfully:
2009-07-08_151300

Even though the new DOM nodes appear correctly, the browser never processed associated files. Even stranger, the IE dev tool finds the JavaScript files and I can run the code in the console referencing the included files:
2009-07-08_152119

This caused me to wonder about the timing of my scripts in IE (of course, all other browsers work just fine). I tried wrapping my evocations (built dynamically in the page with PHP) inside a jQuery document.ready call and proceeded that function with:

    if (typeof jQuery === 'undefined') {
       alert('break') ;
    }

IE always alerted “break” despite the files loading from cache and having several milliseconds to process before the page completely rendered. So, I tried another trick and wrapped my invocation inside

setTimeout(function(){
  //put evocation here
,0);

That actually worked. My page included and processed the new JS files then executed the evocation on a “ready” DOM (it has something to do with the difference between document.ready and pageLoad and IE being IE).

I found no such work-around for the CSS files. So, if I want to keep CodeDodger geared toward high-performance, I will need to detect for IE and skip the fragment to insert the CSS link tag directly into the DOM. I know this will perform slower and could cause blocking but I don’t think I have a choice–thanks IE.

Edging out Chrome in anything remains a mark of achievement but will users feel like FF 3.5 actually browses faster than Chrome 2?

I reviewed the charts at the UA Profiler. FF only supports one feature that Chrome does not, link prefetching. Since only FF supports it and it requires new development practices, I doubt it will make much impact with users on most sites.

Only one quantifiable performance measure on the UA Profiler differs between Chrome and FF, maximum connections, with the edge going to Chrome. Couple that with the outstanding JavaScript performance in the new Chrome Chrome remains the browser to beat.