Skip to main content

Kimberly Blessing

CSS & Troubleshooting IE6

3 min read

This past Saturday I gave my CSS Summit presentation on CSS & Troubleshooting IE6. Feel free to download the presentation slides to check out what I covered!

In the chat room, a number of questions and comments came up regarding the use of CSS hacks to address IE. I don't know how many people were in the camp of "all hacks are bad, all CSS must validate!" versus "who cares, use all the hacks you want", but I was put on the spot and asked for my two cents. I said something to the effect of, "Aiming to write CSS which validates is a great goal and perfectly achievable on your personal site, but when putting together a site for work or for a client, especially a large site, you may find that using hacks is easier to write and read, and will scale better over time -- so long as you plan a way out." I think that resonated with some of the folks in attendance, who have always felt that to honor the Web Standards cause, a developer always had to follow the best practices and have valid code at all times.

So, just to reiterate, no, you don't have to have valid markup and style sheets all of the time. In fact, there are times where you'll intentionally code something not valid -- whether it's the use of the target attribute for an anchor to make sure a link opens in a new tab/window, or whether it's the application of a hack in your CSS, so a future developer doesn't have to look through multiple CSS files to figure out what you did. I think this is perfectly acceptable, provided you execute the hack consciously. At almost all of the large companies where I've worked*, we've had to use hacks or deliver non-valid code. It's just a fact of life. It's what you know about your non-validating code, what you plan for**, that matters.

*At PayPal, we attempted to maintain separate IE6 and IE7 style sheets, called with conditional comments; this caused developers to have to write additional CSS in many cases, as the CSS architecture included a global CSS file, one or more product/flow/page-specific CSS files, and then these IE-specific CSS files. Due to the cascade, overwriting one style in the IE-specific CSS file sometimes meant writing additional lines of CSS to restore a style -- unless you could ensure that tweaking selectors in the other CSS files to make them more specific would be a better fix, without breaking any other pages... perhaps you see where I'm going with this? With over 100 developers potentially working on a bit of code, decoupling IE-specific styles created a nightmare situation, which inline hacks would have solved in a way that would have been easier to read and easier to maintain.

**On the other hand, at CIM, we have no coding standards (yet), so each developer appears to be addressing browser-specific issues in whatever way they want. I've seen multiple hacks used in our code and backing them out later is going to be a major challenge. When you do use hacks, make sure everyone on the project/working on the site uses the same ones!

So, with that, you have my permission to use hacks and write non-validating code -- just make sure you have a good reason for doing so, in case someone comes asking why you did it. 'Cause I won't back you up if you don't have solid justification!