The IE Factor

I relate it to a driving experience. One in which I drive to a certain destination often enough, that I become more and more familiar with the route that takes me there. I learn the best streets getting to and off the freeway system, every exit along the way. I know the interesting segments, the boring stretches. Most importantly, I start to recognize traffic patterns, and can predict the areas of congestion that will slow me down. No matter which route I take, there’s usually one portion of the trip where I know I’ll slow to a crawling pace. Some routes can’t be avoided, and the delays they bring must be factored into the total time I think the trip will take.

Such is often the case when designing with CSS. When working with semi-complex layouts, I frequently encounter challenges that end up slowing me down. I’m getting familiar with these road blocks, and can often predict where I’ll find them. Having patience, or knowing what to try to get around them prevents head from going through monitor.

Without a doubt, the biggest challenge I encounter each time is in wrangling Microsoft’s Internet Explorer browser. This devil does not play fair. It often follows no rules, and its behavior defies all common logic. It will double margins for no apparent reason. Borders disappear, 62 pixels magically turn into 143 pixels. It dodges left when other browsers go right. I’ve decided to call this phenomenon “the IE Factor“. (Those familiar with authoring DHTML four or five years ago already know where I’m headed with this.)

While working on the final stretch of a client project last week, I got stuck in a patch of quicksand. Design was finalized long ago. The bulk of CSS was authored over the holidays. Mozilla, Firebird, Safari, and Opera were all rendering the design beautifully, give or take a few small hiccups. But the design still had a few major quirks in IE (both Windows and Mac versions). “Ok, no problem — I need to spend an hour or so squashing bugs in IE.” That hour turned into two full days. Days filled with head-scratching and mind-numbing deconstruction and isolation of declaration blocks and properties. Progress came to a screeching halt while I tried every trick in my book. Solving one problem revealed another. Making a fix for IE would throw off the other browsers. Tweaks that should have worked had no effect, prompting me to try things that made absolutely no sense to try. And lucky me, IE/Win and IE/Mac have completely different bugs.

To be fair, IE/Mac has a predictable set of bugs which have known workarounds. But as I stated above, IE/Win will defy all common logic. Which makes it such a difficult browser to troubleshoot. I don’t dwell on the box model problems in version 5.x. Those can be dealt with. It’s the idiosyncrasies of IE5.0, IE5.5, and IE6.0 together (or in different combinations) that will drive a CSS author mad.

At times, I thought about writing every one of my style sheet rules using child selectors, filtering IE/Win out completely and serving it the same unstyled version as Netscape 4. But of course, IE possesses too much market share to turn off a design for every person using it. My client couldn’t — and wouldn’t — agree with that type of decision. So I had to compromise on each bug. If I couldn’t find an acceptable solution, or beat IE into submission, I’d decide to turn off that feature or design attribute just for IE/Win. Nice hover effects over those icons? Sorry IE, you won’t get them. A nice little bottom border on this box, like EVERY OTHER BROWSER renders correctly without going into convulsions? Sorry IE, you don’t get that either. You’re too fragile for a simple border. What kills me is the extra markup I’ll sometimes give in and add, just to get IE to render a critical part of the design correctly.

On numerous occasions, I’ve been bogged down by Internet Explorer’s incomplete support of CSS. I spent an extra 2 weeks trying to figure out why IE was bungling the Wired News layout. I should have known that I’d encounter difficulty with my project last week. But those two days of lost time hit me hard. I was over-confident that I could catch anything IE threw at me, thinking I could solve it quickly and easily. Silly rabbit. In reality, I’ve now calculated the IE Factor can add upwards of an additional 10% in time and cost for each project, distorting the estimating process if it’s not figured in.

So, you could say I’m becoming familiar with the route. I’m learning the best paths to tread when constructing designs with CSS. I know the interesting segments, the boring stretches. Most importantly, I’ve started to recognize patterns, and can predict the areas that will slow me down. Specifically, I know about the IE Factor. I don’t like it one bit, but at least I can prepare, and expect to encounter it for each project. And I’m building up an arsenal of weapons for use against IE when it misbehaves in the future.

The browser wars are supposedly over. We’re supposed to be at peace now. Everyone is supposedly cooperating. We’re supposed to be living in an era where we don’t need to alter code and make unique design decisions for each browser. We’re close, but I don’t think we’re there yet.

Update: See one example of a bug which contributes to the IE Factor, described in detail in this entry.