There are still discussions going on among webmasters about what’s more important – valid code or design which is displayed alike on all web browsers. I do not take hard stance – i think that webpage should look the same on all browsers but at the same time webmaster must write as valid code as possible.
So, why validate code
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 DocumentTypeDefiniton (alsok nown as a doctype or DTD) or a particular profile defined so as to comply with reasonably well-defined standards (validation). 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. 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 CssHacks, but also consider AvoidingHacks.
W3C also gives some answers to question why it is important to write walid code. Validators – tools to help webmaster to write valid code
W3C Markup Validation Service
The first step is to check (x)HTML markup. Even perfectly valid CSS may not have any idea what to do to a page with bad markup. W3C Markup Validator will check your page whether it is HTML or XTML. Just paste your link, upload file or paste your code and get the result.
Note that the doctype on your page, in addition to determining the RenderingMode 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.
Validator will display all errors and warnings. 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.
CSS Validator
Next step is to validate your CSS (cascading stylesheet). Note that the doctype on your page, in addition to determining the RenderingMode 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. CSS validator, as you can guess, validates cascading stylesheets.
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 the others may be appropriate for certain purposes.
RSS validator
As RSS is becoming more and more used in web development, it becomes important to check if your RSS is generated corectly. Therefore RSS validator might be very useful, too.
…and more
Here is full list of validators offered by W3C: http://www.w3.org/QA/Tools/
At the end
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.
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. For example, <a href=”script.cgi?id=4&BV_Engine=20″>. 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 <a href=”script.cgi?id=4&BV_Engine=20″> will fix the error and give you better browser compatibility as well.