That is not to say that some validation errors should not be overlooked, but the validation itself should still take place. For example, Facebook and Twitter buttons generally will not xhtml validate because they use Open Graph. So in general, it does not pay to beat your self to death to get them to validate. I say in general because you can do it, but the xhtml page validation errors will not interfere with the web browser rendering the page correctly. If they work, then you can safely ignore the errors, but this should be a conscious decision, made from knowledge and not from hope. i.e. I hope my pages work despite the errors.

The html/xhtml validator verifies syntax, not context, so Alexander’s argument is weak. Comparing it to a language translator is almost ludicrous. Comparing it to the front end of a compiler would be much more appropriate. We may not think of a complier as a validator, but think about it… A compiler goes through the source code and checks for the syntax before trying to “translate” it into assembly language and finally compiling it into machine language. If the syntax (code) is written incorrectly, the complier will indicate the issues. This is synonymous to what the validators do. They basically check the web page html/xhtml syntax. If an “if” statement does not have an “endif”, the compiler indicates an error. If the “head” tag does not have an “end head” tag, the validator will indicate an error. Of course there is differences, but the comparison makes far more sense then to compare the validator with the screen language translator.

The article compares the CSS validator, which is the closets comparison made. Still there is a significant difference. The CSS can be more easily checked by humans, as they look at the web page to see if everything looks in place. Humans do a very poor job of reading html/xhtml. Sure if there is a significant error and that particular browser cannot handle it by switching to quirks mode, the human can tell there is an issue. However if a table does not render right because of a CSS issue, the programmer knows exactly where to go to fix it. If the same table does not render right because of an html/xhtml error, it may be caused by incorrect html/xhtml syntax dozens, or even 100s of lines before the table.

The screen reader is NOT a validator, either, but I supposed it could be used to check a web page, but lets face it… Who uses a screen reader to check their web pages, but does not use a validator?

Alexander made sever good points, and had the title been something like, “Life after the validator” and was written appropriately, the article would have been much more useful.

Humans are very high prone to error. Statistically, humans are 3 sigma. On average they/we make about 45,000 errors in every 1 million opportunities to make those errors. Systems and machines are needed to help us get to 6 sigma (3.4 errors/million opportunities). In fairness to this article, validators are created by humans and humans make many mistakes, so the end result is that validators do indeed make mistakes, but lest face it, when it comes to html/xhtml, I would much rather have 3.4 errors per million, then 45,000. Wouldn’t you?

The validators that I’ve written, WebLight and Tart, have always allowed people to categorize and filter messages so they can ignore messages related to conscious choices they’ve made and find unexpected problems more easily.

But, as long as you know why and have a good reason for choosing not to adhere to a standard there should no problem.

Saying that, writing html that passes the w3c validator is easy and in general good practice. I rarely see a good reason to break the recommendations.

But that is just one small part of writing decent markup.