Getting your site sorted for IE 7

Just how bad will it be?

After five years of tweaking the hacks that make your site look the way it's supposed to in IE 6, the CSS changes in Internet Explorer 7 are probably going to cause you some more pain.

Fixing bugs doesn't usually cause complaints, but the CSS bug fixes in IE 7 change behaviours web coders have come to rely on. Workarounds like the *HTML and underscore hack force IE to only parse the section of CSS you want it to; but they work because of bugs that are fixed in IE 7. In the best case, that won't matter. You put in the hack because the correct CSS that you've written for other browsers doesn't work in IE 6; the hack will still work for IE 6 visitors but IE 7 will parse the CSS intended for browsers like Firefox correctly and your site will still look good. Height, width and position bugs are fixed; you can scroll smoothly with JavaScript; and use CSS for transparency and hover effects without needing scripts.

There's a full list of changes in the IE 7 Readiness Toolkit, which will also check your code and let you know if there are any hacks that IE 7 will break. You can see the public bug database for IE 7 at Internet Explorer Feedback (apply here; irritatingly you need a Passport account to use it). You can sign up for the Application Compatibility Toolkit V5.0 Beta at the same site, which tests sites and add-ons for both IE 7 and Vista compatibility.

But not every layout bug is going to be fixed in IE 7. Current betas are layout complete, so if your code doesn't look right in the beta it won't improve in the final release. Rather than keeping the hacks you already have, Microsoft suggests rewriting them as conditional comments that lad the different styles needed for different versions of IE from a separate CSS stylesheet. You'll get the behaviour you want by calling it explicitly rather than relying on the browser parsing or failing to parse a line of code. If you're using hard-coded user agent strings that look for IE 6, at least change them to look for IE 6 or above, or IE 7 will end up with whatever fallback you put in to cope with browsers your user agent strings don't find (and if that's a page asking people to upgrade to IE 6, it doesn't look good).

You can also force IE 7 to render as if it was IE 6 by telling it to render your page in quirks mode, which has none of the fixes implemented in strict mode; compatibility mode will still render as if it was in IE 5. But that loses advances like rendering transparent PNGs, lighting up the RSS button if you have a feed on the page and offering your site as a search option if you're using OpenSearch 1.1. Painful as it may be, it's better to clean up your code.

If you're making changes to your site for IE 7, it's a good time to consider how much support you want to keep around for older browsers. IE 5 is in extended support as part of Windows 2000 and that goes on until at least June 2010, but IE 5.5 came out with Windows ME and it's now out of support, so you can expect business users to be moving away from it. By the same reckoning, after five years IE 6 is in extended support with Windows XP; but there are still plenty of users who aren't ready to make the jump to IE 7 (or Firefox). ®

Sponsored: Designing and building an open ITOA architecture