CSS is in essence relatively simple: you point to one or more nodes in the DOM with a rule and apply some styles to it. That is the theory. In practice debugging CSS can be hard sometimes. Most of the time it’s because either the code lacks the neccesary structure or you don’t have arcane knowledge of browser bugs.
Even when you’re a structured CSS coder and know all the browser glitches (or think you do), it can happen you find yourself between a rock and a hard place. You know, when you stare at the screen, glancing over all the style properties in Firebug and still don’t have a clue about what’s going on.
DEL is your friend
Those cases happen rarely but when they do, I always resort to a tested and tried technique: isolate the problem by removing or commenting all unneeded markup. Isolating the problem may take some time but when you have a web page with a minimum of HTML while keeping the styling bug intact, you get in most cases the bug fixed in no time.
Why does isolating code work so well? Well, most of the time you can find styling bugs by experience, but when you’re stuck, every bit of styling on a tag becomes suspicious and that’s just too much to test. The bug becomes a needle in a hay stack.
Removing the easy way
The best way to remove blocks in a page is by just adding a display: none to its styling via a developer tool like Firefox’s Firebug, Opera’s Dragonfly, Webkits developer tools or IE’s Web Developer Toolbar. Just cut away big blocks and each time you remove something, you test if the bug still persists. You continue until you find the block that is triggering the bug. Most of the time you’ll have to continue the same technique of removing bits of code within that block until you can isolate the problem.
Hiding a block by adding a 'display: none'
Removing a block of HTML completely
Removing the source code
Sometimes it’s better to have direct access to the source HTML than doing temporary changes in the developer tool. But if the HTML is (partly) created server side it’s hard to easily remove stuff. In those cases when I’m really desperate, I request the HTML source from the browser and save it in the directory the original web page resides. Then I can make dramatic changes to the code and test in multiple browsers without affecting the site itself.
Is this an efficient way of debugging? Definitely not, but sometimes you just need to do it. It happens to me once or twice a year or so and by debugging that way I always managed to find the root of the problem.
