Feeling the need for Validation?

Do you ever feel the need for validation? You may not, but there’s a good chance your web sites pages do. I know that there are people out there that do not know what it means to validate a page, so this not just for those folks, but also for the people who think it may not be worth the effort.

First, what is page validation? It’s a simple thing really – it’s just the process of verifying that the code in your page meets a specific standard, without errors. When your page validates properly, browsers are able to load it faster, simply because they don’t have to work to determine how to render the page. When a page is not valid code, the browser is thrown into “quirks” mode – which basically means it’s having to figure out how to deal with what code is there and how to render as best as possible.

Valid code is a good thing, as there are specific rules for rendering a page based on the actual web standards. If the page code is valid, then it truly does load faster AND when you need to make changes later, there is less chance of unpredictable behavior. Although it's not a perfect solution, this also helps your site render consistently between different browsers.

So, why don’t people validate all their documents? It takes some time… but it doesn’t have to take all that long if you plan for it from the start. The best way to go about it is to start validating when you are building the framework for a sites page. Most people start out building a single page that will be the template for an entire site, so before you start loading that template page up with a whole lot of code, start validating it so it’s easier to keep it validating as you add more code.

The first important step in validation is to decide what DOCTYPE you are going to work with. The DOCTYPE defines what coding standard you want to adhere to. These days, likely the best way to go is XHTML. Because it’s based on XML, it’s more easily portable to different devices such as mobile computing devices. If your page does NOT have a DOCTYPE, you need to put one in. If you want more information on DOCTYPEs, you can read to your hearts content.

Part of deciding what DOCTYPE to go with is deciding if you will be willing to adhere to the standard fully or not. This is the difference between a DOCTYPE using STRICT versus TRANSITIONAL. STRICT means just that – the rules are strict and MUST be followed to pass validation. Really though… it’s not that difficult. TRANSITIONAL allows you to have some older style code while ‘transitioning’ to STRICT, and still pass validation.

So how do we do this validation thing? It’s as simple as going to a website. The website happens to be The W3C Markup Validation Service. This is a free tool provided by World Wide Web Consortium. There are three ways to start the validation.

1) Simply point the tool to your page – ‘Validate by URI’
2) Upload your document – ‘Validate by File Upload’
3) Copy/paste your code – ‘Validate by Direct Input’

Each method accomplishes the same thing. You get a report back indicating either success or failure. If you successfully pass validation, you’ve done well! If you have not passed validation yet, then a few adjustments will be needed. The only challenge here is properly reading the output from the validator when there are errors and warnings from the page. Much of the output is fairly straight forward, but there can be times when it gets a little crazy looking. This is usually the case when you have not closed a tag properly – such as missing the closing tag for a paragraph or div. In this case, the validators parser will get to the end of the document to finally determine that yes, a tag is missing. Along the way though, it may output many other errors, simply because the parser wasn’t sure what was going on right there. If you read all the warnings and errors though, you will get hints about what the issue could be – like many times it will give you things like “this may be caused by a tag not being closed properly”. Nice hint.

For this reason, I find it easier to read through ALL the errors first. Then, I identify the easy ones that are simple no brainers. Yes… that was my typo there… the <budy> tag does not exist… After I fix the easy ones, I revalidate to see what changed. If there are no other easy fixes, then I read through the errors and warnings, but I start working on fixing them from the bottom up. This is because anything else is often a missed closing tag or something to that effect. You’ll often find that doing it this way will allow you to fix one thing and a LOT of errors will simply go away. The parser suddenly got happy with you!

The key at this stage is to fix just one or two things at a time, then revalidate. Since one real error can create the appearance of many other errors, you don't want to waste your time on fixing something that was caused by the parser being confused someplace else in your document.

Since it can be frustrating to look at a HUGE list of errors all at once, this is why I suggest you validate early and often. Anytime you make changes to your pages, validate them to be sure. I was recently handed a template document from somebody who wanted some dynamic code put in the page. The template contained over 900 validation errors. When I couldn’t get something to display just they way they wanted, we decided to give up since neither one of us wanted to try and validate what was there…

One thing to remember is that 100% validated pages are a great goal, but sometimes this is not a reasonable expectation. Affiliate code is one good reason you may not get there. Those nice banners and links that help pay the bills… they don’t always provide you with valid code. Got somebody else’s video code on your site, like your AEBN videos? Those are the types of things that you want on your site, but may not deliver you perfectly valid code. It’s a balance. Get what you can control as good as you can, then put those types of things in and be happy with where you are.

Next up… CSS validation…