The other day in the Foundation Github issues tracker, a user stated that Foundation CSS doesn't validate. We are using vendor prefixes and attributes like zoom in some areas that the validator is choking on. Our framework is tested in almost every perceivable browser, and battle-tested daily by our 20-plus team of engineers and designers, and yet we still don't meet validation, even though it renders well in most every browser. This made us wonder if validation is still relevant?
Although HTML and CSS validation icons no longer appear at the bottom of every modern-facing website, there is still a general sentiment that validation is necessary. Can we satisfy standards compliance without the need for validation, or, alternatively, is there a better approach to validation? We say yes.
Validation Was Once Useful
Validation was created, in part, to drum up interest for standards compliance after newfangled browsers like Netscape and Internet Explorer started extending the capabilities of HTML in the early 1990s. They added infuriating tags such as marquee and the notorious blink. Many rebuffed these additions as going beyond the original intent of the language, to provide document structure, not influence stylistic choices.
The W3C was formed in 1994 to develop and maintain open standards to counteract what the original creators of the Web saw as a cruel and indecent assault on everything they'd created. Three years later, the stylesheet was introduced in the HTML4 specification along with the W3C Validator service. The service was designed to help people generate syntactically accurate markup in both HTML and CSS. It worked. In the early 2000s validation symbolized professionalism among web developers. Everyone had the badges on their page. Everyone was drinking the validation kool-aid.
Validation Is No Longer Useful
Over the past five or so years our web development workflows have begun to standardize and become more powerful. We are now using better development tools that catch mistakes earlier. Editing software and IDE's now have linting — a method of validating syntax — built in, or have third party extensions that do the same. Proper syntax highlighting in editors can quickly catch a missing div or quotation mark. Front-end and backend frameworks, like Rails and Angular, give structure to our code, dividing it into, smaller, easier to maintain chunks.
All of these tools catch syntax mistakes earlier in the development process than what is typical for online validation. Web validation is usually an afterthought for many, as it doesn't easily integrate into the developer's workflow. So by the time a developer realizes they need to validate their code, it is riddled with issues, making it much more difficult to debug.
A web validator shouldn't be used as a debugging tool. Editors like Sublime make debugging much easier. The built-in developer tools in the browsers have gotten extremely sophisticated and will now notify you if there are any parse errors while processing your HTML, CSS or JavaScript.
Validation is also frequently done against live code, which opens up other problems. Live code is typically compressed, which causes issues with the validator's parser. More and more websites are being generated dynamically, which means that the source code may contain little to no markup on page load, rendering the validator useless.
Validation Isn't Accurate
No browser conforms 100% to W3C standards, which web validators use. This means that when you validate your web page, it doesn't guarantee that it will actually render accurately in the browser. These validators also mark vendor-specific properties (-moz-opacity, -webkit-transform) as invalid. Even though these features are supported, you should still use new, non-standard, functionality. It helps push the web forward. And means that your site won't be 100% valid, which, at the end of the day, shouldn't get your feathers in a ruffle.
The parsers also don't take into account graceful degradation. Many of these non-standard extensions to HTML or CSS are just ignored in browsers that don't support them. However, the validator will still mark it as an error in your syntax, even though your page may be valid as far as the browser is concerned.
Not a Bad Thing, But...
Validation isn't a bad thing — it's just unnecessary. You should be able to catch syntax issues continuously through your site's development. Web validators make this difficult because they are designed as a one-off tool. By the time you've gotten far enough that you realize you need to validate your code, you're already knee deep unclosed p tags, missing alt attributes, and block level elements nested within inline elements.
Validation doesn't complete the picture. Your site may be 100% valid according to the W3C but still have inconsistent indentation, unnecessarily complex or non-semantic markup, and be hell to maintain.
Validation helped spur interest in standards among developers. It helped get your website working in browsers that were less powerful and less forgiving, where a small typo could cause the browser to crash. Today browsers are smarter, our development process allows us to catch errors in our code earlier on, and powerful revisioning tools like git can help us trace down the mistakes. It can also be a valuable education tool early on, but as you become more experienced, validation should be done in your editor and more frequently, not in some external web tool that is disjointed from your development environment.