Keeping Promises II: IE Quirks

Posted on 15th April, 2005 at 12:09am by joel

There isn’t a serious standards-focused web developer on the planet who hasn’t had irritating troubles with Internet Explorer. We’ve finally reached a point where IE on the Mac is largely irrelevant thanks to Safari and Firefox. Versions of IE on Windows older than 6 are also marginalized for the most part. However, even though IE6 offers decent standards support, it is filled with behavior from the bizarre to the downright idiotic (and everything in between, of course). I could list dozens upon dozens of these issues, and such bugs as “double margin” and “peek-a-boo” are just two well-named examples.

A Google search for “Internet Explorer CSS bug” returns “about 881,000” results. Granted, Firefox’s results are almost as high (790,000), but I’m whining about IE here, OK? Anyway, my point is that there are a lot of them and while many have been squashed—often with amazing solutions—more crop up every day. I came across a few interesting things that I’d never seen before. Here’s a quick rundown of the problems (and the solutions if they exist).

Italicized Text

I just discovered documentation of this bug this evening. Granted, I didn’t look too hard when I first came across the problem, opting to just make the quick fix and call it good. The italics weren’t mandatory and I was fine with removing them. If you scroll to the bottom of this post before the comments, you’ll see a paragraph in a box that starts with “You can follow…”.

After much hair-pulling, I discovered that this paragraph was the culprit in forcing IE to render the black content column about 4px too wide. After more hair-pulling, I learned that the font-style: italic; in my CSS for that particular paragraph was at fault. Fine, then. I removed that from the CSS and wrapped the paragraph in <em> tags. Crap. That didn’t work either. So, it was clearly a rendering problem. Making the text italic with the CSS caused the problems. So did making it italic with the XHTML. If I wanted to live with the rendering error in IE, I could have. However, those 4px of extra width looked like hell and I wasn’t going to take it.

The fix: Well, there really isn’t one. The paragraph is in a box (obviously) to set it off from normal paragraphs. I also added a font-size adjustment in the CSS to make the text a little smaller. Final verdict? Live with it or change the design. Oh, and complain. Loudly.

Those Tricky Negatives

If you haven’t discovered the style switcher yet, please scroll to the top to locate it. Then, switch over to the green “capri” theme if you’ve not already chosen it. Now, scroll all the way to the bottom to the “‹ return to top” button. See how it overlaps the bottom border of the content region? It works great on good browsers and IE. However, the way in which it happens is very different. Here are some code snippets (showing only relevant code):

#cbottom {
	position: relative;
	height: 8px;
}

#totop {
	position: relative;
	bottom: -20px;
	margin: -20px 18px 0 0;
	height: 30px;
}

As far as markup goes, <p id="totop"> is contained within <div id="cbottom">. Here is where the quirks come in: good browsers (Safari, Firefox, Opera) all line up the top of #totop with the top of #cbottom. Due to the height differences, this causes the former to overlap the latter, just how I want it. However, the rest of the CSS moves #totop down 20px thanks to bottom: -20px; and back up 20px as determined by the -20px top margin. “That’s silly,” you say, “you’ve just moved #totop back where it came from.”

The fix: And, you’re exactly right. IE is the reason I had to add that “silly” extra code. It lines up the bottom of #totop with the bottom of #cbottom and thus, doesn’t overlap the two. I successfully pulled #totop down where it belonged by using bottom: -20px;, but that broke good browsers. Fortunately, IE completely ignores the margin: -20px ..., allowing good browsers and IE to both display the button in the right place. And thank heavens for that, huh? Frankly, I am not sure if this is a bug as much as it was a quirk of my code, but I’m not even sure how to go about Googling for prior reports of this problem. I’m going to blame IE.

Line-Height Hair-Pulling

Last, but not least, we get to learn about my struggles with the style switcher—struggles which took at least an hour longer than they should have to resolve. Again, we’re working with “capri” with this problem. See that little row of buttons up there for the style switcher? They’re all carefully positioned absolutely when floats would have worked just fine and saved on code. Why? Because I was attacking a stupid problem from the wrong direction.

Again, see those little buttons? They’re exactly 20px tall. They’ve always been 20px tall. I designed them 20px tall and I’d like them to display 20px tall. IE didn’t agree. They were displaying 26px tall. This wouldn’t be so much of a problem if my sprites weren’t showing part of the over state as a result of the excess height. So, I had to fix them. But how? Easy.

The fix: Make the line-height of the text in the list items exactly the same as the height of the <dd> elements. Well, that’s a no-brainer, right? Meh, I guess. It seems that IE thinks that the 26px line-height should take precedence over the 20px height of it’s container. Safari, Firefox, and Opera all didn’t think so. They drew the box 20px tall and if the text wanted more space, it was out of luck and the box ended up 20px tall. I can see the logical argument behind either behavior, but I’m going to have to agree with the three vs. one point of view and [again] blame IE.

Wrap-Up

So there you have it. I ran headlong into Microsoft’s finest while prepping this site for launch. None of those three issues were fun to fix, though none were particularly hard either. I think that only the first can be legitimately called a “bug”, while the second two are going to have to settle for being “quirks”. I haven’t read the W3C specs to know if a taller block inside a shorter block is supposed to line up with the top edge or the bottom or if line-height is supposed to override the height of it’s container. I just know that “good browsers” tend to do a much, much, much better job of rendering pages and cooperating with web standards than does IE.

This is clearly a case of me giving the benefit of the doubt to those browsers that have played nice in the past while making IE start with a strike (or twelve) against it from the get-go. It isn’t like it hasn’t earned it. Ugh, I say… ugh.

Filed under: meta, webdev

6 Responses to “Keeping Promises II: IE Quirks”

1. 1Matt N sayeth:

   15th April, 2005 at 1:05am

   Matt N. is cool.

2. 2John Pennypacker sayeth:

   15th April, 2005 at 7:51am

   A tip on that line-height issue: Set the containing element to overflow: hidden; I have had similar problems when using line-height to position type vertically within an element. e.g.
   
h1 {
background: #fff url('somebigpic.jpg') 0 0 no-repeat;
height: 200px; width: 600px;
line-height: 300px;
}
...
[h1]My Header[/h1]


   IE would hold up the content beneath the h1 until its line-height was satisfied (an extra 100px), and that was no good. So I hid the overflow on the h1, and it renders just dandy.

3. 3Shawn sayeth:

   15th April, 2005 at 8:50am

   Come to think of it, I had to do that too on the work site…
   Bad IE! :: spank ::

4. 4joel sayeth:

   15th April, 2005 at 9:48am

   John, I’ll have to keep that in mind for future use. In this instance, I was fortunate enough that the line-height wasn’t a big deal. I just changed it to 20px and all was well. I’m still kind of confused as to why line-height forces a smaller container to change its size. I guess it seems to me that height should wield more power. Then again, it IS IE, after all.

   Shawn, this is a no spanking web site. 😉

5. 5max sayeth:

   17th April, 2005 at 9:43pm

   Screw IE users (not literally, they get lots of viruses).

6. 6max sayeth:

   17th April, 2005 at 9:44pm

   Gaah, it stripped out the tag!

   <input type crash>