M1 Validation
Validation
HTML and to a lesser extent CSS are forgiving when it comes to syntactical errors in your code. However, it is not good practice to ignore your syntax errors for a variety of reasons:
- Faster and More Reliable Rendering. Don't leave it up to your client's browser to decide what you meant when you made your syntax error.
- Interoperability with Compliant Browsers. Although a web page may look right in your testing browser, you need to remember that there are lots of different user agents: other browsers, mobile devices, and screen readers, just to name a few.
- Accessibility. Valid HTML code enables you to be confident that your page will be accessible to people with disabilities, such as the blind.
- Search Engine Optimization. Web sites with valid HTML syntax rank higher in search engines like Google.
- Future Proofing. The W3C specification will not be made backwards-incompatible, so writing valid HTML syntax ensures that your page will work well into the future.
- More Professional. No seasoned web developer will publish a page with accidental syntax errors.
The industry standard tool for HTML and CSS syntax checking is the W3C Validator. You should ALWAYS validate your code before completing your project! The Validator gives very helpful feedback to help you find and fix syntax errors.
For more information on why it is important to validate, see the W3C's recommendation.
But why don't…
As you play around with the validator, you may have discovered that household name sites like Google and Yahoo do not pass the validator. This is a deliberate act on the part of these web sites because of the following reasons:
- Download Speed. Sometimes, but not always, valid code adds bytes to the file size. Sites that serve tens of thousands of requests per second are highly concerned with the increased file size.
- Interoperability with Non-Compliant Browsers. Very old browsers like Netscape Navigator and Internet Explorer 5 do not respond the way that modern browsers do to the same markup.
However, do not take these as reasons to not validate your own code. The reasons listed in the previous section almost always outweigh the counterpoints in this section.