Working with Web Page HTML, CSS and Link Validators

This article is the first in a series whose goal is to help you create error free web pages that are compatible with
major search engines and browsers. Tools for help in your task of maintaining your site(s) will also be discussed.

Both Programmers and Web page designers ranging from long time career professionals to novices often use
automated validators for many varied reasons.

Maybe you are working on a proposal or bid for a contract and you want quick analysis of the existing markup
Maybe you provide technical support and you need quick analysis to provide timely answers
Maybe a client has named this as a requirement or you are just conscientious and you insist that in your QA
certification process, all your code is indeed validated to standards
Maybe you have a site that does not get indexed by search engines but looks ok in a browser and you want to
make sure the site does not contain serious errors that cause the bots grief when they try to navigate your page
You have to fix or want to avoid cross browser issues.

These are all good reasons to use validation tools.

>>Sidebar note:
This is also a controversial issue believe it or not! While I recommend using validated code, you do have to keep in
mind that:
1. Successful validation on its own does not insure your markup is 100% error free.
2. If you currently have site(s) that do not pass validation you may be confronted with a major, non-trivial makeover
to achieve successful validation.
3. Some search engines bots are more "understanding" of faulty markup than browsers, Thus some SEO's make a valid
point and consider validation less important than keywords, titles, links, and content. But how much broken is ok?

That being said, I suggest using "Trusted" validators as early as possible in your web site design and most certainly
before you publish a new site or page.
Remember that all browsers are not alike. They often have proprietary features and handle errors differently. Using
validated markup will help insure cross browser compatibility by identifying markup errors that may not be apparent
in your current browser.
Also, Do not tend to use the validator as a panacea, They are tools that are best used as a second "pair of eyes".

>>Back to business:

There are many different validators. There are standalone validation applications you can purchase and/or download,
Some that are plugins for your browser, and there are online services. On the right hand side I have added links to
some of the more popular free online validation services. It is the latter I will focus on in this article.

Running these online validators couldn't be easier. Just go to the site and key in your URL - www.example.com.
If you are using a page validator, key in the complete path to your page. For example, if you use the above site
name and your page is mywebpage.html then key in www.example.com/mywebpage.html.

Note: On some validators you may need to include the protocol, so you would prefix the above with http://
For example: http://www.example.com/mywebpage.html

The validator will then "spider" your site or page and present you with the results.

Sometimes it is difficult to understand and thereby rectify issues presented by the validator. My goal with this
article is to help you understand how the validator basically functions and provide solutions to some of the more
puzzling if not downright misleading errors they report.

A word about Doctype's and the Doctype statement

The doctype or public text identifier is normally (except e.g. MS formats) the top line of your page and should contain
the correct specification for the markup your page is using. The first half of the statement below (Dark Blue)
identifies the specification to which this document conforms. The second half (Bold Black) is the URL of the DTD or
Document Type Definition that details this specification. Here is an example of an HTML 4.01 transitional Doctype
statement:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

This specification for HTML 4.01 DTD is one you will likely see most often. It includes all the definitions in the strict
DTD, but allows depreciated elements like <font>. This type is useful when you use CSS but need to use markup
that supports non-CSS browsers.

There is also frameset type which includes all definitions of transitional, but replaces the <body> with framesets.
It looks like this:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">
This doctype is commonly used for Non-CSS HTML pages.

There are also similar DTD's for XHTML 1.0 doctypes and are used with those particular page formats. Here is the
doctype statement for strict XHTML

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"

Most browsers will render the HTML ok without the doctype but the HTML Validators however, will fail miserably if it is
mismatched. Validators use the doctype to detemine the correct DTD for parsing the markup.

Understanding HTML validator results and fixing your HTML markup

Question: The results are showing many errors! Where do I start?

Now assuming you have the correct doctype, It's best to start from the beginning of your page and try to think like
the validator. By that I mean start scanning the data and when you get an error, flag it. Continue and use the
previously scanned data as your context, disregarding most if not all previous errors. Using this method you will
often wind up reporting a cascade of errors when in fact there may be only one!
Together, Lets consider the following example:

1 <pre>Now is the time for all good men to come to the aid of their country.
2 More.
3 Even More.
4 /pre>
5 <h2>This is a list of good men</h2>
6 <ul>
7 <li>John is good man 1</li>
8 <li>Mike is good man 2</li>
9 </ul>
10 <pre>Now is the time for all good women to come to the aid of their country.
11 More.
12 Even More.
13 </pre>

Note: The lines are numbered for reference only.

Now, Say you as the validator start scanning the above HTML. You see a open preformed text <pre> tag in line 1.

You expect the next preformed text tag to be the </pre> close tag. In the HTML however, the close preformed text tag
is missing the less than symbol as shown on line 4.

So, as you scan has a you encounter a open header tag as shown on line 5 and since headers are not allowed within
the preformed text, you flag that as an error.

Continuing you find yet another type of tag that formats text, The unordered list tag <ul> on line 6.
You will consider that an error too! You flag that and continue.

Now you find the open preformatted text tag <pre> on line 10. Since nesting preformed text containers is not allowed
you flag another error. Now the validator thinks you have 4 errors when in fact you have only one!

The lesson here is that If one of the errors you get has something to do with a missing close tag, Try revalidating after
fixing the first one. Often you will find many of the remaining errors disappear.

Question: The results show a number of errors but I can't see anything wrong with them!

This is similar to the error cascade mentioned above with two differences. None of the results given show the
actual cause of the errors. In fact, None of the errors indicated have anything wrong with them!

It is my observation, that in most cases this indicative of missing close tags or those that don't have a preceding
open tag.

Again, the best advice is to start at the beginning, but in this case, scrutinize the markup from the beginning of the
file up to the first reported error very carefully.

Common causes of validation errors

Using break tags <br> in the wrong spot can be an issue. The page may look fine in a browser but its use in certain
contexts is illegal. One common error is using breaks after the </li> close tag and the next open line item tag <li>.
If you want more space between list items you may want to consider using the style="margin-top: " CSS property\value.

When using the preformed text tag <pre> be careful what you put inside. Lists (ordered or unordered) are a no no.
Other Items not allowed within a </pre > are <H#> and  <HR>.
Close your pre first </pre >, Make your list or header, Then open a new preformed text section.


  Question: I've just verified my site with Google (or Yahoo*) but now my home page fails validation!

 

Google Webmaster Tools requires you to prove you are the webmaster of the domain and one method is for you to
place a meta verification line in the head section of your page. There is an issue however, that the tag given by Google,
assumed you are using a doctype of XHTML. In doing so they have an extra space and a "/" (fwd slash) on the
end that is invalid for the HTML doctype. If you use a validator and it calls out an error with your close head tag
</head> then this is a likely cause of the validation failure.

* Yahoo also has a verification meta tag and has been subject to the same issue as was the Google tag. Check yours!

To rectify this, change your meta from: (example)

<META name="verify-v1" content="fgnfgnfgnfgn41gfn684ngf51fnpM=" /> 

to this, removing the " /"

<META name="verify-v1" content="fgnfgnfgnfgn41gfn684ngf51fnpM=">

Then revalidate your page. You may find that, hopefully, many of your errors were just a cascade effect and go away.
If errors persist, we recommend you endeavor to correct them. For additional help be sure to review the FAQ and help
for the validator you are using.

While some validation errors may cause some cross browser issues, as said before Googlebot is quite resilient and can
handle many markup errors, but you do want to have the best chance for success when Googlebot or Yahoo! Slurp
comes to call!

Understanding CSS validator results and fixing your Style Sheets

Of course the first thing to do is make sure your CSS itself is correct. To this end I have made available the
free version of TopStyle lite in the downloads section in the right pane. This tool can be used to identify the
CSS elements available and list the correct syntax automatically. It also plugs in to popular text editors such
as Notetab and PSPad.

As discussed in my section regarding Understanding HTML validator results and fixing your HTML markup, It's best
to start from the beginning. Look for any unpaired "{}" and missing ";" terminators. Errors of this type will cause a flaw
in the validators working context that results in incorrect parsing of the remaining style sheet.

Try revalidating after fixing the first one. Often, you will find many of the remaining errors disappear.

If you find the results point out errors and there doesn't seem to be anything wrong, Carefully scrutinize the lines
preceding the first reported error just as you would with HTML errors of this type.

There is one area where the CSS Validator is quite different than the HTML Validator. In addition to errors, you may
receive warning messages. These warnings help address issues or conflicts that may occur when your styles are
applied to pages. Conflicts can occur surprisingly easy because of the inherent "cascade" property of style sheets.
This is because the same attributes can be redefined at different levels. While this multilevel ability give CSS much
power and flexibility, You could wind up with some surprising results that cause you to wonder "Why did it do that?".
This can become quite tedious to figure out and fix especially when your style sheets get large and complex.

This is where the warnings become your friend. They will point out value/attribute pairs that while syntactically correct,
Logically they are in conflict. For example defining the same color for a foreground and a background.
For example: "color: #0000FF; background-color: #0000FF;"

This warning is reported when this definition occurs within the same ID, the same Selector or the same Link.
This warning is also reported when this occurs between elements such as in an ID and a Selector but it is usually
noted "This occurs when these elements are used together in the same context".

There is one warning message you may see when you have this foreground\background conflict that may be less than
obvious: "This property applies to block-level elements". If you see this warning, check for this color conflict.
Also, If you just fixed a foreground/background conflict, then attempt to re-validate and get this warning, try refreshing
or re-validating again. In this particular situation the warning may be a false positive. I've seen this personally!

There are also warnings when certain attributes are vague or missing that could cause undesired results in the future
or in certain contexts. No, the Validator is not clairvoyant or using "fuzzy logic" on your code. It is actually using
Logic on your "fuzzy" code!

An example of this not specifying "background-color: #0000FF" and foreground "color:#FF0000 " in pairs.

While this is perfectly legal, In practice it may cause some confusion later when pages get changed or added. Also
once a web site is up and running, it will be more difficult and in some cases problematic if you or some other designer
want to go back pair these definitions.

There is only one way to "Honestly" get rid of the warning. That is, obviously, to always define the background-color:
and color: properties in pairs.

That being said, A word of Caution. There is one technique I have seen mention of in some forums that may be
incorrectly perceived as a "fix" but is in fact, only a cheat.

"Try using "Named Colors" for the color: and background-color: attributes in your ID's (e.g. color:blue) and use
Hex declarations (color:#CCFFFF) for your selectors".

This has the effect of making the validator think the color and background-color attributes do not match when compared
when in fact the values are effectively the same and defeats the whole purpose of the warning!

I recommend trying to specify both foreground and background properties whenever possible throughout your
style sheet and bite the bullet on the size or bandwidth considerations. I have found this is easier if you first
define a theme or look for the web site before you start coding.

Eliminate broken links using Link management, testing and validation tools

Web sites by nature contain many links both internal and external. Sometimes these become the easiest thing to break
and the hardest to maintain.  Broken links can really sour ones opinion of your web site and detracting from its
usefulness. Also if you have numerous broken links, over time that may lower a search engine bots "opinion" of your
site and lower its crawl frequency.

As a web site grows it becomes very hard to test every hyperlink manually. This is best done using automated
tools that will spider your website and test the links it encounters. There are free online tools available and also
downloadable link testers such as Xenu Link . I have provided links to some of the more popular tools on the right
pane for your convenience.

One thing to keep in mind is that the status and availability of external links are under the control of the external
site. To help insure surfers have the best experience and bots can pass on some "Link Juice", test your links regularly.
Also you may want to provide an easy way for web surfers to inform you of broken links such as a simple
form they can submit to let you know of any discrepancies.

That's about it for this first installment on building a quality, search engine friendly website.
Please visit us again as we will be adding new topics to assist your further.

Back to the top

If you found this page useful, consider linking to it.
Just copy (mark then ctrl-c) and paste into your website.
This is how this link will look: Using web site validation tools

<A HREF="/validation.html"> Using web site validation tools</A>

One other thing. If you found this article on using CSS, link, and HTML validation tools useful (or not)
and have comments, criticisms, or suggestions please feel free to drop us a note using our Contact form

Thanks! Enjoy! I hope this is helpful!

Working with Web Page HTML, CSS and Link Validators

A word about Doctype's and the Doctype statement

Understanding HTML validator results and fixing your HTML markup

Common causes of validation errors

Understanding CSS validator results and fixing your Style Sheets

Eliminate broken links using Link management, testing and validation tools

Quick Links

Downloads

Validation Tool Links

CSS and HTML reference guides