|
HTML Tip:
5 Rules for Debugging Your Web Page
by Larisa Thomason,
Senior Web Analyst,
NetMechanic, Inc.
We get lots of letters from readers who need help debugging their Web pages. When you've helped enough people, you start to see the same problems over and over again. So...
Try these five simple rules for debugging problems with your pages.
1. Be sure to edit the right page.
Check to see if the page you're looking at in the browser is the same page you're editing in Notepad or your HTML editor. It's easy to get confused when you're working with multiple copies of the same file.
For instance, most webmasters with slow Internet connections often prefer to make changes offline and keep a duplicate copy of their Web site on their own PC. It's quicker to update the page offline. So they work on the local copy, save it, and then test the changes online.
But they sometimes leave out one critical step: sending the changed document to the server. The online copy hasn't changed a bit because the webmaster forgot to upload the changed file! The file open in the browser is not the same file that has changed.
Note: you should always have a backup copy of your site no matter what kind of connection you have!
2. Beware of the browser cache
If you're sure that you are editing the correct page, but your changes still don't show up in your browser, then you may have a caching problem.
The solution is often as simple as closing your browser and reopening it because the browser cache isn't functioning properly. Normally, the cache is your friend: it decreases page download time by saving downloaded files and loading the local copies when the browser requests them again. That means fewer requests to the server.
Theoretically, a "hard refresh" (press the shift key as you reload the page) in Explorer and Netscape tells the browser to request the page from the source (either the server or your local copy) instead of loading the cached copy.
That's the theory, but in reality you sometimes just have to close the browser window entirely and reopen it to see the changed file.
3. Write clean HTML code
Before you get your hands dirty trying to debug problems, run HTML Toolbox over your page to make sure you don't have any coding errors. Clean HTML code isn't guaranteed to solve your problem, but it's a critical step.
If your page is free of HTML coding errors, then the problem may be in your Cascading Style Sheets (CSS) or JavaScript code. Review them both for errors and browser display problems. These resources at the NetMechanic site will help you get started:
And remember, sometimes your code, CSS, and JavaScript are all correct - but the basic problem is browser support! Use Browser Photo to determine how your page looks in different browser versions and operating systems. If you find a display problem in a single browser, check to see if the browser actually supports the design technique you used.
For instance, Opera doesn't allow you to use CSS to create dynamic form fields and WebTV has very limited JavaScript support. If you don't realize that browsers display pages differently at times, you may waste a lot of time trying to debug your pages when really there's nothing you can do except use a different technique.
It's comforting to know that you didn't cause the problem - but frustrating to realize that you can't fix it either!
4. Take it one step at a time.
The subscription version of HTML Toolbox will identify and repair coding errors, then give you a corrected copy of the page that you can test and upload to your own server. But if you're using the trial version, Toolbox just finds the errors for you. You have to fix them yourself.
One problem with fixing errors by hand is that you often introduce new errors while trying to figure out the original problem.
To avoid this trap always make one change at a time! It's maddening to spend hours making extensive corrections to a page, only to have it look worse than when you started. Follow these steps:
- Take the first error flagged by Toolbox and fix it.
- Save the file.
- Test your page (remember Step One in this article!).
Sometimes, fixing one error takes care of multiple problems. That's because a single error like not closing a tag properly can cascade through the rest of the code. The tool may read the rest of the code improperly and assume the whole thing is messed up - when in fact the only problem is that you just forgot to close a quotation mark or bracket on one tag.
Make changes one at a time and it's much easier to evaluate the results and fix problems.
5. Pay attention to server-side issues.
You may be using server-side technologies that only work when the page is on a live server. Here's a short list:
- Server-side Includes: These don't appear on your local machine since they're a server-side technology. You have to upload your pages to test them.
- Database Functions: If you're running a dynamic Web site and creating pages on the fly from database queries, then you may need to upload the pages to the server before testing them. That depends on how your have your local system set up, but if your Web host is supplying the database or shopping cart software, chances are you need to design online!
- FrontPage Forms: FrontPage makes it easy to process forms without bothering with CGI script installation, database setup, etc. However, you must have FrontPage extensions installed on the server before the forms will process and display correctly.
FrontPage usually warns you when the page "…contains elements that need to be published before they display correctly." That's your cue to upload the page before you even start trying to debug it.
These questions and answers may sound silly or way too basic as you read the article, but there's a good chance that every webmaster has asked some of them at least once! Save yourself time and frustration: if HTML Toolbox and/or Browser Photo can't solve your problem - maybe the answer is right here.
|
