1) Nested Tables
This is the biggest problem on the seeUthere site. Many pages with grids take way too long to download. On Netscape these pages can even crash the browser completely. What is the leading cause of this massive slowdown? Too many nested tables.

Try these figures on for size:

That's right, from an unbearable 40 second download on a major page of the seeUthere.com site, to only 5 seconds. I pared down the bloated excess code, eliminated a few hundred lines of unnecessary whitespace (which is still processed by the browser, though it's not displayed), and that helped quite a bit.

The document weights above don't even include 76KB worth of images, that's 53KB just of *text* on the original page (the recommended average page weight with images is about 30KB!)

But the drastic increase in download speed is mainly caused by reducing the number of maximum nested tables on this page from seven to four, and most of those tables are located within the grid. If you are about to open another table within a table, think about it first. Can you structure things differently? Can you stack tables on top of another rather than within one another? It takes a bit of thinking about spatial relationships, but there is almost no reason on Earth why you need to nest tables seven layers deep.

Rather than adding another table just so that you can have a box around your data, why not space it out properly from everything else on the page so that the extra box and table can be eliminated?

Here is an example of an optimized grid page with several layers of nested tables removed.

2) Escape Characters
I won't say much about these, since I only noticed occasional lapses in the site, and 90% of those concerned double quotes ("") and ampersands (&) left unescaped in the text. Most of the time it's not a problem, but if one of those pairs of double quotes escapes from its partner and becomes a free agent, there could be big trouble. An extra double quote is notoriously difficult to locate as the source of your problems. So be careful.

You can find a list of HTML escape characters in any HTML reference text or in many places online.

3) Elements, Attributes & Case
The current HTML 4.0 standard dictates that elements (like TABLE) should be in uppercase and their attributes (like width) in lowercase. This is strictly for readability, since HTML is case-insensitive at present.

XHTML is another story. It has been developed (see the 1.0 standard at http://www.w3.org/TR/xhtml1/ to expand HTML to accommodate future XML extensions. You can use it right now if you like! It's basically strictly conforming HTML, so if you had some idea that in the future browsers would be able to take any jumble of text that even remotely resembles a web page and be able to interpret it correctly for you, you're wrong. We're actually moving in the opposite direction, where developers need to be able to write clean strict HTML.

In XHTML all elements and attributes must be in lower case, so it's a good idea to start doing this now. In addition, it makes a document easier to work on if everyone folows the same convention. Reading code in a page where half the elements are in uppercase and half in lowercase is confusing. If everyone uses lowercase for both elements and attributes, that just makes things easier overall.

One thing that is NOT acceptable is to write any elements or attributes in mixed case. HTML is not JavaScript. Mixed Case is just not good form in HTML, and could cause serious problems when XHTML becomes the standard, so break your bad habits now.

Incorrect:	bgColor="FFFFFF" bgcolor="#Ffcc66"
Correct:	bgcolor="#FFCC66"

4) Indenting Vertically
It is easiest to read HTML when it is indented vertically rather than horizontally (see my example below). Horizontal indenting requires that you scroll sideways to read it properly, which is hard on the eyes. With vertical indentation all you have to do is look straight down the left margin to see everything opening and closing. Put a full return break in between each table row, add a comment when you open a table and when you close it and voila! Your code becomes very easy to read, edit, and pass on to other people. If you write your code like this you will understand it more easily and won't have to rely on Dreamweaver to understand what is going on in the page. Even heavily nested tables become a snap to read and understand.

Horizontal indentation also creates a lot of extra whitespace in the code, which still has to be processed by the browser, though it is not displayed. This adds to the document weight.

The third reason not to do it is that browsers have problems with too many spaces within tables and can display weird spacing in the actual page because they choke on all the whitespace within a table. The most notorious of these problems is one caused by a </td> tags being placed on the next line down from the content that it closes. We'll talk about that more below...

And the last reason is that it is a whole extra process to keep up with the indenting system already present when you are making changes to a page. How many tabs do you need to move your content over by? Where did the last table on that level close? Can you even keep track? Are there already lots of mistakes in the indenting system?

It's much easier to just bring everything over to the left margin and go from there.

Here's an example of a simple nested table, indented vertically

5) Whitespace and Tables
Avoid excess spaces in your code whenever possible. Although browsers are not supposed to process whitespace, excess space (especially within tables) can create problems. Indent minimally (the vertical indenting system above is a good choice, since it mostly uses carriage returns and not spaces or tabs)in order to make your HTML readable and user-friendly, but don't add extra carriage returns or whitespace if you don't need it.

Tables are extra sensitive to whitespace. Be especially careful about putting a closing </td> tag on a line all by itself. This can create mysterious and unsightly gaps on the page in certain browsers, especially Netscape. Always put your closing </td> tags at the end of the same line as the content that this tag is enclosing.

Incorrect:	<td> content </td>
Correct:	<td>content</td>