As web masters, we all know that on occasion our “live” web pages get reported for a wide range of issues: failed log in attempt errors, buggy actions due to failed scripts, images that do not render properly, overlapping text, or content styling spilling over into other background divisions or sections. These are just a few of the things that can go wrong when visitors experience a buggy web page.

This list of several tips and tools can become prime candidates for incorporation into your debugging and testing routines for you and your team. Included in this short list are techniques for debugging code, several tools to look through offending code, services to test your designs, and cross-browser support, including earlier versions of IE.

Directory assistance?

As simple as it seems, sometimes all it takes is a little organizing to keep your file and directory structure in a logical order. For most this means starting with the web root directory named htdocs, inetpub, webroot, public_html, or any other logical platform naming convention assigned during the initial web server setup. From there, the typical organizing sub-directories include /styles, which contains all CSS files, /scripts, which includes JavaScript, JQuery and the like, /images, which, of course, contains all image and graphic file types. Organizing your files in this manner helps when you are debugging and testing files.

Sectional troubleshooting

On occasion, the offending code can be highlighted and commented out as a single section or several sections, and then the page tested again. Using troubleshooting techniques such as dividing and bi-sectioning the web pages, using a formatted, systematic checklist based on your systems and design, or isolating the specific cause or causes of the symptomatic code can result in a quick solution to the aberrant problem. One of the core principles of troubleshooting web pages is being able to reproduce the problem, and seeing if the issue occurs in all server environments, be they development, staging, or production (live). Singling out the issue may mean making a change on the server also.



Several tools are available, and many of them for a price, however, some are also provided free of charge. One such example is Firebug, which is used for debugging web pages and code; it is available for free and is open source. Firebug is a Firefox extension which integrates with the browser to put a wealth of development tools at your fingertips. With Firebug you can edit, debug, and monitor CSS, HTML, and JavaScript in any live web page. One feature in particular that I enjoy is the ability to inspect and tweak CSS on the fly. It is available for several versions of Firefox and also provides add-ons for AJAX debugging called FirePHP, available within the Firebug Swarm, a collection of extensions also including Eventbug, Firediff, and Selectbug. Figure B shows a screen capture of a portion of the TechRepublic home page as displayed with Firebug, demonstrating panel views of the live HTML and Style tab.

Figure B

Cross-browser support

Does the offending code only present an issue in one or just a few browsers or versions? You can test your web pages for cross-browser support at BrowserShots, selecting from comparison options between Linux, Windows, BSD, and Gecko, KHTML/WebKit, all, or none. While it might not always have perfect results, you do get a queued view of screenshots showing how your site might render across a range of browsers. This online tool could give you a clue as to pinpointing any problem code.

Figure C

Testing, testing, IE5.5, IE 6

As web developers we all know about the issues with IE, especially earlier versions. And as much as we would like to sweep this one under the carpet, it cannot be ignored that many visitors still do use earlier versions of IE including going way back to IE5.5. If your web statistics show more than 1% of your traffic coming from IE6 or earlier versions, then it makes sense to test in IE. Good thing you don’t have to keep all the versions of that aged product on your test beds, because you can use the IETester, in a virtual environment. IETester is a part of the DebugBar, and embeds multiple versions of the Internet Explorer rendering engine (called Trident) into a single process. Trident is an ActiveX control, thus a COM object, and can be embedded into any application.

Figure D