A HTML 5 CSS 3 Tutorial: Debugging a Web Page

From personal experience while adding to a Web page iteratively the first thing to check is whether the code you think is behaving improperly is the code you think you have submitted to the browser.Most editors will tell you whether your code has been saved.

Notepad++ indicates an unsaved file with an asterisk in from of the file name.The snapshot below shows tht this can happen. The asterisk preceding the file name should be one of the first things to look for.

It is generally a good practice to have backup copies of what you are working on. This however can be another source of a problem. Are you in the right directory and are you editing the right file.

In the snapshot which follows, the problem of something not displaying is as simple as a missing style tag. Other things which could be could cause this could be an incomplete tag, a missing slash "/" or less tan or greater than sign.

Many text editor will help you with color or the ability to collapse sections of code.

The snapshot which follow illustrate a blank screen being displayed when the closing style tag was missing.

It's even more baffling when there are multiple errors in a file as in the second example. This might go undiscovered until some future time when a code change occurs.

Adding background colors can be quite helful in figuring out a page layout and avoiding problems. Page elements have default values for size, margins, borders which do not always result in easy calculations. Distinct colors for different page elemnts while prototyping the page can save a lot of time and avoid problems.

For example when viewing a page in Google Chrome in order to investigate a problem all you really need to do is right click your mouse and choose the "Inspect element". There are a number of performance options you can access but during the early coding stages you might just need to look at any error message reported. The snapshot which follows illustrates the very simple problem of a misspelled image name.

Other thing which it can help with are indicating default browser values and where you might need to specify an override.

Another example of a good tool is Firebug which integrates well with Firefox.

Sometimes the brute force approaches mentioned above and careful investigation doesn't seem to work. In that case you might want to utilize the W3C Validator. It's free, relatively easy to access and use. You page need not be on an active website. There is an option to upload your file or enter a snippet of HTML or CSS code. The following illustrates how it may be used and what kind of output you might expect.

In this case by looking at the error messages the problems with the code were resolved. This is not always the case. Just yesterday, it looked like all of the problems I had with some code had gone through the validation process without any errors, yet my default browser was not displaying the page the way I expected it to.

So what next? What recourse do you have? Try it on another browser. Guess what? It worked! Not only on one browser but three of the four browsers I normally use. (The ones I use are firefox, Opera, Chrome, Internet Explorer.)

The moral of the story is you should not rely on one browser to verify your code nor should you rely on one device to display it. Something might look good on a deskpot machine but give a table, netbook, or mobile devices user a miserable experience.