CSS Hack and Slash
Not all browsers are savvy when it comes to the complexities of CSS. Many have improved over the last few years, while some still lag behind. This spotty adoption of the CSS standards makes it difficult for designers and programmers to create a consistent user experience across all browsers. In order to make things work as best as possible, the web authoring community resorted to various hacks (or patches, if you prefer). The problem with these hacks may not be obvious at first glance. As browsers improve, the hacks can break over time.
A bit of history. Long ago, Tantek Çelik saw that there was a problem with how Internet Explorer in Windows rendered the Box Model. The problem was sized block level elements with margins and/or padding took up a different amount of space on the page, adversely affecting the presentation of these elements. Through trial and error, he found a “magical” character sequence in CSS that caused IE to choke, and stop reading a CSS declaration. He used this to feed one value to IE, and feed the “correct” values to all other browsers. And thus, the Box Model Hack (or BMH) was born.
Over time, other people discovered that they could use similar methods to feed various browsers one rule, and other browsers another. This was great, as these hacks prevented the less-savvy browsers from attempting something they couldn’t properly render. People visiting the site wouldn’t get an identical experience, but at least these hacks would prevent the visitor from getting a bad experience.
What happens over time, when a browser that used to be unable to render something properly suddenly becomes a model citizen? Your hack sequence may still work, so you will feed the newly-fixed browser the wrong information, resulting in a bad user experience. This means you have to go back and rip apart your CSS code and take out the hacks. Best practices say we should separate CSS files for our hacked declarations. Doing this allows the programmer to easily find and change the code during such a problem.
Let’s take this one step further, and think about the nature of hacks themselves. Most of them include the use of a magical escape sequence to confuse a browser into cooperating. What if we didn’t use a magical escape sequence, but instead used a proper CSS selector that the problem browser just doesn’t understand (and therefore won’t render)? The idea behind this is the hope that both problems will be fixed in a new version of the browser, and the hacked CSS won’t break the new version.
In my hunt, I discovered that IE doesn’t understand Child Selectors. This made my life easier, as I didn’t need to remember a fragile magic sequence. I would make a simple declaration in CSS for IE, and afterward use child selector notation to feed the correct values to the smarter browsers. The downside is this method requires a bit of extra code, but we’re talking about a few characters. Considering most web servers send the browser compressed data, and the CSS file is cached on the client side, the extra bytes are negligible.
CSS has a method of calling an arbitrary element that is a child of another element. The syntax looks like: html>body>p {font-size: 1.6em} Which technically says “Find all <p> elements that are inside the <body> element which in turn, is inside the html element.” Of course, the easier way to think about this is “every <p> element in the document” (you can only have one <html> and one <body> element per document, and all valid <p> elements are inside the <body>). This notation could just have easily been written as: html>p {font-size: 1.6em} or body>p {font-size: 1.6em}
Because not all browsers render CSS properly, I encourage you to follow the best practices of separating your CSS patches from your main CSS file, and using proper selector sequences in lieu of magic sequences where possible. Doing so will give your code extra flexibility when your target browsers get updated.
Update:
It seems Tantek has chimed in on exactly this subject here.