The best way to start coding a new website is to make a rough sketch on paper. Draw the content blocks, make short notes on the XHTML and CSS you'll need and try to anticipate the problems you'll encounter. It's highly unlikely that you'll solve all, or even most, problems by this rough sketch, but creating it forces you to think logically and to define the rough outlines of your code. You'll also find that sketching helps you to remember your fundamental decisions and the reasons behind them better than just starting to write code.
Then create the XHTML file. If you've never used XHTML before, your first step should be to ditch some ancient HTML preconceptions. Fortunately migrating from HTML to XHTML is extremely simple:
- Make all your tags lower case (
<p>
instead of<P>
); - Close all your tags, even empty ones (
<br />
and<hr />
instead of<BR>
and<HR>
); - Make all attribute names lower case and quote all attribute values; for example,
<td colspan="2">
instead of<TD COLSPAN=2>
, andonmouseover
instead ofonMouseOver
; - Give empty attributes a value—such as
<input type="checkbox" checked="checked" />
instead of<INPUT TYPE=checkbox CHECKED>
; - Nest all your tags correctly.
Now your HTML has become XHTML. This is not enough, though. By choosing a DOCTYPE
you have committed yourself to the Strict, Transitional or Frameset flavor, and you should make sure that you only use the tags and attributes that your chosen flavor allows.
When you think you're ready, validate your pages. The official W3C Validation Service is the most logical place to start. Nonetheless its error messages can be quite verbose and confusing to the uninitiated. W3C is experimenting with a new validator that gives more understandable error messages.
If you don't quite understand the error messages, ask groups.yahoo.com/group/XHTML-L for help. You're not the first one to run into a particular problem.
Even when your XHTML is perfectly valid it can contain bad coding. You have to avoid a few practices that, though not expressly forbidden, are strongly discouraged.
Tables Revisited
As we saw above, using one minimal table to roughly lay out your page is quite acceptable. Nonetheless, it is important to stress that this minimal table should be the only one. Do not insert more tables into your code. They're not necessary; CSS can do the job for you.
There's one single exception to this rule: you may use tables to display tabular data, for instance stock quotes or long lists of employees with their room numbers and phone numbers. For these bits of data (and only for these bits of data) you can add an extra table to your code.
If you're not sure if a certain data set requires a table, ask yourself how you'd display it in print. If you'd use a table even in print, the data is tabular.
Tagitis
Tagitis is the adding of many useless XHTML tags. This header, for instance, suffers from tagitis:
<h3><em>Header</em></h3>
You don't need the extra <em>
tag. One line of CSS would give the same effect:
h3 { font-style: italic; }
Classitis and Divitis
A common error of beginning CSS coders is to use far too many <div>
tags and class
attributes, like:
<div class="header"> <div class="headerText"> <p class="headerP">This site uses CSS!</p> </div> </div>
Ninety-nine out of a hundred times these complicated structures are unnecessary. When you start writing CSS you should avoid them, instead of thinking you found the one in hundred exception to the rule. Start with simple XHTML:
<div class="header"> <p>This site uses CSS!</p> </div>
Use these two CSS selectors:
div.header { /* styles */ } div.header p { /* styles */ }
You'll find that you can style the entire header by styling these two selectors.