Are CSS Hacks Necessary? Hint: I Don’t Have the Answer

As web designers, we are stuck with the fact that not every browser resolves style sheets the same way. Regardless we are expected to come up with code that appears and functions the same whether visitors are using IE, Firefox, Netscape, Opera, Safari, or the next hot browser we don’t even know about yet.

The discrepancies between Internet Explorer and the rest of the pack seem to generate the most wailing and gnashing of teeth. The good news is that the imminent release of IE7 addresses many of the problems of its predecessors. It still isn’t strictly compliant with the CSS standard (but that can be said of other major browsers, as well).

Chasing the holy grail of consistent cross browser layout, many designers employ CSS hacks. This (relatively) simple practice consists of including code in your CSS that will be read by some browsers and ignored by others. Usually this amounts to writing code only visible to IE that “corrects” how IE is rendering the page.

Normally a layout that makes extensive use of sizing and positioning rules is going to trigger some of the quirkier behavior of the different browsers, but these CSS hacks allow you to bring creative, complex designs to every visitor regardless of the software they use. Using hacks is not without some element of risk, though. Most hacks are based on exploiting a bug in how the browser interprets code. What happens when the bug is fixed? John and Holly are faced with this possibility with the release of IE7.

Note: There is a similar approach (at least with IE) that allows you to write code that will only be seen be specific browsers that does not rely on exploiting bugs. Peter-Paul Koch writes about conditional comments.

You could avoid this problem by restricting yourself to vanilla layouts that don’t make use of the more advanced features of CSS, but that would likely result in you becoming extremely bored with your work as well as getting trounced by your competition. Are you stuck with using hacks that may or may not require you to do massive rewrites years from now?

Sometimes the answer to that might be yes, but adding “wrapper tags” can solve many of the challenges you’ll encounter without resorting to hacks. I am in fact talking about blaspheming your beautiful semantic HTML with additional tags that have no purpose other than to affect the presentation of the page. So your code that used to look like this:

<div id=”maincontent”>

</div>

Now looks like this:

<div id=”wrapper1”>
<div id=”maincontent”>

</div>
</div>

That’s a simple example, but it can get very ugly quickly with a complex layout. I don’t want to go into the technical aspects of how you address certain CSS positioning problems with nested div tags (and I’m not suggesting that it can address all of them) because I want to talk about the philosophy behind the practice. Why are people for or against these “extra” div tags?

Truthfully, they really do muddy up your HTML. The whole purpose of CSS is to separate semantic and presentational markup. The HTML code should only be describing the structure of the content. In addition to blurring that line, more div tags means inflating the file size of the HTML document and eating up more bandwidth.

Then there’s the question of who you are writing this code for. The primary audience is the people who will be visiting this site in a web browser. I don’t think they really care which path we take. The customer who is buying our design from us cares. I’m guessing most of them would prefer robust code that isn’t going to break in new browsers a few years from now.

I guess I really don’t know what the right answer is for this. I’ve heard people argue in favor of both sides. Both arguments are compelling as far as I’m concerned. I’ve taken both approaches at different times. The factors I take into consideration are how I think the customer would react to mandatory rewrites in the future, how long until the site is likely to be redesigned anyway, and how much non-semantic HTML would be required to avoid using any CSS hacks.

Leave a Reply

Best Practices

presented by Site Potion