Validation simply means ensuring through a test program that your web site is written in valid code, or error free if you prefer. You call up a program, usually the W3C Validator (1 page at a time) or the WDG Validator (Multiple pages) and point it at a or multiple pages and you tell it to validate your code. It then says your good to go or you have "X"-many errors that need to be fixed. It tells you how many, where they are and what the error is with a cryptic hint as to what the problem is. You then fix it, test again and when it is error free you publish the web site or post a critique request.
You want to do this because:
- You should be professional and trying to create error free pages for your customers.
Errors do cause coding problems and a problem you have visually may be tied to a simple code error much earlier in the source code. You can often have 20 errors that vanish when you correct one thing earlier in the page. A gap in the visual elements of a page you can not figure out may be connected by a error in your code 200 lines before. The error in itself is not visible, but it effects elements later in the design.
- We must design for "User Agents," anything that can be used by the user to visit a web page, browsers are just one section of user agents, others are screen readers, cell phones, PDAs and Gaming Consoles like PSP or Nintendo Wii. Browsers may ignore mistakes in the code, but we can never know what software on what user agent may completely break due to an error. Error free code will work best across user agents.
- You should want your web site to work across user agnets, and not just to days user agents but tomorrows as well. Many misguided web designers thought designing for IE6 was enough as not enough people use Firefox, now more people do and IE7 actually supports standards so they discovered their designs for IE6 broke in IE7. We want to design for today and tomorrow.
You may also wish to read:
OK, we get allot of requests here for critiques. Far to often it is new members with their first posts... then they do not understand what we are telling them. One case in point is validation.
Web sites can be critiqued in three forms
- Code - the hard rules of creating web sites, the code behind them, rules to follow and test against..
- Usability/Accessibility - if the site can be used successfully by users and those with disabilities, again there are rules and ways of doing things you can test against.
- Look & Feel - whether or not a web site looks good/professional. This is a matter of personal taste with little true guidelines to test against, what one person likes others may hate and more indifferent. It is not clear cut.
So back to the code, we get a request to critique it and we validate it and it shows dozens of silly errors that should not be there and should have been easily repaired before publishing or asking for a review, that is why we say to validate first as we are tired of masses of errors. But many reply "what do you mean validation?"
If you stop to think about it, it is clear that we mean test your code to see if it is valid. The problem lies in two forms:
- Designers who do not think validation is needed as long as IE shows the site the way they want it and like to think web design is like the Wild West, with no rules and anyone can do anything they like.
- Beginners who do not know better and think web design is like the Wild West, with no rules and anyone can do anything they like.
Well it is not. Web design is a structured way of creativity and has rules and guidelines. You can write novels or poems... but you still have to use correct grammar and spelling right? Web design is no different, only we use other languages, rather than English or German with their different rules and spellings, we use (X)HTML and CSS and co. with their rules and grammar. Just as you would not publish a novel with poor grammar or spelling, you should not publish web sites built with poor grammar in HTML.
This is where validation comes in. It is about testing your code for errors and bad habits, missing tags and deprecated tags. Validating your code is about ensuring that your code is valid and error free, that it is written per norms and standards set forth and that the code is written the way it is supposed to be.
These rules are set forth by the World Wide Web Consortium (W3C) who defined what the tags in say HTML do and it is these standards and definitions of tags that tell the browser what to do with that tag when it finds it. Standards state the a tag that looks like
is a paragraph and so space shall be added between these blocks of text. It also states that in HTML a closing tag may be left out, but should be added and that in XHTML closing tags MUST be used.
In your HTML you are supposed to start the page with a tag that starts with DOCTYPE, this defines what language is being tested against. Just like you have to tell a spell or grammar checker that you are checking German and not English, you must tell the validator that you are testing HTML or XHTML so it knows if a closing
This is where the two groups above miss the point, they look at the web site in IE and it looks like the way they want it so all is fine. Well I could give my published novel to a drunk or a pot head and they would likely not care either about grammar or spelling. But should I not be publishing a quality product?
Hence validation is very important, it finds those stupid little errors that we all make. The IE argument is a cop out by lazy people (if they know validation and choose not to, not if you do not know it.) who only want to do the minimal work and call it finished. IE was developed to be idiot proof and assumes you do not know what you are doing. It is programed to more or less note that there are errors but to ignore them as you do not know what you are doing and just act like the error was not there.
For the most part all other browsers now expect you to know what you are doing and do not ignore mistakes, they show what you wrote. IE may be the majority browser, but it in not the only browser and is not guaranteed to always be the majority browser. So is it logical to design just for it?
That is the point, not all the users use IE even if it is the majority browser. Even more important, browsers are not even the only issue anymore. Browsers are just a sub-section of the larger term "User Agent", specifically graphic browsers may be the majority of user agents, but we also now have to design for Cell Phones, PDAs, screen readers, text browsers and even game consoles like Nintendo's Wii and PlayStation Portable. User Agents are anything a user can choose or need to use to access the internet and that will one day include refrigerators to oder groceries and maybe coffee machines.
Will IE ignore validation mistakes? Yes for the most part. Will a cell phone? You do not know do you. Well the fact is there are some PDAs running windows that have IE, but for the most part mobile devices run software developed by that company, there is no telling what a mistake will do to a web site. Opera has a mobile version that is good, Firefox is being developed for Mobile as well and their is a 3rd party browser that is good... but the vast majority of mobile units do not use these products so we cannot know what will break our site in the proprietary software used.
That leads us back to validation. If we create a site that is error free and uses standards... then you can feel more secure that your web site will work over all possible user agents than a poorly written site full of errors.
Lastly, like in programming, errors do not always show themselves where they lay. More often they appear quite far away from where the mistake was made so can be a bugger to find. One small unimportant mistake above can aggravate another mistake farther below in the code and snowball into a major issue. Correct that one small mistake at the beginning and "POOF!" all the others disappear.
But all the good arguments aside, should you not simply take pride in your work and make it error free for the sake of doing it right?