Hi, my name is Kimberly Blessing. I'm a computer scientist, Web developer, standards evangelist, feminist, and geek. This is where I write about life, the Web, technology, women's issues, and whatever else comes to mind.
CSS & Troubleshooting IE6
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!
Comments (2)
Hey Kimberly … I don’t disagree and, in fact, would like to add that even widely used libraries like YUI use hacks in their CSS files. You can imagine what a nightmare it would be to get your audience to include multiple files for each component just to handle all the hacks in a standards based way! Your library would end up not being so widely used…
There’s also a performance impact. The more connections you make, the slower your page loads. Sure, it’s only for IE but, alas, that’s still the majority of users. At PayPal, there was a core style sheet but only a single set of IE specific style sheets. At a site as large as PP, this could lead to some serious bloat. If all the IE specific code went into these files, every page is going to have to parse all the IE specific rules for the entire site even if you only need one.
Still, one should try…
I almost never validate my CSS. That’s something that’s never been important to me, for some reason. I guess because I don’t find a lot of ways that CSS would become invalid.
I think the other important thing to remember about hacks is to document which hack you’re using, for which browser(s), and why. It could be that the problem goes away when old browsers are depreciated and yet the hack stays in there because nobody can remember what it was for.
Thanks for coming out and saying that it’s okay not to be valid (for the right reasons!). I know some people will actually switch to a transitional doctype when they intentionally do something minor that’s invalid. Or if they can’t be sure that someone won’t make a mistake that invalidates the code. I’ve always thought that it’s better to be strict – even if you can’t verify that it will always be valid. I know my blog sometimes becomes invalid because I forget to encode ampersands in URLs.