Mystery Bug

From CSS Discuss

Jump to: navigation, search

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 below, 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 are available.

These engines 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.

Note: Make sure you have safe copies of all documents before you start, not after it's too late.

After cutting each external link, save, and view the page. If a link is removed and the bug disappears, paste that .css file in the link location. If the link is cut and the bug stays, move on to the next link. In the case of a <link>, the newly embedded CSS must be enclosed with <style></style> tags. Important: Each external .css file must be placed in the same location 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: Isolate the problem

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 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.

A better alternative is to "comment out" portions of the html by ... css. If you want to temporarily remove a block of content and there happens to be a convenient element wrapper for that block, just add style="display: none;" to the start tag of that element. If there is no such surrounding element to use, or if it happens to be a crucial structural element, you can instead add your own DIV that surrounds the content to be removed and use style="display: none;" on that DIV. In effect such a DIV amounts to a "comment" that may harmlessly enclose other real HTML comments without any difficulties.

Be aware of any CSS that is 'inline' within the HTML, and treat these 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 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 gone bye bye, 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 a bit of both. If it is a browser specific problem, don't forget to visit bug specialist sites as PIE. However it's done, by the time it IS done you will have learned, guaranteed.

One excellent testing method is to use backgrounds and/or borders on elements to show exactly where the browser believes they are on the screen. Be careful with borders tho, because modern browsers (and IE6 in "standard" mode) will add the border to the box size. If there is not enough room for the enlarged box to fit, the test border itself can break the layout.

As a last resort, there's always the Css Discuss List. Any bug that can survive this treatment and keep laughing, will draw such as myself like sharks to the chum. And not having to paw thru a huge set of documents is really nice, take my word for it. Now go nuts! I mean, get cracking! Well, you know what I mean.

Personal tools