Web Tricks: 2006 Archives
It appears that in Firefox one must do somersaults to use javascript-opened windows and AJAX. There is a conflict between window.close() and AJAX and a delayed window.close() is prevented by a second Firefox bug where the window reference becomes corrupted in some way. The final solution appears to be to delay the AJAX call instead, using setTimeout().
One of my major gripes with IE has always been with the way it passive-aggressively recodes the html on every page it loads. Just take a look at view source. That's not my code. My code is pretty and lower-case with proper xhtml quotes on all attribute values.
IE does this so it can create the DOM tree (other browsers create the DOM tree just fine without mucking up code, but I guess this argument has never really been a motivator over at MS headquarters). And this is probably also why IE has so many problems with its DOM.
For instance, I've had lots of fun trying to change the select element's name through DOM in IE. Why would I want to do this, you ask? Well, I created a generic filepath dropdown on the server which I wanted to clone and insert into various parts of the form via DOM and rename "oldpath" and "newpath" and such. If I do it this way, it sort of works:
var x=document.getElementById("x"); //x is a select list with name and id "x"
var x2=x.cloneNode(true);
x2.id=x2.name="x2";
document.forms[0].appendChild(x2);
In this case, the innerHTML is wrong (the name remains "x") - and it remains wrong throughtout the life of the page and from every element's innerHTML in the page - but IE still sends the correct name in the form. And if you ever edit the page using innerHTML, it breaks (sends the incorrect name in the form).
document.forms[0].innerHTML+="New list:"+x2.outerHTML; //this does not work
So, you say, never use innerHTML in IE? It's not so easy. Some values can only be retrieved correctly from the innerHTML text. Try accessing href and src using getAttribute() and you will get a mucked-up absolute pathname. You have to parse it out of innerHTML to get the correct pathname.
And when you clone a select list, IE resets its selectedIndex to 0. Even the innerHTML is wrong here. You
have to manually reset the selectedIndex of the cloned list using the
selectedIndex of the original list using DOM. I have a sneaky suspicion that IE thinks this is desired behavior.
If this doesn't make your DOM life miserable enough, IE has several distressing DOM memory issues:
Understanding and Exploring Internet Explorer Leak Patterns
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/IETechCol/dnwebgen/ie_leak_patterns.asp)
Note that they never express any of these leaks as bugs. They are exactly the way things should be, and every JavaScript developer out there should be doing their aggressive DOM garbage collection or it's their own damn fault.
Yup, I love that browser.
OK, I understand IE's whole DOCTYPE quirks vs. standards (or strict) CSS variations (I don't agree, but I understand). But when did they decide to change their javascript as well (without backwards compatibility)?
http://aranea.zuavra.net/index.php/5 and http://www.quirksmode.org/js/doctypes.html
Basically, when you switch to standards mode, some of the IE proprietary javascript properties move from document.body to document.documentElement. document.body.scrollTop is now always 0 on a standards-compliant page, and the value can be found in document.documentElement.scrollTop instead.
Really, would it have been so hard to leave the document.body.scrollTop value? I know that the IE freaks love to tell us we should develop a million separate CSS files for each damn browser version they throw at us, but having to develop separate javascript as well is enough to make me want to jump up and down and scream violent profanities at my monitor.
Update 04/02/2006: I found a similar problem in Firefox. It is triggered by a more complex example involving tables and new form fields.
Yup, another fine IE bug. We were getting rare and unreproducible large (HUGE!) font size complaints from users on a new page (all the old pages were just fine) and only in IE. Customer Service - with the help of one clever user - finally tracked down the issue to the Windows XP Accessibility feature called "High Contrast." In my futile attempts to make the new page compatible with this Windows feature, I trailed the feature's failure down to nested relative font sizes. This is a fun one to reproduce on your own computer. Imagine all the lovely places it will occur on your own supposedly perfect web pages!
I found this one at work. The focus of an element disappears when clicking the scrollbar - but only in xhtml compliant pages! This irritated an amazingly huge number of people. Yet another instance of IE punishing me for trying to be standards-compliant.
