I'd like to collect the ANSWERS we find here on this thread - similar to the generic javascript thread we already have. If you are looking for help on a specific validation error, don't post that here, start a new thread. Then, if the answer we find is common enough, we can add it here after the issue is resolved.

Improper Nesting of Tags
This is a very common error. All it means is that you close tags your in the reverse of the order you opened them: <xx><yy>content</yy></xx>. An easy error to make, but it's easy to fix, too.

Some browsers do very creative tag handling to work around nesting erors -- they will automatically assume the next closing tag is what it should be and they will IGNORE what your code actually says. So the browser will read this:

<b><i>word word</b>word</i>

as if it were:

<b><i>word word</i>word</b>

That can give you some unexpected results. It's best to nest properly!

Unclosed Tags
Worse than bad nesting, these ugly bits of code can really snarl up a browser - and it's easy to leave a tag open by accident if you cut/copy/paste a lot of HTML snippets.

Inline Element Cannot Contain a Block Level Element
It sounds like a foreign language the first time you read this one!

HTML has two types of elements - block level (like div, p, table) and inline (b, i, font, em, etc). Block level elements stake out a block or box on the page. They may contain other block level elements or inline elements. But in valid code, an inline element cannot contain a block level element.

The most common reason for this error is wrapping one set of <font> tags around several <p> tags. For code to be valid, each <p> tag needs its own <font> and </font> before the next <p> comes along. That's one reason the font tag is deprecated - it's very, very messy and resource wasteful!
One of the most common and most obvious:

Missing alt tags: makes you regret the 42 spacer.gif's you needed to make that fancy new table work...

Missing quotation marks for element attributes (xhtml validation)

Deprecated tags! While these may only produce Warnings and not actually prevent validation, it is time to put deprecated tags to rest. Four of the most common:

• <applet>
  
• <basefont>
  
• <center>
  
• <font>
  

Not defining javascript type...

<script language=javascript src=script.js type=text/javascript></script>
Let's hold this thread to one topic - explanations and answers for common validation errors. That way we can build a resource for everyone.

If you want to ask a question, express an opinion, or pursue discussion of a related area, please start a new thread for that. Some good topics have already been brought up, but I don't want to pull this thread off track, so those posts have been deleted here.
One of the most common I run into in my code is this:

<p>This is a paragraph<p>

I always leave off that slash on the closing tag. It will validate in html, but not xhtml for this example.
Ah, the joys of Homesite and auto tag completion settings... ;)

Nesting elements has always been my nemisis; it seems no matter how attentive I may be, I always find an open div (or table) tag somewhere. This occurs fars less frequenlty now, but still often enough to keep me checking.

I have gotten into the habit of quoting all attributes. I can thank XHTML for that...

One other habit I have acquired is when writing css declarations I always use a semi-colon; to end each statement. I find it helps if I happen to go back and add more styles. Keeps my from scratching my head trying to figure out why my CSS isn't working.
Let's not forget the very first issue some will be faced with...

Warnings
Warning: No Character Encoding detected! To assure correct validation, processing, and display, it is important that the character encoding is properly labeled. Further explanations.

Below are the results of attempting to parse this document with an SGML parser.

Fatal Error: no document type declaration; will parse without validation

I could not parse this document, because it uses a public identifier that is not in my catalog.

You should make the first line of your HTML document a DOCTYPE declaration, for example, for a typical HTML 4.01 document:

<!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN>

<HTML>

<HEAD>
<TITLE>Title</TITLE>
</HEAD>

<BODY>
<-- ... body of document ... -->
</BODY>

</HTML>
Forgetting to encode ampersands in <a href>

All HTML attributes must be HTML-escaped, including URLs in an href or src attribute. This:

<a href=foo.html?a=b&c=d>

is wrong. Though it may work in common browsers today, it won't if you happen to pick a name after the '&' that happens to match an HTML entity name. Or if a new entity '&c;' is added to a later version of HTML. Instead use:

<a href=foo.html?a=b&c=d>

The '&' will be decoded before the browser uses it as part of a URL, so the script will never see it.

<fixed entity>

(edited by: Xoc at 2:30 pm (utc) on April 3, 2002)
Here's the culprit that has kept a lot of us from validating...

marginheight=0
^Error: there is no attribute MARGINHEIGHT for this element (in this HTML version)

marginwidth=0
^Error: there is no attribute MARGINWIDTH for this element (in this HTML version)

The only fix for this is to utilize CSS and absolute positioning. NN4.x needs the above attributes in the <body> tag to render proper margin specifications.
Another simple one but it causes errors.

<hr size=1 color=#C0C0C0>
^Error: there is no attribute COLOR for this element (in this HTML version)

The only fix for this one is also through CSS. Or, you can do it the hard core way and make a cell with a 1px transparent gif and then assign a color to the cell.
I see this one quite a bit with WYSIWYG designs where people utilize the border feature of tables.

bordercolor=#ffffff
^Error: there is no attribute BORDERCOLOR for this element (in this HTML version)

The options are to utilize CSS or create multiple tables with one of those having a cellspacing of 0, cellpadding of 1 and a table color of your choice. You then assign colors to your cells (usually white) and this gives you your table with border.
Forgetting to encode ampersands in <a href>

One problem I see a lot are URLs where the / in the path are written as \. Some browsers deal with it, others don't. Anoher common URL problem are spaces. They should be encoded as . Again some browsers handle the problem, other doesn't.

One important issue would be whether search engine robots handle incorrect URLs. You may find that URLs that works in MSIE are dropped by some robots.

In other words: Use proper URI encoding.
I'm reposting this with asterisks where ampersands should be as I can't edit it any more. It looks like the forum's Edit function is also a bit broken with regard to ampersands - it is forgotting to escape them on output to a textarea, thus destroying posted entities. Very poor. Anyway, this must have happened to Xoc editing my post, which is now quite broken (bah!!) though it will still display okay in some browsers...

Forgetting to encode ampersands in <a href>

All HTML attributes must be HTML-escaped, including URLs in an href or src attribute. This:

<a href=foo.html?a=b*c=d>

is wrong. Though it may work in common browsers today, it won't if you happen to pick a name after the '*' that happens to match an HTML entity name. Or if a new entity '*c;' is added to a later version of HTML. Instead use:

<a href=foo.html?a=b*amp;c=d>

The '*amp;' will be decoded before the browser uses it as part of a URL, so the script will never see it.
Check out Mozilla Evangelism at mozilla-evangelism.bclary.com to help websites becomes standards compliant.
http://mozilla-evangelism.bclary.com/
This above URL is unuseable when viewed with the Opera browser.

Could it be because of the following Warnings generated from the page's CSS when run through the W3C CSS Validator?

http://jigsaw.w3.org/css-validator/validator-text.html

1. Line : 2 Level : 1 You have no color with your background-color : body
   
2. Line : 6 Level : 1 You have no color with your background-color : #menu
   
3. Line : 29 Level : 1 You have no color with your background-color : #menu
   
4. Line : 49 Level : 1 You have no background-color with your color : p
   
5. Line : 57 Level : 1 You have no background-color with your color : h3
   
6. Line : 66 Level : 1 You have no background-color with your color : a:link
   
7. Line : 66 Level : 1 Same colors for color and background-color in two contexts a:link:hover and a:link
   
8. Line : 67 Level : 1 Same colors for color and background-color in two contexts a:link:hover and a:visited
   
9. Line : 67 Level : 1 You have no background-color with your color : a:visited

Look closely at the anchor CSS declarations:

a:link {
color : #339;
}
a:visited {
color : #339;
}
a:link:hover {
color : white;
background : #339;
}
a:visited:hover {
color : white;
background : #669;
}

Visit the above page with Opera to see the troublesome rendering; the link text does not even become visible until the active state is triggered.

First Rule of applying color is to supply a background-color for each and every color declarartion, avoiding the above unseable situtation.

I going to check this out...
Pageone, here is an alternate method for creating a hr rule with color. The answer is CSS of course (naturally!)

<div style=color:#000;background-color:#696969;height:5px;font-size:1px;></div>

By setting the font-size to 1px you solve an inheritance issue that prevents the div's height from rendering smaller than the font-size of the parent container.

For example, if the body{font-size:12px;} is the only font-size declaration, then Opera and Netscape 6.x/Mozilla will not display the hr's height at less than 12px - MSIE incorrectly forgives this of course...

If you use this in a div or table, you can let the containers padding set the width, or you can add margin-right and margin-left percentages...
This above URL is unuseable when viewed with the Opera browser.

This appears to be because Opera is buggy with multiple pseudoclasses and applying :hover effects to things that aren't in a hover state.

Take a look at http://www.people.fas.harvard.edu/~dbaron/css/test/pseudos2 for some test cases.
Opera does use a different more user friendly method for some hoover and link displays. I agree there are some anomolies with hoover on a couple hoover attributes, but no other browser does links justice and respects user preferences the way Opera does. It's a very contentious issue, that we've been fighting for a long time.

...all links until the sun goes super nova, should be underlined.
Well, one of the most common mistakes when it comes to HTML validation is using a bad validator.

CSE HTML Validator is an excellent choice!

But, even if you have a good validator, you must make sure to change the settings properly.

Unfortunately we all know that IE and NN are not 100% compatible with each other. Therefore, you will get warnings when using attributes such as bordercolor, marginwidth, or marginheight.

If you're using CSE you can make it validate pure HTML standard as well as IE and NN extensions. Very useful, and very important.
Is it easy to be penalized by a search engine for having common validation errors such as leaving out the doctype definition?
forgetting the enclosing <UL> for the <LI> tags...
For XHTML 1.0 validation I have a hard time remembering the closing /.

ex: <br /> or <img src=xx.gif />
> Is it easy to be penalized by a search engine for having common validation errors such as leaving out the doctype definition?

I don't think omitting the DTD causes SE troubles. But open tags, bad nesting, etc might hurt a spider's ability to take in the entire page.
Just downloaded the free CSE HTML Validator lite and ran my site through. I fared pretty well - with only a dozen out of 100plus pages not validating clean.

The problem on each of those pages: ampersands and no break spaces.

I know I did it correctly when I wrote it - LOL Somehow the wicked code gremlin snuck in and changed it! Seriously, sometimes symbols do degrade into the mark-up especially if you've ever recovered your pages from a server.
Brett, I don't quite understand what is contentious about my earlier statement. Some browsers have better CSS2 support than others but none are perfect, and this page happens to be one that Opera gets wrong.

The limitation is documented on the Opera site http://www.opera.com/docs/specs/#css

All CSS2 selectors are supported with the exception of ... combinations with pseudo-classes before other selectors

Mozilla evangelism site displayed best by Mozilla is hardly surprising news though.

It's a useful reminder that the slightly more obscure corners of CSS still cause compatibility problems, even in modern browsers.

Featured Links: