![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Developer's Notebook addendum
Sep. 17th, 2007 09:25 amThis blog is now on the first page of Google hits for [fuck msie]. (It is also the number-one hit for [msie fuck]. Ha.)
A couple of techie followups
Jun. 25th, 2007 04:37 pmResearch, including asking y'all earlier, has led me to believe that if there is a way to have MSIE 6 and 7 running independently on a single Windows machine, it's almost certainly not worth the tremendous effort involved. Nor is it worth the questionable level of stability that this level of DLL and registry contortion would no doubt leave the machine in.
I will instead take![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
mr_choronzon's advice and carve out a second, file-based VMWare machine on my Mac, expressly for running 7. This is a sad sacrifice of hard disk space for running a single test-target application, but I really see no other reasonable way.
Had a comment thread a while ago about maintainability versus size in client-code that has to be sent over the wire (most commonly, JavaScript in web pages). Since then I've encountered a happy medium that many perfectly clueful entities employ.
It's apparently SOP for organizations that deal with tremendous amounts of traffic to code in a nice clean fashion with as much whitespace and as many long variable names as you please, but before going into active duty each such piece of code is pseudo-compiled (really, obfuscated) down to an ultra-compact size, making it as small as possible without any loss of meaning. These files are then treated like compiled binaries, even though they're still interpreted scripts: the developers never touch them directly, instead making further changes by editing the long-form scripts and then re-compressing them.
I will instead take
mr_choronzon's advice and carve out a second, file-based VMWare machine on my Mac, expressly for running 7. This is a sad sacrifice of hard disk space for running a single test-target application, but I really see no other reasonable way.Had a comment thread a while ago about maintainability versus size in client-code that has to be sent over the wire (most commonly, JavaScript in web pages). Since then I've encountered a happy medium that many perfectly clueful entities employ.
It's apparently SOP for organizations that deal with tremendous amounts of traffic to code in a nice clean fashion with as much whitespace and as many long variable names as you please, but before going into active duty each such piece of code is pseudo-compiled (really, obfuscated) down to an ultra-compact size, making it as small as possible without any loss of meaning. These files are then treated like compiled binaries, even though they're still interpreted scripts: the developers never touch them directly, instead making further changes by editing the long-form scripts and then re-compressing them.
Non-ranty MSIE question
Jun. 12th, 2007 12:14 pmHow do you install MSIE 7 without killing your MSIE 6 install? IIRC this is non-trivial. Tell me if the world has changed since I last checked.
I wanna be able to test on both...
I wanna be able to test on both...
XML DOM hacking in MSIE: halp!
Jun. 1st, 2007 11:25 pmRighto, 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
The initial
Another good reason to drop the library I am dropping? It contains lines of code like this:
Holy hannah. That's no way to make friends.
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.
