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:

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:

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.