Troubleshooting your HTML/XHTML

Analysing and finding the cause of your problems

[BlobFisk]

By being able to quickly and easily find the source of a problem we waste far less time fixing bugs and pulling our hair out! We that live in the client side world know that we have it slightly harder than our server side friends! That is that the languages (scripting languages for the pedantic) we use have no real IDEs to work on. If you write Java (for example) you have some nice tools at your disposal to develop in, with preemptive editors and decent debug tools.

For HTML and CSS we have the validator. For JavaScript we have the JS consols that come with Mozilla/Opera - although there are others. So, how do you it? For me the W3C Validator is always the first port of call. It can flag you to unclosed tags, incorrect tags and incorrect attributes. However, if you have a complicated page with lots of nesting of p's and divs and spans and you close a div before you close a p by mistake the validator will tell you:

end tag for element "P" which is not open

Not very helpful. This is also true for complicated table nesting. So, how do we try and debug errors here? How do you find the source of your problem? Personally I use the following techniques to try and keep my code clean, easy to debug and easy for someone else to come along and work on without too much difficulty:

• Validate: The validator will catch the vast majority of errors. I listen to it as much as I can. If there are browser render differences that need to be sorted I try to use CSS. Valid code is correct code and by in large cleaner than non-validating code.
  
  
• Comments, comments and more comments: Comments are esential in any language. On any page you need to clearly mark the start and the end point of any important element (like the start and end of a table/div/p). This will allow you to see where things are opened and closed.
  
  
• Code indenting: This helps just as much for me as commenting. It allows me to see things in logical blocks by how far in they are tabbed. It also helps in making sure that things are closed in the correct order.
  
  
• Server Side Includes: This is very much dependent on the structure of your site, but for me I use SSIs for common logical areas on a page. This means that you only need to update one file and the changes propogate sitewide (global search and replace is a powerful and dangerous tool!)
  
  
• Too much nesting means tough debugging: The problem with lots of nesting is that it makes tracking down a problem all the more difficult. You can see an error on the page and have a rough idea of where it may be in the code - but because of the high degree of nesting it makes it difficult to exactly pin point what the problem is. With time these get easier to spot - but CSS is your friend and can help you to cut down on table nesting for layout.

So, any other tricks and tools that you use?

[tedster]

One of my pet topics!

I couldn't agree more about validator. Unless I know there are no errors in my mark-up, I'm stuck making random corrections -- and then cross checking in a pile of different browsers just hoping that things will look the way I want.

And even then, without validation there's no way to be sure that those oh-so important browsers - the spiders - will see what I intended. Before I got the validator habit, I would sometimes see parts of my pages being skipped and then notice a broken tag somewhere in the beighborhood. Many months would pass before I noticed this kind of problem...if I ever did.

INDENTS
I've stopped using them! I use line breaks to group logical sections, but bring related tags onto the same line. It makes my mark-up smaller in file size and gives me more of a chance to see open and close tags on the same screen.

CSS
I forget who introduced me to this particular approach, but declaring multiple classes has been a big help in making my mark-up easy to de-bug. I'm talking about class="sm in c" which declares 3 different classes with one attribute. So now instead of long sets of rules for a div or other element, I create a toolkit of frequently needed rendering effects and add them in as needed.

PLAYING
When I have a trouble area, or think I've found a rendering bug, I create a test page and play with it to discover the minimum code needed to recreate the problem. I almost always end up learning something more about HTML/CSS/Browsers that I can use a lot, as well as fixing the immediate page.

This playing around can work either way - building up a new page from scratch with just the test elements, or starting with a copy of a page I'm working on and eliminating factors one at time.

EDITORS
My favorite editor is Homesite - it's one of the reasons I stopped indenting, because I can just use it's handy "find matching tag" utility. Its customizable, on-board validation is another nice feature that allows me to find major errors without always running to the W3C.

DEVELOPER'S EXTENSION
The Developer's Extension for Moz/FireFox is a really nice debugging tool - the ability to outline various elements visually (block elements, deprecated elements, frames, table cells) is a BIG time saver - and it's integration with the W3C validators (HTML and CSS) is also pretty sweet.

[pageoneresults]

Excellent topic and one that I too always enjoy participating in. It also gives me the opportunity to plug my favorite WYSIWYG Editor FrontPage when these discussions come up! ;)

FP2003 has added a host of features that any hard core developer would appreciate. Since all of these features are incorporated into my development environment, I'm one button away from finding and troubleshooting any problems.

One really neat feature that has been part of FP for quite some time is the Ctrl + / option which is also referred to as the Reveal Tags option. This allows me to see all tags at the WYSIWYG level. If there are any missing tags or improperly nested tags FP will alert me to those with the use of various icons.

For example, if there is an ending tag missing, I get a yellow icon with a question mark in it. If I click that icon and then go to HTML view, it puts me right on that tag so I can see what is going on. In most instances, it is just a matter of deleting it.

I've also just recently downloaded the upgraded version of the Iconico WebTools Pro [iconico.com] which in itself has just about everything I need for debugging routines.

The W3C has been my bible when it comes to learning. Without it, I would have been lost because I am pretty much self-taught.

In reference to validation, I strongly support the W3C in their efforts for a valid web. All sites that I've developed over the past few years are minimum HTML 4.01 Strict and XHMTL 1.0 Strict.

A quick tip...

Validating your CSS from the actual page using the [jigsaw.w3.org...] produces additional information that you may not see if you are just validating your CSS file specifically.

[Reflection]

EDITORS
My favorite editor is Homesite - it's one of the reasons I stopped indenting, because I can just use it's handy "find matching tag" utility. Its customizable, on-board validation is another nice feature that allows me to find major errors without always running to the W3C.

I love Homesite, and I don't even take advantage of most of the stuff it offers. Anyway I wanted to mention that one of the best debugging tools is a rather simple one, color coded text. Color coded text allows you to find a lot of mistakes as you are coding and before you head off to the w3c validator.

[tedster]

Color coded text allows you to find a lot of mistakes as you are coding

Ain't it sweet?

My chosen color for content is black. So if what I'm typing or pasting in shows in blue, then I know that my markup is not correct, that Homesite sees this text as something other than content. So, I look back and find a missing end quote or whatever, right there and in the moment before I get lost in other details.

Other color coded editors should offer a similar advantage. And color coding also helps for a quick debug of a document that I've never worked with before. Just open it up in a color coded editor, and the color patterns help me zero in on trouble spots very nicely.

[iamlost]

The biggest help by far is the use of CSS, especially external CSS files. The elimination of some style tags (esp. <font>) and the placing of style elements/attributes in an external file makes (X)HTML debugging much much easier. The (X)HTML tags do not get quite so lost in the underbrush.

As I still muddle through with Notepad my colour coding is a stark classic black on white. Everyone else I work with uses Homesite - I almost break down and switch each year but then decide to stay with what I am familiar with. Old dogs and all that ...

The various validators are the second greatest help. The HTML/CSS ones are almost just a "final quality check" now but I still go back and back and back on accessibility issues. I keep telling myself that they will become as ingrained as HTML/CSS have become ...

Once the code is clean and it validates making it cross-browser compatible has become (almost) a breeze - thanks WebmasterWorld! I do need to get an Apple to replace leaning over friends shoulders bumming time on their browsers ... they keep the old IE(mac) just for me! Priceless.

I still use a small amount of indenting in my code. I place the main layout blocks without indent and indent (one tab only) the lesser blocks within. Otherwise I just utilise line breaks similar to tedster. Easy visual separation without getting lost in an indent stairway.

I am now beginning to use multiple CSS files (how split depending on site) to shrink the size of each - they were starting to get as bad as the old muddled HTML and <font> days. How do you folks split them ... or do you?

NOTE: I am pleased that pageoneresults has upgraded from Word(save as HTML) to Frontpage. Congratulations.

[BlobFisk]

Colour coding is a great one - one I completely overlooked as I am so used to it!

I use Scite as my editor and it is not bad for coding markup (betted at CSS and JS and server side languages). If your editor can capture errors all the better! Tedster, Homesite sounds very powerful, I must look at that...

Another interesting thought struck me. Many development groups work to the XP (Extreme Programming) methodology of Paired Programming and Peet Reviews. Paired Programming is basically 2 people working on one problem/bug/feature, brainstorming and working as one.

Peer Reviewing is done whenever a change is being added to the codebase. A developer works on the fix/feature and before committing the code gets a fellow developer to check the approach and code.

I wonder if such an approach would work in our area?

[photon]

Color coded text is also known as syntax highlighting. For me, that's the one absolutely required feature for any HTML editor I use (with FTP capabilities a close second).

One simple technique I use is to create the opening and closing tags at the same time. That is I'd first type

<div></div>

, then add the child elements. In fact, I've got HTML-Kit set up to automatically produce the closing tag when the opening tag is created, and then place the insertion point between the two. Makes wondering if I closed that tag twenty levels up a thing of the past.