homepage Welcome to WebmasterWorld Guest from 54.198.157.6
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Pubcon Platinum Sponsor 2014
Home / Forums Index / Code, Content, and Presentation / HTML
Forum Library, Charter, Moderators: incrediBILL

HTML Forum

    
Common Validation Errors
what they are - how to fix
tedster




msg:610113
 2:34 am on Apr 2, 2002 (gmt 0)

We now have several threads that deal with common HTML validation problems. And the more people work toward writing valid code, the more challenges we'll see.

I'd like to collect the ANSWERS we find here on this thread - similar to the generic javascript thread [webmasterworld.com] 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!

 

papabaer




msg:610114
 7:25 am on Apr 2, 2002 (gmt 0)

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>

pageoneresults




msg:610115
 8:50 am on Apr 2, 2002 (gmt 0)

<script language="javascript" src="script.js"></script>

Not defining javascript type...

<script language="javascript" src="script.js" type="text/javascript"></script>

tedster




msg:610116
 4:46 pm on Apr 2, 2002 (gmt 0)

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.

Xoc




msg:610117
 6:03 pm on Apr 2, 2002 (gmt 0)

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.

papabaer




msg:610118
 6:18 pm on Apr 2, 2002 (gmt 0)

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.

pageoneresults




msg:610119
 6:45 pm on Apr 2, 2002 (gmt 0)

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>


bobince




msg:610120
 8:55 pm on Apr 2, 2002 (gmt 0)

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 '&' 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)

pageoneresults




msg:610121
 10:01 pm on Apr 2, 2002 (gmt 0)

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.

pageoneresults




msg:610122
 10:03 pm on Apr 2, 2002 (gmt 0)

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.

pageoneresults




msg:610123
 10:11 pm on Apr 2, 2002 (gmt 0)

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.

hstyri




msg:610124
 2:37 am on Apr 3, 2002 (gmt 0)

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 %20. 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.

bobince




msg:610125
 11:31 pm on Apr 3, 2002 (gmt 0)

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.

brantgurga




msg:610126
 2:31 am on Apr 12, 2002 (gmt 0)

Check out Mozilla Evangelism at mozilla-evangelism.bclary.com to help websites becomes standards compliant.

papabaer




msg:610127
 3:20 am on Apr 12, 2002 (gmt 0)

[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?

[jigsaw.w3.org...]


  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...

papabaer




msg:610128
 3:51 am on Apr 12, 2002 (gmt 0)

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...

leogah




msg:610129
 5:16 pm on Apr 12, 2002 (gmt 0)

"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 [people.fas.harvard.edu ] for some test cases.

Brett_Tabke




msg:610130
 5:42 pm on Apr 12, 2002 (gmt 0)

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.

DrDoc




msg:610131
 5:56 pm on Apr 12, 2002 (gmt 0)

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.

dvduval




msg:610132
 6:14 pm on Apr 12, 2002 (gmt 0)

Is it easy to be penalized by a search engine for having common validation errors such as leaving out the doctype definition?

Tapolyai




msg:610133
 7:23 pm on Apr 12, 2002 (gmt 0)

forgetting the enclosing <UL> for the <LI> tags...

pcguru333




msg:610134
 8:05 pm on Apr 12, 2002 (gmt 0)

For XHTML 1.0 validation I have a hard time remembering the closing /.

ex: <br /> or <img src="xx.gif" />

tedster




msg:610135
 3:47 am on Apr 13, 2002 (gmt 0)

> 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.

keyplyr




msg:610136
 8:30 am on Apr 13, 2002 (gmt 0)

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.

leogah




msg:610137
 9:54 am on Apr 13, 2002 (gmt 0)

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 [opera.com ]

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.

Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Code, Content, and Presentation / HTML
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved