XML DOM hacking in MSIE: halp!

[prog]

Righto, I just sacrificed a couple of hours on the altar of trying to get shit to work in MSIE. On the plus side, I think I can eliminate one of the third-party libraries I've been using; MSIE was barking at it, and I find that I can do the same thing it was doing using Prototype, which the application already depends on.

On the minus side, MSIE's XML API eludes me. Consider this code snippet. Given xml_request, an XMLHttpRequest object:

    alert(xml_request.responseText); // This prints the correct thing.
    var xml_doc = xml_request.responseXML;
    var root_element = xml_doc.documentElement;
    if (root_element) {
        alert("I have a document element. I am a sane browser!");
    }
    else {
        alert("I have no document element. I must be MSIE. Fuck.");
    }

The initial alert() makes me sure that MSIE (as well as any other browser) is in fact reading the XML. I just can't do a damn thing with it after that; every attempt to peek into any DOMmish properties of xml_doc returns null.

xml_doc.firstChild and equivalent statements all fail equally (while succeeding on sane browsers). Wha?

---

Another good reason to drop the library I am dropping? It contains lines of code like this:

MWJ_ldD[MWJ_ldD.length-1].onreadystatechange = new Function( 'if( MWJ_ldD['+(MWJ_ldD.length-1)+'].readyState == 4 ) { '+oFunct+'(MWJ_ldD['+(MWJ_ldD.length-1)+'].load?MWJ_ldD['+(MWJ_ldD.length-1)+']:MWJ_ldD['+(MWJ_ldD.length-1)+'].responseXML); }' );

Holy hannah. That's no way to make friends.

Comments

[chocorisu.livejournal.com]

msdn.microsoft.com... it's a pain to search but it's all on there. Handy trick: use "site:msdn.microsoft.com" to search it with Google. It'll be way less painful than using Microsoft's search tools.

[jaq.livejournal.com]

You might find Sarissa helpful?

[jaq.livejournal.com]

p.s. I have a bit of code at work that does something similar - I'll refresh my memory on Monday.

[cnoocy]

Is xml_doc even defined? You may need different syntax there.

[prog.livejournal.com]

Yeah, it's defined. Note that peeking at its documentElement property doesn't make JS crap out (as it would if it were null). And it does self-identify as an XML document node if you ask it.

[ahkond.livejournal.com]

What do you get from alert(xml_request.responseXML)? Just to see whether it's empty or not ...

Is it possible that calling xml_request.responseText empties the xml_request object, and that subsequently calling .responseXML therefore returns an empty XML document?

[misuba.livejournal.com]

No, responseXML should still be there. XHR objects aren't one-use like that. This does not mean that IE is doing anything sensible with the XML once it gets it, however. (I can't shake the feeling that it just has some minorly different way to get there than 'documentElement', but for the life of me I... ooh! I know! The flamingo book! I'll be right back)

[misuba.livejournal.com]

I'm betting that that library code is the result of a packing algorithm meant to reduce the time it takes to move the JS over the wire. There may be a more readable version available. OTOH, that looks pretty lengthy for packed JS.

I found a few articles on JS and XML that have techniques that might be helpful, but they aren't anything the most casual googler couldn't dig up. There is this, though, if you don't have something like it (it ain't Firebug but it's pretty handy): JavaScript Shell for IE

[prog.livejournal.com]

Everyone knows it loads faster if you remove all the whitespace. Naming your variables through keymashing makes it even better.

[misuba.livejournal.com]

Seriously, for libs like Prototype that get up to 200K when you add script.aculo.us to the picture, some of those techniques can really count. I've seen 75% reductions.

[prog.livejournal.com]

gzip, m'man.

I have yet to come to a place where it's worth sacrificing maintainability for optimization. Or anything else.

I'm not saying there is no such place... but I haven't been there yet, if so.

i have

[jtroutman.livejournal.com]

high volume pages frequented by dialup users.

But in general, yeah, gzip compression. I did some testing on $JOB's website (upwards of ~40k unique visitors per day at peak), and enabling gzip for HTML cut total bandwidth utilization by 55%.

I do admit to using HTML/CSS stripping tools on outbound opt-in emails. Shaving a few kb does seem to make a difference. This means I have also sent HTML format emails, for which I am deeply shamed.

Re: i have

[prog.livejournal.com]

You're actually backing up my point here! I remain highly resistant to the idea that it's ever necessary to make your code as unreadable and unmaintainable as my example for the sake of optimization. There's always a better way (such as gzip).

[misuba.livejournal.com]

OK, few more things:

Does xml_doc.nodeType evaluate to 9? It should.

Does going straight to xml_doc.childNodes yield anything fruitful?

Surprisingly, a look at the Prototype API docs doesn't reveal any special sauce for the responseXML property. You'd think that they had a basic browser incompatibility like this one handled.

[ahkond.livejournal.com]

You'd think that they had a basic browser incompatibility like this one handled.

AHAHAHA you're funny!

[misuba.livejournal.com]

By "they" I mean the authors of the Prototype library. Handling browser incompatibilities is like a third of why they exist.

[ahkond.livejournal.com]

Ah - I thought you meant MSIE.

[daerr.livejournal.com]

And xml_doc.documentElement.firstChild doesn't work?

I'm pretty sure that xml_doc.firstChild isn't actually valid.

[prog.livejournal.com]

xml_doc.documentElement returns null. So, no.