Subtraction.com

The Many Crimes of Internet Explorer

Some people just think that my efforts to warn Internet Explorer users that the fidelity of this site is compromised when viewed in that Web browser is just a showy way of picking a fight. Maybe a little. But I’m being genuine when I say that the way Subtraction.com renders in I.E. is maddeningly imperfect, and I just haven’t the time or patience really to try and troubleshoot the problems. What I do have time for is a nitpicking catalog of those imperfections.

Three’s a Crowd (of Pixels)

What drives me the most crazy is the well-documented 3-pixel Text-Jog, which effectively nudges over any body of text that runs past a float by, you guessed it, three pixels. This is a problem I encountered when designing version Six.5 of this site, but, having had more free time at that stage and less care for keeping my HTML clean, I threw in another enclosing <div> around the body text. That fixed the problem but added yet another layer of complexity to the markup.

This time, I couldn’t bring myself to do that — depending on your point of view, my philosophy on code has gotten either more precious or more aware — so I just left it as is. Some people may not notice it at all, but it screams out loud and clear to me, especially as it’s plainly evident on the home page. It can also be seen in action in the Remarks section at the bottom of most individual article pages, and because the leading (line-spacing) is tighter there, it’s perhaps more noticeable too.

Above: The 3-pixel Text-Jog bug in full effect on the home page and the Archives page.

I.E. renders a similar indentation problem on the right column of Archives page, where the title of each category appears to hang out a little further to the left than the descriptions of that same category just below. Again, this is layout trainspotting, but it’s an irritation to me.

Below: Rolling over a nav box doesn’t work, though Fitt’s law — and my code — says it should. Directly rolling over the text does, but an unexpected border appears at the top.

Giving Me Fitt’s

Perhaps more seriously, I.E. doesn’t care much for the way I coded the navigation, to the point of almost breaking it, or at least crippling its usability seriously. If you hover over any part of a box in the navigation using Safari, Firefox etc., you’ll be able to activate the hyperlink without having to directly target the text itself. This, as a reader pointed out, is the behavior recommended by Fitt’s Law. However, if you roll over any navigation box in I.E., you must target the actual text directly with your mouse, or no roll-over will occur. What’s more, when the roll-over does occur — when the box turns orange — then an odd, single-pixel black border appears at the top. Another superficial imperfection, but by now you get a sense of how freakin’ uptight I am.

More Flaws

Predictable rendering errors, like the 3-pixel Text-Jog bug, are one thing, but inconsistent errors are another. Here’s one that only shows up at odd times: a double-rule effect that appears over some headlines on the home page and on monthly archives. I know exactly where the rule comes from; there’s a -1px margin-top on the headline to lay the top border on the headline directly on top of the longer border that demarcates the day. I.E. seems to know how to deal with this, but on erratic occasions, it flubs the effect somehow.

Above: Occasional double-border rendering. Below: Extra space in the Remarks form.

A more serious layout bug occurs in the Remarks form that appears at the bottom of most article pages. Again, these forms render fine when using the usual suspects, but I.E. adds a gaping white space above the first field, for a reason that I admittedly never investigated too seriously but that I don’t really understand nevertheless. To be fair, using CSS to apply layout precision to a Web form is an act of self-torture in any browser — which probably explains the dearth of documentation on how to do this. A List Apart, I’ve got an article idea for you.

My Secret Love for I.E.

All of which goes to prove that I.E. is sorely lacking in layout prowess (to say nothing of security). This is probably not news to very many designers, but it’s an obscure enough fact that I felt that I should point it out to open-minded readers who may be enticed to give Firefox a shot. That’s an altruistic explanation for my decision, but to be honest, I saw an opportunity to just ignore I.E.’s quirks outright, something that many CSS/XHTML advocates daydream about. This site is, after all, a personal endeavor that I’m doing for no financial remuneration; why not do whatever the hell I want?

That said, I was careful not to flagrantly offend I.E. users beyond my attention-getting caveat. It’s true that you can read every single line of text and every single page in this site with Internet Explorer, design flaws and all; this was a conscious decision. What’s more, as another reader pointed out, the style sheet specifies Arial for body text, with Helvetica as the back-up. Now, I really dislike Arial, finding it a pathetic imitation of Helvetica, but the fact remains that Helvetica looks pretty bad at 12 points on a Windows machine, where Arial looks… inoffensive. I wanted to ensure some level of visual competency for body text, so Arial won out. This is a decision I may reverse at some point, but for now, I’m sticking with it. As you can see, Internet Explorer users, I got yer back.

+