From CSS Discuss
Web page code can be submitted to certain pieces of software, the purpose of which is to ensure that the code follows either its own Document Type Definiton (otherwise known as a DTD or doctype) or a particular profile defined so as to comply with reasonably well-defined standards. The process of using such software is known as "validation" and the primary goal of validation is to ensure that the submitted code contains no obvious, facial mistakes. Validated code is much more likely to render properly in all browsers. Moreover, valid code, being standards-and-doctype compliant, is much more forward-compatible - meaning newer browser versions will be less likely to break it. And finally, if you are asking for help on the Css Discuss List, we will often ask you to validate your page before we are likely to help you. Validation can catch many mistakes that are otherwise very difficult to spot, such as missing semi-colons or length units. Valid code can still use Css Hack, but also consider Avoiding Hacks.
How to Validate:
There are two steps to validating web page code. First, the underlying HTML or XHTML markup must be checked. Even perfectly valid CSS may not have any idea what to do to a page with bad markup. You can go to http://validator.w3.org/ to validate both HTML and XHTML pages. Note that the doctype on your page, in addition to determining the Rendering Mode of the browser, also determines which standard the validator will use in parsing the document. There is quite a difference between the various flavors of HTML and XHTML, so be sure you understand which doctype the validator will be using on your document and what implications that has for your document.
The second step is to validate your CSS. Once you have known valid markup, then you still need to check that you haven't made any glaring mistakes in your CSS. You can go to http://jigsaw.w3.org/css-validator/ to begin the validation process. Note you may choose to validate your CSS entirely separately from the referenced markup, and that you can submit to the validator either an independent CSS file or an (X)HTML document that itself contains or calls CSS. Unlike markup validation, in which the document itself determines which doctype is used, for CSS the individual submitting the document must select from the profile options available on the validator. Most likely you'll want CSS 2 (the most current full standard) but of others may be appropriate for certain purposes.
What do the results mean?
If your CSS is valid, you will get a nice message from the validation service verifying that your css validates, and giving you permission to use the W3C certification icon:
Note that if you get a message with this icon and a note of congratulations, you have a valid, error-free page. Your page may still, however, contain various warnings. The most typical warning is that you have failed to specify a color with your background color, or vice versa. Warnings are not the same as errors, and a page with warnings but no errors is still considered a valid page. The warnings are there as a convenience to the author, to let you know that you may have missed something. Some unfixed warnings may very well have catastrophic results for users, and others may very well be ignorable. It is up to the author to determine which ones present serious problems and which ones don't. If you don't have any idea if a warning is a serious threat to your page, ask someone.
In the case of colors and background colors, it can be dangerous to specify one without the other. Let's say, for example, that you have specified a white background color, but have not specified a text color. If the user is vision impaired, they may have set a user style sheet or other preference to display white text on a black background. However, your white background may override their background declaration (depending on how the various styles are declared), and the user will be left with their white text on your white background, making the content of the page invisible. So it is a good idea to go back and check. Frequently, color warnings appear in places where a given element will allow the background from a different element in the document to "shine through", thus in effect taking on the background of that other element. It may often be relatively safe to leave these, but you will need to review your page and make your own judgement for each instance.
Validation is not the be-all-and-end-all of web pages. A page can be invalid for some very good, thoughtful reasons. On the other hand, it is generally a bad idea to have an invalid page just because it is easy or because you happen to know a bit of invalid code that still works correctly in a particular browser. If you as the author haven't carefully considered why you want an invalid page, you probably should clean up your code. But if, for example, you are using a CSS3 property, which you know won't validate but which some newer browsers nevertheless understand, you may be well-justified in ignoring the fact that the advanced property prevents the page from returning a positive result from the validator. If you are in this position and still need help from the Css Discuss List, it is a good idea to mention that you know your page doesn't validate and to mention the reasons why.
Tips on fixing problems
If you go to validate a page and it comes up with 30+ errors, don't panic! Most of the time a large number of errors is the result of a "cascade" effect from a single error earlier on in the page. For example, say you forgot to close a element. Since the span is still open, you could be inundated with errors about other elements on the page being invalid because they are not allowed inside a span. Close the span element and all of those errors will be fixed as well.
The most common error by far looks something like this:
reference to entity "BV_Engine" for which no system identifier could be generated.
What that means is simply that you've got a URL with an & sign in it that you forgot to escape.
The & sign in this URL should be &. In fact ALL & signs in an HTML document should be escaped in this way to avoid causing confusion to HTML parsers. For the above example, replacing it with
will fix the error and give you better browser compatibility as well.
For a contrasting viewpoint concerning much of what appears on this page, please see http://www.cs.tut.fi/~jkorpela/html/validation.html.