Monday, December 22, 2008

The IE6 AntiPattern

This might be a little behind the times but it’s still not uncommon for me to spend half a day or more just trying to fix CSS for IE6.  I was reminded of this while reading Joel Spolsky’s blog recently where he said

"I’ve been debugging the new site. The first problem: hopelessly messed up rendering on IE6. The best way to fix CSS problems with IE6 is to generate random mutations on the style sheet until it looks fixed. That’s really the only way to approach these kinds of things; CSS is nondeterministic, and many better minds than mine have gone completely stark raving mad trying to understand the rhyme and reason of IE6 rendering bugs." - Joel Spolsky

My method is not too different from that of Joel’s.  I know the hacks of putting a “#” before the class name or wrapping the entire CSS in “”.  But these are ridiculous work-arounds… and the amount of time wasted…  I wonder if the additional costs of maintaining MSN, Live, MSDN,, etc. for IE6 outweigh the expense of…

Allow me to digress.  Just the other day my uncle mentioned that he wanted to upgrade his version of Windows XP from the Home Edition to Professional  The reason is that Microsoft was going to stop supporting the Home version soon.  My uncle is the type of person that I would consider an average user.  He uses his computer for managing his photos, email, and the like – nothing fancy.  Because of people like my uncle, I’m pretty sure that IE6 isn’t going away any time soon.  And with IE 6 still at 20% of the market share, it’s a browser that we all have to support.

As far as I know, there isn’t much we can do about the situation except wait it out.  Hopefully with IE 8, Windows 7, and limited support for Windows XP the usage of IE will eventually end. 

And since we’re all complicit, we should also be thinking about how we got here (like the frog in the pot) and how we can make sure that this does not happen again.  I know the story conventional story line that IE 6 was “The Browser” at the time and so whatever worked on IE was correct.  Then came Firefox and it was back to trying to support two different browsers.  Then came IE 7 which was “broken” because it was “fixed”.  And now with the plethora of options (Safari, Opera, Chrome, etc.) we have our work cut out for us.

Friday, December 19, 2008

Isolating 3rd Party JavaScript

I'm looking for a way of protecting our web pages from 3rd party javascript files that might timeout or throw errors. These files are usually for ads where we just include a script reference.

What makes it worse is that these files contain code that does a document.write(). Because of this, moving the reference or trying to load the file asynchronously will cause the ads to be rendered on a different part of the page. Because of the use of document.write(), the only way to load the files without affecting the page's load time is to load them from within an iframe.

In addition, we can override on the onerror event for the page in the iframe.

This method scares me since I really can't imagine what would happen if other developers start putting this little snippet of script into all their pages. In addition this sounds like a whole lot of extra work just because some other companies product is problematic. Stop using their product is what I think.