So, you’ve written a brand new page and fired it up in your browser only to find that it doesn’t look anything like you expected. Or it doesn’t display at all. Or maybe it looks great in your default browser, but when you or your clients check it in others, it looks, well, kind of funny. Between HTML, CSS, and the multitude of browsers (especially older ones) and platforms, it’s easy to have trouble here and there. This chapter will alert you to some common errors and will also help you weed out your own homegrown variety. Some of these debugging techniques will seem pretty basic, but problems with Web pages are often pretty basic too. Before you go looking for a big problem, make sure you don’t have any little ones. I’ll show you how in the first section. Once your code is correct, you should thoroughly test your site on a few browsers, in one or more platforms, to see if each page works the way you want it to (see the section “Testing Your Page” and the sidebar “Which Browsers Should You Test?”).

Trying Some Debugging Techniques Here are some tried and true techniques for getting the kinks out of a Web page.

• Check the easy stuff first
• Be observant and methodical.
• Work incrementally. Make small

changes, and test after each change. That way, you’ll be able to pinpoint the source of a problem if one occurs.

• When you’re debugging, start with what you know works. Only then should you add the hard parts chunk by chunk— testing the page in a browser after each addition—until you find the source of the problem.

• Use the process of elimination to figure out which chunks of your code are giv￾ing you trouble. For example, you can comment out half of the code to see if the problem is in the other half A. Then comment out a smaller portion of the offending half, and so on, until you find the problem. (See “Adding Comments” in Chapter 3 and “Adding Comments to Style Rules” in Chapter 7.)

• Be careful about typos. Many perplex￾ing problems can end up being simple typing mistakes—for instance, you spelled a class name one way in your HTML but a different way in your CSS.

• In CSS, if you’re not sure whether the problem is with the property or with the selector, try adding a very simple decla￾ration to your selector, like color: red; or border: 1px solid red; (or choose

A I’ve commented out the middle section of this code to see if it’s the culprit. Note that many HTML and CSS editors include syntax highlighting, which is automatic color-coding of elements, selectors, and the like. This can aid your debugging. Mistype the name of a CSS property, for example, and the editor won’t show it in the expected color: a hint that it isn’t valid.

        ...
        .entry {
         border-right: 2px dashed #b74e07;
         margin: 0 .5em 2em 0;
         }
        .entry h2 {
         font-size: 1.25em;
         line-height: 1;
         }
        /*
        .continued,
        .entry .date {
        text-align: right;
        }
       .entry .date {
       line-height: 1;
       margin: 0 1em 0 0;
       padding: 0;
      position: relative;
      top: -1em;
      }
     .intro {
     margin: -5px 0 0 110px;
     }
    */
   .photo {
   float: left;
   height: 75px;
   width: 100px;
    }
  .photo a {
  margin: 0;
  padding: 0;
  }**
  ...

an uncommon site color like pink if red is part of your design). If the element turns red, the problem is with your prop￾erty; if it doesn’t, the problem is with your selector (assuming you don’t have another selector that’s more specific or that comes after the current one).

• Take a break. Sometimes you can get much more done in the fifteen minutes after an hour-long walk than you would have if you’d worked during that hour. I’ve also solved problems in my head while taking brief naps.

• Test changes to your HTML or CSS directly in the browser by using one or more of the developer toolbars at your disposal. Or inspect the code with these tools to try to locate the problem. (See the “Browser Developer Tools” sidebar.