By: John Gallant , Holly Bergevin ,
Page 1 of 1
CSS bugs can be obscenely difficult to isolate, especially when they are located amidst a large, complex page with many external style sheets. Compounding this is the fact that few coders have enough experience to be sure that what they're seeing really IS a bug, and not just incorrect coding.
Often people will, when facing the "Mystery Bug," just thrash about almost blindly, and only by pure luck will the answer be found. This need not be.
By following the procedure outlined here, a clear understanding of the problem may be quickly obtained, freeing the coder to find a workaround or avoid the bug altogether.
Step One: Validation
Too often this step is not performed, which is a shame because the majority of Mystery Bugs are simply due to typos and basic code errors. Luckily, online validation tools (x/html, CSS) are available. These web validation sites will expose outright validation errors, and will also give validation warnings about code that might possibly cause viewing problems due to conflicts with user stylesheets and the like. But beware: they have been known on occasion to throw errors for seemingly valid code. This is quite rare, though.
Step Two: Simplify the Cascade
If all the CSS for the page is contained within the source document, or if it is all within a single external .css file, go on to the next step. Otherwise, it's best to embed the relevant CSS into a single document (into the head of the document being worked on).
Note: Make sure you have safe copies of all documents before you start, not after it's too late.
After cutting an external linked (or @imported) stylesheet, save, and view the page. If a linked stylesheet is removed and the bug disappears, paste that .css file in the link location (in the head of the document). If the link is cut and the bug stays, move on to the next linked stylesheet. In the case of a <link>, the newly embedded CSS must be enclosed with <style></style> tags. Important: In the case of multiple linked or @imported stylesheets, each external .css file must be placed in the same location (in the same order in the head of the document) as the link that called for it.
When there are no more external sheets, and the bug is still present, it's time for the real work to begin.
Step Three: Cut and Paste
The object here is to cut large sections of code, save the file, and check to see if the bug is gone or not. If the bug is gone, paste that section back in, and cut the next section. Obviously, if the bug is still there, do not paste back that section, but move on to the next. This method is applied to both the CSS and the x/HTML. Which one gets done first is up to you.
An alternative method is to surround code sections with comment tags. This makes it easier to recover if you somehow "lose" the bug, but the source stays cluttered, and it is all too easy to accidentally nest comment tags (not good). It's also not as fast as the first method.
Be aware of any CSS that is "inline" within the x/HTML, and treat these styles the same as the embedded CSS. If you cut an inline style rule, and the bug is affected, paste it into the head within the appropriate rule, and after the other properties in that rule. This should prevent any alteration of the cascade. Don't forget to save and view the page, just to be sure.
Remember, the goal here is to keep the bug present, while removing as much of the code as possible. As you go along, the portions that can be removed will get smaller and smaller. Switch back and forth between the HTML and CSS, and don't stop until there is not one single bit of code that can be removed without losing the bug.
Step Four: Analysis
At this point the bug page is called a "minimal test case." You may by now have worked out the problem and figured out how to get rid of it, but if not, step back and take a good long look at the code, and the page. Here's where code knowledge, analytical skills, and keen observation pay off. You could "play" with the code, or go to a good knowledge base like the W3C, or CMX, or a bit of each. However you go about solving the problem, by the time it is solved, you will have learned, guaranteed.
As a last resort, there are always help forums like here at CMX, or email lists, or newsgroups that have people willing to help solve the problems you encounter. And those people will appreciate that you took the time to make that "minimal test case" as described above, because they won't have to wade through many external stylesheets and extra code that just confuse the issue.
Any bug that can survive this treatment and keep laughing, will draw CSS experts like sharks to the chum. Not having to paw thru a huge set of documents is really nice; take our word for it. Now go nuts! Er, get cracking! Well, you know what we mean.
Page 1 of 1 1