Table of Contents for

The CSS Detective Guide: Tricks for solving tough CSS mysteries

3. Giving the Third Degree

NOW THAT YOU’VE LEARNED HOW TO INVESTIGATE the scene of the crime and you have the tools to crack your cases, it’s time to take the next step and learn techniques to thoroughly interrogate any code and make it ’fess up as to where exactly it went wrong.

Validating Your Hunches

We’d all like to believe that our code is beyond reproach and has no issues, but most of us have also had that lingering suspicion that we’ve missed something. In either case, it’s a good idea to validate.

Validation is a method of interrogating your code to see if it is written correctly. Validation checks the markup and style code that you write against the rules of that particular code version. A validator is a tool, usually online, that finds all of the instances where your code does not match the standards of the specification written for it, and then generates results to show you what needs to be changed.

The biggest advantage of validators is that they catch small errors that are often difficult to spot but that may have larger ramifications for the rest of the document and related documents. Minor problems in HTML may be negligible on their own, but when combined with a style sheet could cause major problems. In short, validation is a great error-finder and quality-assurance tool.

To validate, you need a code validator, either online or stand-alone. You can either point the validator to the location of the document that you want checked (on the web or locally on your computer), then upload the document to the validator; or cut and paste the code and submit it that way. Then, using the document type, or doctype, definition (DTD) that you’ve included in your document, the validator runs the page code against the DTD written by the W3C, and provides a list of results based on the comparison. The results will be a line-by-line itemized list of issues in your document (unless the page is error free).

There are many good code validators for HTML, but the one most often used is the one from the W3C, http://validator.w3.org/. In order for the validator to work properly, your HTML document must have a proper doctype declaration at the beginning of it. (I will cover doctypes in greater detail in the next section of this chapter). A list of additional HTML markup validators can be found in the Resources section.

The W3C also has a validator for CSS: http://jigsaw.w3.org/css-validator/. In contrast to the HTML validator, it doesn’t require a doctype declaration in your CSS. Instead, you have to indicate which version of CSS you’re using. There are also some CSS validators whose results will show which properties specific browsers support. For a list of additional CSS validators, please see the Resources section.

“Huh? What are you saying?”

Interpreting validation results takes some practice. The output is based on the standards of the language definition, and is really geared more for standards geeks than everyday web developers. However, with a little practice, you’ll get the hang of it.

For example, here is a standard output:

End tag for X omitted, but its declaration does not permit this

And here is the translation:

You are missing a closing tag.

The W3C has a great resource to help with interpreting validation results called “Explanation of the Error Messages for the W3C Markup Validator” (http://validator.w3.org/docs/errors.html), which explains many of the more esoteric results that the validator produces.

What validating can and cannot do

Validating is perfect for finding all the little mistakes that can make for rendering problems that cause much pulling of hair and gnashing of teeth. Once you have validated your code and fixed the issues, you can rest assured that your page is free of syntax errors.

However, validating your code is no guarantee that your pages will show up the same across all browsers (would that it were so easy!). To achieve this feat, you will have to test your pages in various browsers and fix them accordingly.

Also, some of the issues that the validator points out may or may not be relevant to your particular case. You may be expressly using a style that you know will not validate, or you may choose to ignore CSS warnings if, for example, styles higher up in the document take care of the issue through the cascade.

Take a look at this warning, for example:

Same colors for color and background-color in two contexts #container
and h1

The warning resulted from this code:

#container {
background-color: #fff;
border-left: 2px solid #936;

border-right: 2px solid #936;
margin:0 auto;
padding: 0;
width: 950px;
}

h1 {
color : #fff;
font-size : 1px;
line-height : 0;
margin : 0;
}

The h1 was styled with the color as part of an image-replacement technique to keep the text on the page, but invisible. In this case, then, the warning is easily ignored.

Finally, there are some mistakes that the validators just won’t pick up. If you are still having problems, you will need to go over the document with a fine-tooth comb.

Errors vs. warnings

When you first start validating, the validator may return a lot of errors in your markup and both errors and warnings in your CSS code. Errors definitely need to be addressed and fixed, for they indicate that your code is incorrect and does not conform to the standards in that instance. Warnings, however, are simply spots in your code that may cause potential problems. Many common warnings are accessibility related, such as the color warning above, and aren’t related to how the page actually renders. With practice, you will learn to determine how serious a warning is and whether the problems it may cause are acceptable or not.

Troubleshooting tips for validation

• Make sure you have the correct doctype defined so that the validator knows which DTD (document type definition) to validate against.

• Start validating early. Don’t wait until you’ve finished creating your markup and styles. You will find simple errors sooner, and avoid what might look like a lot of errors if you validate later in the process.

• Validate frequently. A good rule for HTML is to validate after you add a major section of code. For CSS, validate after you style each major section.

• Set color and background color for ancestor elements high in the document tree so that the styles cascade down to all of the descendants. Then you can rest assured that you can safely ignore any warnings.

• If you do have a lot of errors and warnings, don’t freak out. Often, there is one error early in the document that causes a cascade of other errors. Start addressing the errors from the top of the document down, and then revalidate. You may find that a list of 30 errors is cleared with one or two tweaks to the code.

Bait-and-Switch Tactics: Doctype Sniffing and Switching

Not only does a doctype declaration let the validator know which rules to check your markup against, but the doctype declaration also affects how the browser renders your pages by triggering different browser modes. An unexpected browser mode could be contributing to your problem, so understanding doctypes may help you get to the bottom of your code’s misdemeanors.

Anatomy of a DTD

Being familiar with the parts of a doctype declaration will give you a better idea of what to look for when choosing and troubleshooting your doctype declaration.

Here is the doctype declaration for HTML 4.01:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

• !DOCTYPE tells the browser that this is an element that defines the doctype definition.

• HTML is the root element of the document.

• PUBLIC specifies the availability of this DTD.

• "-//W3C//DTD HTML 4.01//EN" is the formal public identifier (FPI), which indicates the registration, owning organization, which markup language is being used, and which human language it is in.

• http://www.w3.org/TR/html4/strict.dtd is the formal system identifier (FSI)—that is, the location of the definition document.

There are many incomplete doctype declarations floating around on the web, so be sure to check the W3C’s complete list of valid doctypes at http://www.w3.org/QA/2002/04/valid-dtd-list.html.

Browser modes

If validating still hasn’t revealed the felony in your code, there may be extenuating circumstances. Browsers can render pages differently based on the doctype declaration at the head of the HTML document. Doctypes were originally designed to enable standards-savvy developers to choose how they wanted their pages rendered intentionally, while simultaneously allowing pages that were older or created by standards-ignorant applications to render as well.

There are three rendering modes: standards (or strict), quirks (or loose), and almost standards. The process by which a browser reads a document to determine in which mode to render a page is called doctype sniffing or doctype switching.

• Standards (or strict) mode

In compliant browsers, standards mode will render your pages according to rules of the doctype definition that you have established at the head of your document. This means that your pages will show up the way you expect them to: the markup will be rendered according to the rules of the version of (X)HTML you are using, and the CSS will be rendered according to the latest CSS specification.

• Quirks (or loose) mode

Ah, quirks mode. Quirks mode is for the pages that time and developers have both forgotten: for the pages that have lost their way and are without a doctype, for the pages that have only partial doctype definitions or incorrect doctype syntax, and for the pages created by WYSIWYG editors and page generators that neglected to bestow upon their page progeny a proper doctype declaration.

In essence, quirks mode renders pages based on the browser’s best guess, with some browsers rendering pages the same way they did up to circa 2001. This was an era of poorly written invalid markup and before the popular browsers released versions that conformed to the standards written for the web by the W3C for both HTML and CSS. Yes, we are talking browsers rendering like Netscape Navigator 4.0 and Microsoft Internet Explorer 5 (IE5), to name names. The exact particulars of rendering do vary slightly between different browsers.

Needless to say, having your pages rendering like those of the previous millennium would throw a huge wrench in the works of determining what the problems are in your code and making the most effective and necessary changes. Most likely, you will want to avoid having your documents trigger quirks mode.

• Almost-standards mode

Almost-standards mode is exactly the same as standards mode except for the rendering of images in table cells, in which case it operates like quirks mode. This mode was created to let developers have pages with sliced images in tables that can display as desired without a lot of workarounds. However, if you’re not using tables to assemble sliced images and you’re doing table-free CSS-based layouts, you won’t really need this mode for your pages.

Choosing the right doctype

After all of the above, you may be thinking, “OK, I get that I need to have the proper doctype, but how do I choose the right one?” There are great charts on the web that list every doctype and which browser mode each triggers. However, to get you up and running quickly, here are some general guidelines:

• All doctype declarations below HTML 4.0 will trigger quirks mode.

• Documents with incomplete URLs in the FSI or FPI will trigger quirks mode.

• Documents using the HTML 4.0/4.01 strict doctype with the correct syntax will trigger standards mode.

• All XHTML strict documents (regardless of version number) with the correct syntax will trigger standards mode.

• Documents with HTML transitional or frameset doctypes and XHTML transitional doctypes will trigger almost-standards mode.

• The HTML5 doctype will trigger standards mode.

Tip-offs that an undesired browser mode may be behind your problems

Although not exhaustive, here is a list of some of the rendering you may see if your page is being rendered in quirks mode against your will:

• Text inside a table has not inherited styles as you expected it to.

• Widths and heights seem to be off.

• Default font size is small.

• List bullets do not inherit the font size of the list itself.

• Line-height does not show up as expected.

• The <hr> element renders differently than you expected.

Troubleshooting tips with doctypes

While not the most dangerous character on the block in terms of wreaking havoc, doctypes are significant enough to be on the list of suspicious characters. Here is an overview of what to look for to make sure they don’t make your rendered page look like it’s going down the wrong path.

• Be sure to have a doctype, or your browser will render like it’s 1999. Literally.

Not this:

  <html>
  <head>
  <title>Hunting for Suspects</title>
  </head>

  <body>
  ...
  </body>
  </html>

But more like this:

  <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
  <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
  <head>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  <title>Hunting for Suspects</title>
  </head>

  <body>
  ...
  </body>
  </html>

• Make sure the doctype declaration syntax is correct.

No:

  <!-- DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" -->

Yes:

  <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

• Make sure the declaration is going to a valid DTD.

I don’t think so:

  <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.superstandards.org/mydtd/looseygoosey.dtd">

Definitely:

  <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

• Make sure the declaration has the correct URL—one that is not truncated, incomplete, or relative.

Not gonna work:

  <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">

There we go:

  <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

• Avoid the XML prolog if using the XHTML doctypes: it will trigger quirks mode in some browsers. Use the meta tag instead.

Instead of this:

  <?xml version="1.0"?>
  <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

Do this:

  <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
  <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
  <head>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  <title>Confessions of Crooked Stylesheet</title>
  </head>

Zeroing In on the Problem

You’ve created your pages, chosen a doctype that triggers the browser mode that you want, and validated your code. You’ve even employed a CSS reset, as discussed in the previous chapter. However, your pages still don’t look the way you want them to. It’s time to turn up the heat on your document to expose the real culprits in your code.

Debugging interrogation techniques

To help you get the information you need, here are some time-honored techniques that act like truth serum for getting your code to spill the source of its problems.

Shine some light on it

To better determine where and what the problems may be, highlighting elements is often the first method for targeting areas of code.

Background

You can highlight the background of the element with a color so that you can see the element in contrast to its surroundings, and also see the element’s boundaries.

Add this declaration, and the element should pop right off of the page at you.

background-color: pink;

Adding a contrasting background color does not add to the size of the element’s box and does make the element easier to see. However, if there are nesting issues that you want to bring to light, then you should employ the next technique of adding a border. Also, background colors will not help you see any margin issues.

Border

You can put a border box around an element by adding the declaration to the code of the suspicious element:

border: 1px dashed red;

As effective as this is, you do need to be aware that adding a border to an element will alter its width and height. If you use this technique on an inline element, this may not be an issue. However, if you use this on a block-level element, such as a <div> that is floated and part of a fixed-width pixel-perfect page layout, you may end up breaking the layout of the page by those few additional pixels. And again, this method does not help troubleshoot margin issues.

Outline

You can also use the outline property. This method has an advantage over border because instead of adding to an element’s width and height, as border does, no dimension is added since an outline is visually placed over the edges of the element’s box. This method is most effective in browsers that support the W3C box model, because outline is not supported by browsers that get the box model wrong, namely IE6 and IE7.

So you can use this declaration to delineate the element:

outline: 1px dotted orange;

without affecting the layout of the page.

Get Ugly

You’ve been playing nice guy by using border or background by itself. To take it up a notch and make an element jump out at you, make it really ugly. Change the font to one that you hate (for me, that would be Comic Sans); make the font color a crazy, brash color; and add an equally garish background color, border, or outline.

Here is an effective piece of code that you can add to a selector. It will make you want to put a paper bag over its head, but it makes it much easier to see. I like to think of it as “The Ugly Treatment”:

/* start - the ugly treatment */
border: 1px dashed green;
background-color: yellow;
color: magenta;
font-family: MS Comic Sans;
/* end - the ugly treatment */

Wreak havoc with Space

Another technique is to add either margin or padding values to the questionable element to see if it causes any changes in the element or surrounding elements. Ironically, the most powerful value to establish is 0. Why? Remember the earlier discussion about default browser styles? Explicitly establishing a value of 0 overrides whatever value the browser was rendering by default.

If setting margin or padding value to 0 doesn’t make anything come to light, then try changing the values in very slight increments—for example, from .9em to .89em.

Because either option will cause a change in how the element renders, it may bring the problem to the surface.

Make it !important

You can also use !important to make a declaration override any conflicting styles. If the element renders differently, it can indicate that a style later on in the style sheet is causing a conflict, and that improper order of your styles may be the source of your problem.

Get specific

Another way of isolating problems in your code is to leverage specificity. By making a selector more specific, you can see if the problem is in the cascade, the selector itself, or the style rules you have established for it.

In the style sheet

For example, take this:

.replies {...}

And turn it into this:

#comments .replies {...}

This change makes the selector more specific, and will direct the styles that you think might be the problem to very particular spots in the document. You may find that your selector is not being correctly applied to the desired element.

By limiting the target of the style, you should gain insight into the source of the issue.

Inline

Although inline styles are not good for standard page development, during troubleshooting you can leverage them and the cascade to help isolate your problems by process of elimination.

By taking a style declaration out of the head of the document (or an external style sheet) and making it inline in the markup, you can see if the problem persists or if anything changes. If something does change, it may mean that there is a declaration higher up in the document that is conflicting with the style that you changed to inline, and it’s the other style that is creating the problem.

Once you have determined that the problem is elsewhere, you can remove the inline style and put it back in your external style sheet.

Incapacitate it

You might just need to eliminate parts of your markup and code to better see the root of the problem. Here are several ways to do so.

Comment out sections of the code

Commenting out certain parts of the code is another way to isolate the parts that are buggy. You can comment out either parts of the HTML markup or sections of the CSS code. In both cases it is important to remember that you cannot nest comments, so you need to keep track of where you have the comment tags, or your page will end up looking even more off the mark than when you started. Using a text editor with code coloring will help you find comments in a jiffy.

As a reminder, here are the comments:

• HTML: <!-- comment -->

In action:

  <div id="container">
    <div id="header">
    <h1><a href="lineup.html">The Line-Up</a></h1>
  </div>

    <!-- <ul id="nav">
    <li class="first"><a href="shifty.html">Shifty Sam</a></li>
    <li><a href="unreliable.html">Unreliable Ray</a></li>
    <li><a href="doubletalk.html">Double-talking Dan</a></li>
    <li><a href="alibi.html">Alibi Allen</a></li>
    <li><a href="wiley.html">Wiley Warren</a></li>
    </ul> -->
  </div><!-- end container -->

• CSS: /* comment */

In action:

  body {
  background: #E2DEE5 url(bg_suspects.jpg) no-repeat 0 0;
  color: #993366;
  font: .85em "Trebuchet MS", sans-serif;
  margin: 0;
  }

  #container {
  background-color: #fff;
  border: 1px solid #369;
  margin: 0 auto;
  padding: 0;
  width: 950px;
  }

  #header {
  margin: 0;
  padding: 5px 0 0 0;
  }

  /* temp nav removal
  #nav {
  background-color: #E2DEE5;
  border: 2px solid #cdcecd;
  margin: 0;
  padding: 6px 0;
  width: 100%;
  } */

Comment out sections with the code

A less intrusive method—it’s gentler on the markup and you don’t have to remember whether or not your comments are nested—is to use CSS properties to “comment out” sections of the page by making them invisible while keeping the code intact.

There are two options: visibility: hidden and display: none.

The property visibility: hidden will prevent the element in question from being seen. However, the element will continue to occupy its normal space on the page.

In contrast, display: none will not only hide the element from view, but also take it out of the normal flow of the page, and other elements will take its place.

Adding either of these properties to the selector of the page section that you are trying to eliminate will help you more easily see the area that you feel is problematic. The one you use will be based on whether or not you want the element to take up its normal space on the page.

During debugging, add the style declaration to the style sheet for the section that you want to make disappear temporarily. Or, leverage the start tag of the element that starts the section (such as a <div> or a <ul>) by adding style="display: none;".

If there isn’t a convenient element to comment out the part of the page you want, then it’s fine to create a temporary <div> to contain it expressly for the purpose of making it disappear for a while. Give it an appropriate name like id="testdiv" to remind you that it is temporary and is to be removed once you have finished debugging.

For example, if you used the CSS property option, it would look like this:

#header {
margin-top: 0;
padding: 5px 0 0 0;
visibility; hidden;
}

If, instead, you add the style to the HTML, it would look like this:

<div id="header" style="display: none;>
  <h1><a href="lineup.html">The Line-Up</a></h1>
</div>

Quick Disable

Commenting out sections both manually and by CSS works great, but if you want to dispense with the niceties and get right to the point, there is a quicker way to disable styles in both the CSS code and in the markup.

In the CSS, add an x in front of the suspicious selector to essentially switch off its rendering. (You could also add the word disabled, but that is more typing.) For example, if you had this:

.highlight {...}

You could turn it into this:

x.highlight {...}

Similarly, in the markup, you can disable a style from being applied to an element thus:

<div id="xnav">...</div>

or

<li class="xfirst">...</li>

Troubleshooting tips for disabling and zeroing in

• Check the selector syntax and alter it to target the correct element(s).

• If the selector is not being applied, check to see if the style above it is properly closed, or that the hook you are using in the HTML document is catching the style.

• To be sure that the selector you are working with is targeting the piece of code and area of the page that you are fixing, make it stand out from the rest of the page.

• If you add styles to the selector to make it bright, obvious, or ugly and nothing happens, then the problem is that the selector is not being applied, or you have another selector overriding the one you are working with.

• If you think a selector is being overridden, check styles lower in the style sheet, as they have more cascade precedence than higher ones.

• If the problem is not in the section you thought it was, then search for the problem in the markup and styling of the section immediately before it.

Resorting to Drastic Measures

At this point, you’ve spent some time trying to get the document to fess up, but it remains tight-lipped about sharing the source of the problems. When even the most reliable methods of getting the answers are only moderately effective, then you have to resort to last-ditch efforts and call in the SWAT team of techniques.

Start with the basics

If you haven’t done it already, you should simplify the cascade by putting the styles back in the document. Taking the styles from external to document-level will eliminate a layer of complication and rule out problems with the link syntax, the path to the CSS document, or the @import rule.

Process of elimination

You can lull the document into a false sense of security by initially being gentle. When you are troubleshooting, often less is more. Instead of adding style declarations and potentially making the problem worse and the solution even more elusive, try taking them away. Adding styles often hides the bug under more code and compounds the problem. Instead, execute a process of elimination where you take out pieces of markup and CSS declarations until you have the bug isolated.

In a copy of the original document, remove sections of markup one by one until you have only the section where the bug is. You want to keep going until there is no code left to remove without also losing the problem as well.

Then shift your focus to the CSS and remove all the unnecessary styles. You want to reduce your declarations to the bare minimum needed to keep the bug. Many times it’s the declarations you wouldn’t suspect that are the ones at fault.

Create a minimal test case

When you strip out as much of your CSS code as you can to isolate the section you are dealing with, and to make sure that other elements aren’t affecting it, you are creating a minimal test case. This process is extremely helpful in letting you see clearly all the factors that may be contributing to your bug. Sometimes margins, widths, heights, floats, and other properties can influence each other in unexpected ways. Simplifying the code can reveal any dubious interactions.

One way to pare down the code to the essentials is to follow the steps above by taking out code from the document until you isolate your area.

Another way to make a minimal test case is to put the section in question into a blank (X)HTML document, and make the styles for it inline. This converts your test case into the most compact and immediate version possible. If a section works by itself, then you know that the problem is coming from conflicting styles elsewhere in the document.

If you have multiple problems, start with the one highest in the document and work your way down, following the same minimal test case process. Just as in validating, sometimes fixing problems higher up in the document hierarchy eliminates issues in the lower elements.

Dismantle it completely

Although you are already getting tough by stripping out sections of the markup and code, you may still be holding back from really laying into the document and showing it who’s boss once and for all. But you can take the process of elimination a step further and burn the document down to the ground to smoke out the true problems.

You would use this technique only in the most drastic situations, when you absolutely can’t find the source of the problem through any other means. In essence, you fully disassemble the uncooperative markup and style sheet to get as close to ground zero as possible. During the process of dismantling everything you have done, you should manage to ferret out the nefarious bug.

Save your original document as a backup. In the test document, make sure all of the styles are embedded and not external. Open a new file to place all the code that you cut out of the test file.

Start cutting away sections of code from the test file and save them to the cache file. After every cutting of code, view your test file in the browser to see if the bug is still there. When you get to a point where the bug is no longer there, you know that you have found the guilty section.

If you can’t isolate the bug, continue until you have stripped the document bare, and then move on to rebuilding the document.

Rebuild it from the ground up

The teardown process has left you with a blank document, but still no insight as to the source of the problem. It’s time to reverse the process, then, and build it back up, piece by piece, until you can reproduce your bug.

Upon adding each section back, test the file and see what changes have occurred and if the bug is triggered. By keeping track of everything you do, you will be able to pinpoint the section of the markup—and then, correspondingly, the code—where things started going afoul.

The Shakedown: A Debugging Process

Over the course of this chapter, you’ve hardened yourself to become a ruthless interrogator of CSS code and markup. You now have techniques to make your code waive the right to silence. But let’s put them all together, for a solid debugging process.

Steps to finding the bug

Here is a step-by-step process for finding and isolating the code that is wreaking havoc in your document:

Start at the beginning

1. Make a backup copy of the original files in case the process goes awry.

2. If styles are external to the document, make them document-level.

Due diligence

3. Validate both the HTML and the CSS.

Fix any errors that the validators reveal. Check your page in a compliant browser.

4. Rule out the doctype by deliberately throwing the browser into quirks mode to see if the problem is still there.

Eliminate to isolate

5. Eliminate sections of the HTML:

• Determine the exact location in the code where the problem starts. If the area is not obvious, try the various methods for highlighting elements to make it more visible.

• Remove (through commenting out or actual deletion) the markup for the sections before the problem and anything after. Remove extraneous headers, footers, navigation bars, sidebars, and so on, to create a minimal test case.

• With the target section isolated, remove the piece of code immediately before the problem to see if an element above is the trigger.

• Remove the pieces in smaller and smaller increments until something changes—if it does, you have found your errant piece of markup!

• If nothing changes, then the problem is in the styles, so it is time to move on to isolating them.

6. Eliminate sections of the CSS:

• Take out all of the styles for the areas of the page you have removed, leaving only the general styles for the page and all the styles for the section of the page you have isolated.

• If the problem is still there, then comment out the body styles. If the problem is still there, then you know the problem is probably in the styles for that section.

• Remove the styles in the test-case area one by one. When you have a change with your issue, you have found your errant style!

Rebuild to target

7. Create a copy of your original document. In this copy, remove all of the HTML in the document between the <body></body> tags. Yes, all of it.

8. Take out all your CSS declarations. Yes, all of them.

9. Add back the sections of the page, one by one:

• Add back the main layout <div>s.

• Add back the CSS declarations for the main layout <div>s incrementally, and view the page in the browser after every addition.

• Start with the essential CSS rules like size, positioning, margin, and padding, one at a time. Save visual styles like fonts, colors, and backgrounds for later.

• Add temporary background-color or outline to the layout <div>s to determine if they are where you expect.

• Add back test content in the form of headers and paragraphs. Add their spacing and border rules as well.

• Add back test content in the form of lists, images, and so on. Add their spacing and border rules as well.

• Last but not least, add back font and line-height rules where applicable.

The big fix

The big moment of the grand confession has come: you’ve finally found your bug! To fix it, you get to exercise your brain power and creativity. Here are some ideas to get you thinking:

1. The fix may be a matter of margin or padding, where either establishing an explicit value of 0 or making a very slight change in a value is all you need.
2. You may need to augment the style declaration with an additional property or several.
3. Conversely, you may need to remove properties.
4. You may need to change the property altogether to create the effect that you want.

Totally stumped and don’t know what to do?

1. Double-check the property to make sure it does what you want.
2. Do a web search to see if there is a known bug for what you are experiencing and to find the solutions posted for it.

An Interrogator’s Work Is Never Done

After trying the techniques in this chapter, were you able to make the shady styles squeal? Did they finally offer up the whys and wherefores of their crimes and misdemeanors? With all the ways of getting at the truth behind your coding errors, I suspect the answer is yes.

However, we’ve only dealt with coding errors. There is an additional group of shifty characters that you absolutely need to be familiar with before we can start solving the cases: the browser bugs.

In the next chapter, you will meet some of the usual suspects—many of the common browser bugs that trip up developers—and learn how to outwit them from the start.