HTML and CSS Reference
To Hack or Not to Hack
The key to using hacks successfully is knowing when, how, and why to apply them, and where
(as Chapter 5 suggests, it can be good for your organization in larger projects to keep different
aspects of your CSS separated into separate files, and then import them into your base style
sheet—a separate file to keep your hacks grouped together is a great idea). If you follow the
standards-first approach outlined in this chapter, you'll find that the need for hacks for any
modern browser diminishes dramatically.
So When Should You Use a Hack?
Sure, we'd all love to enforce a “Zero Hack Policy,” but the reality is there are plenty of situa-
tions when using a hack is your only option. In fact, as you'll see later in this chapter, almost
any CSS layout will require at least one or two hacks to ensure proper display in IE/Win ver-
sions 5 and 6. So while hacks tend to leave a slight smell hanging around your code, for the
time being you'll need to use at least a few on a regular basis (unless you're one of those few
lucky folks who only develop for an intranet with non-IE browsers).
Typically, the process might go something like this:
Develop and test using Firefox. Everything looks fine and dandy.
Test in Safari and Opera. Still dandy.
Test in IE/Win; commit hara-kiri after seeing the result.
No Need to Get Dramatic
OK, so self-disembowelment-by-sword may be an exaggeration in this case, but seeing your
nice layout being messed with can definitely make you feel a bit ill to say the least. This is
where hacks can bring some sunshine into your life.
WITHER IE 7?
As of this writing, IE 7 beta 3 has been released, and by the time you read this, the final version may well be
winging its way onto Windows users' hard drives via Windows Update. This is a Good Thing,because IE 7
brings us a big step closer to a more standard browsing environment between browsers, but it also under-
scores the need for minimizing the number of hacks you use, being as specific as possible when applying
those hacks, and keeping browser-specific workarounds separate from your default style sheet.
The reason is that hacks that developers have been using for years to target and correct bugs in IE/Win
(specifically versions 5, 5.5, and 6) will not work in IE 7, thus breaking many layouts in the new browser—in
addition, most of the bugs targeted by those hacks have been fixed in IE 7, and the new version also supports
many CSS 2 selectors that have been used in conjunction with the hacks to send correct styles to non-IE
browsers, meaning that IE 7 can now “see” rules that were not intended for its rendering engine. You can
almost hear the web development community letting out sighs of relief and screams of agony simultaneously;
luckily, IE conditional comments (covered later in this chapter) allow targeting of versions less-than-or-equal-to
IE 6, which should ease the pain significantly if your hacks are kept in separate style sheets (they also have
Microsoft's official stamp of approval for this very purpose).