IE 7: Is Your Site Ready?
You may have heard about it. You may know it’s coming. Perhaps you’ve been playing around with beta versions 1 and 2. Some of your sites may be broken in it, perhaps not, but regardless of your situation, if you’re messing around with the IE Beta 2 version, what you see now is what the masses will see later so it seems.
You may have been told not to work on any issues yet and to not act rashly or to panic as Eric Meyers advised. It was sound advise but that is sort of out the window (no pun) now. It started for me this [yesterday] morning while reading an item in Blair Millen’s The Letter which led me from one site to another. In the end I learned that apparently the IE 7 Beta 2 rendering engine is now complete and there will no more fixes to that end. This was noted in this MeyerWeb update and it will not be improved beyond what we have with the beta 2 build. The focus from Microsoft now will be security features, etc.
So, are your pages “IE 7 Ready”? (Feel free to grab the “IE 7 Ready” badge if they are.) If not, what kinds of problem are you or might you encounter? If like me your stuff is pretty much ready-to-go, then you have no worries. If you’ve used IE conditional comments as advised for years, you may have some work to do, primarily changing the “if” condition in the comment from “if IE” to “if lt IE 7″1 (meaning less than IE 7). If you don’t, some of your IE 6 fixes may not render as expected in IE 7. In some cases, you may need to change your conditional comment from “if lt IE 7″ to “if IE,” it all depends on the bug. I’ve gone over all my stuff and found I had to use the latter more than the former much to my surprise.
1Note: You could also use “if !IE 7″ (meaning it’s not IE 7).
And if you didn’t follow the advice of the gurus, and instead used the Star HTML Hack to specify certain CSS rules for versions of IE-only, then assuming those rules aren’t needed for IE 7 — and most won’t be needed — you’ll have to do nothing. The advice wasn’t bad, and it was smart that Microsoft choose to no longer support this (would’ve caused even more problems), but nobody knew if MS was going to carry it through or not. For those who used the Star HTML Hack, you got lucky — this time (I did, I had it in a couple of places) — but if those hacks are needed for IE 7 as well, then you’re going to have to use the “if IE 7″ conditional comment.
There are some nice features in the new IE version. The fact that you can apply hover to elements besides anchors thrills me big time. And the support for *.png transparencies is awesome. Oddly, though, the Content-Type, application/xhtml+xml, still isn’t supported. I could go on listing features, but I’ll skip that in favor of saying it’s better and supports a lot more. Are we still gonna have to make special fixes and stuff just for IE 7 like the good-old-days of versions 1.0 through 6.2? Yes, of course.
How about new bugs? Will you find new breakages using IE 7? I would guess that the answer is affirmative. I say this from experience. All of my sites are now IE 7 ready, but I did have some work to do. Most of my latest designs are fine I can gladly report, but beginning with this site (Green-Beast.com actually) and going back older, some of my designs did have an issue or two. One issue is called the “IE 7 Hover Bug.” The second issue is what’s being called the “IE 7 Whitespace Bug.” The second one may not be a new bug per se, but since a couple of my sites were affected when viewing with IE 7, and weren’t affected with IE 6, to me it’s new. There are probably more issues that I haven’t even heard of yet, but speaking on my own designs only, I can share what I know and what I have learned.
The IE 7 Hover Bug
On some designs that use CSS for rollovers (hover effects on links or anchors), you’ll discover they won’t work. Not at all. I didn’t/couldn’t identify why it would manifest on certain sites only. It would only show up on sites using hover in a linked CSS using “@import” to make the connection. If the CSS was linked using “link” or if the CSS was internal, I think the point is moot. It was frustrating. I was like gimme a break. It didn’t take long to find a solution, though. The fix is really easy. In the style link (using @import) simply add a:hover {}.
Example I:
<!--[if IE]>
<style type="text/css" media="screen" title="My Style">
@import "styles/ie-styles.css"; a:hover {}
</style>
<![endif]-->
IE 7 Whitespace Bug
As the name implies, this bug affects the space shown between block-displayed listed links. It manifests by displaying large gaps between your vertically-oriented list items. If you’re using IE 7 now, you’ll see the bug in all its glory below, Example links 1a and 1b:
Example II:
Ooops. You’re not using IE 7. Sorry, here, it’ll look just like Example Links 2a and 2b below. This is what the links above would look like if you were using IE 7:
Example III:
Whereas it should look like this in all versions of IE (and all browsers for that matter)2:
Example IV:
2Note: I used margin to recreate the bug’s look in Example Links 2a and 2b).
The difference is that Example Links 1a and 1b have the width of the <ul></ul> or unordered list element defined and the links themselves are confined only by that width so they appear as they do. (As noted above, Example Links 2a and 2b are a visual demonstration for people not using IE 7.)
In the properly displayed links (in IE 7 too), Example Links 3a and 3b, the width is placed on the anchor or link element itself, <a></a>. If you are dealing with the Whitespace Bug when your site is viewed with IE 7, you need to define a blocked-anchor width. Simple… right?
Okay, maybe it’s not simple for you. Or maybe you feel obligated to fix the 1000s of sites you’ve created in the past, or maybe it’s lazy. Tell you what, I have a very simple Plan B better suited to your needs, and it doesn’t take away or change the semantics, appearance (other than fixing the IE 7 problem), or content-value of the site. A “Get out of jail for free” card, if you will. This time, anyway. Here’s what you have to do.
Normally, you have your link list markup written like this (right?):
Example V:
<ul> <li><a href="index.php">Home Page</a></li> <li><a href="about.php">About Us</a></li> <li><a href="contact.php">Contact Us</a></li> </ul>
To fix this bug, all you have to do is remove the whitespace.. do’h. That’s easy, huh?
Example VI:
<ul><li><a href="index.php">Home Page</a></li><li><a href="about.php">About Us</a></li><li><a href="contact.php">Contact Us</a></li></ul>
Tah-dah! 
On this site — which was affected by the whitespace bug on IE 7 — I fixed the width and solved the problem. In fact, if you have the Beast-Blog theme, you may be affected by this bug (see next). Sorry about that… who knew? Besides Bill?
Beast-Blog Theme Concerns
I haven’t yet updated the theme zip, but the simple fix is so, um, simple, I wasn’t too worried, so long as you chance upon reading this. If you’re affected by this bug because you’re using the Beast-Blog theme set, please refer to the article above and choose one of the options. If you are going to employ the easy fix, you’ll want to open the “optional_nav.php” file that comes with the theme. It’s located in the beastblog folder. Its contents, as is by default, will look like this:
Example VII:
<!-- Optional Navigation Menu - Fill in link info -->
<!-- To show "Page on" use <li class="on"> -->
<ul class="btn">
<li><a href="/">Main Index</a></li>
<li><a href="<?php echo get_settings('siteurl'); ?>">Blog Home</a></li>
<li><a href="#">Whatever Page</a></li>
</ul>
You’ll want to change that file so it looks like this:
Example VIII:
<!-- Optional Navigation Menu - Fill in link info -->
<!-- To show "Page on" use <li class="on"> -->
<ul class="btn"><li><a href="/">Main Index</a></li><li><a href="<?php echo get_settings('siteurl'); ?>">Blog Home</a></li><li><a href="#">Whatever Page</a></li></ul>
That’s it. This is obviously not a complete list of the possible bugs, but it is the ones I am familiar with. Any questions, just post them here or Contact me.
