But it Doesn’t Validate

I have a small pet peeve that I’m going to share with you. On the nights when I finish up a new CSS3 tutorial for Nettuts+ — typically while listening to my favorite Biebster songs — I click publish, and then wait to see how long it’ll take before a reader leaves a comment containing the phrase, “But it doesn’t validate.”

Thanks for the Input!

Here’s the thing about validation: it’s a tool. Nothing more; nothing less; just a tool.

So here’s the thing about validation: it’s a tool. Nothing more; nothing less; just a tool. At first glance, though, it makes sense, doesn’t it? We equate validation with best practices, much like JavaScript and JSLint. Along that line of thinking, why wouldn’t we want a perfect 100% score? Well that’s the thing: we do; however, problems ensue when the score takes precedence over our own logic.

Validating your Designs

To test your markup and style sheets, you can visit:

• W3C CSS Validator
• W3C Markup Validation

Alternatively, you can install the helpful Firefox add-on, Web Developer, which, among other things, offers the handy-dandy “Validate HTML” and “Validate CSS” links, as well as the option to validate even your local files.

At this point, a report will be generated, which lists any errors that the validator comes across. But herein lies the rub.

Is Validation Irrelevant?

Absolutely not. I’d imagine that, particularly for those who are just breaking into this industry, the phrase, “websites don’t need to pass validation” confuses the heck out of them.

“Validation is your early-warning system about introducing bugs into your pages that can manifest in interesting and hard-to-determine ways. When a browser encounters invalid HTML, it has to take an educated guess as to what you meant to do—and different browsers can come up with different answers.”
– Opera Developer Community

That said, the final score is, in fact, irrelevant.

Remember the days when we (or at least some of us) pasted those validation buttons to the footer of our websites? How funny; who were they for? The site visitors? Haha; I hope not! But here’s the thing: back then, validation wasn’t really a standard. Nope; in fact, if you even bothered to validate your HTML and CSS, you were a standards-embracing, cutting edge dude! Sometimes, it’s easy to forget that web standards is a relatively new concept.

Validate Before you Ask

Years ago, when I used to participate in CSS forums, it never failed: every time a new member requested help on a strange layout issue, our first response was typically something along the lines of, “Your website doesn’t validate. Fix the errors, and then come back to us if there are still issues.” Many times, odd layout issues are the result of unclosed elements, like a div. In these cases, validation can be of tremendous help.

So what changed? Is validation no longer necessary? Does HTML5 allow us to write terrible mark-up without a second thought? Is the new HTML5 doctype magic-infused? Not at all. Validation is a helpful tool that allows us to pinpoint missed closed tags, extra semicolons, etc. That said, the final score is, in fact, irrelevant. It’s not a magic number – that, at 100%, contacts The Architect behind the scenes, and instructs him to apply bonus points to your website. This score serves no higher purpose than to provide you with feedback. It neither contributes to accessibility, nor points out best-practices. In fact, the validator can be misleading, as it signals errors that aren’t errors, by any stretch of the imagination. The HTML4 validator has quickly become out-dated, but luckily the W3C has a new HTML5 validator (still experimental) that’s much improved.

Now, keep in mind that well-formed markup can boost SEO; however, there’s no specific correlation between SEO and a validation score.

HTML5 standardizes many of the features that some browsers have supported for years, such as custom attributes (via the data- prefix), and ARIA attributes, which fail the W3C’s HTML4 validator.

When testing new designs, be sure to check the experimental HTML5 validator option. With this option set, you can use the supported CSS3 properties, custom data- attributes, and more.

How About 75% or Higher?

Never, ever, ever compromise the use of the latest CSS3 techniques and selectors for the sake of validation.

What if we strive for at least a 75% score? I understand the thinking, as I thought that way too at one point; though, again, it’s irrelevant. When validating, your primary focus should be on determining where you’ve made mistakes. Validation isn’t a game, and, while it might be fun to test your skills to determine how high you can get your score, always keep in mind: it doesn’t matter. And never, ever, ever compromise the use of the latest doctype, CSS3 techniques and selectors for the sake of validation.

The dirty secret of browsers is that they never perform HTML validation against a DTD. The doctype you put at the top of the document switches the parser into a particular mode of operation, but no operations involve downloading the doctype and verifying that the code matches. What does this mean? It means that a basic syntax parser handles HTML, with exceptions specified for self-closing tags and block vs. inline elements (and I’m sure other situations as well).
– Nicholas Zakas

What Doesn’t Validate

Dependent upon the options you specify before checking your designs (HTML4 vs. HTML5), the validator will scream like a baby when it comes across:

• Browser hacks
• Vendor-prefixes
• Custom attributes
• Genuine errors, such as unclosed elements
• ARIA roles

Ahh, browser hacks… should you use them? The answer to that question has been debated to death, and it certainly exceeds the scope of this tutorial; however, keep in mind that, for instance, usage of the IE6-underscore-hack will fail validation.

For this reason, many designers prefer to use non-breaking techniques instead.

So:

/* Fails validation */
#myElement {
  _position: relative; /* targets only IE6 */
}

Becomes:

/* Passes validation */
* html #myElement {
   position: relative; /* targets IE6 */
}

The reason behind this line of thinking is, what if, in the future, say, Internet Explorer 10 will also render properties that are prefixed with an underscore? In cases such as that, your IE6-only (so you thought) styling will also be applied to IE10 and beyond, presumably. Now, the truth of the matter is that this would never happen, as it’d break a large number of websites. That said, this method of browser-targeting is indeed a hack. Except in smaller or rare cases, it’s better to use a conditional stylesheet, or a form of feature detection to target specific browsers.

Vendor Prefixes

While we can all agree that applying multiple vendor prefixes to properties, all for the sake of achieving, say, rounded corners, is incredibly tedious, you should thank your lucky stars that the browser vendors experimented with these technologies before they were officially recommended.

Had webkit not experimented with CSS gradients, and had Mozilla not improved upon their suggested syntax, gradients would not be as widely supported in the current generation of modern browsers as they are today. You see, browsers have a huge hand in shaping the future of the web.

.box {
  background: #666;
  background: -moz-linear-gradient(top, black, white);
  background: - webkit-gradient(linear, left top, left bottom, from(black), to(white));
  background: linear-gradient(top, black, white);
}   

With all that said, the use of these vendor prefixes will cause your style sheets to fail validation. But that’s okay; don’t let that worry you one bit.

Learn the rules so you know how to break them properly.

Unfortunately, even now, many designers elect to use, in our example above, images to create gradients — if only for the purpose of pushing their validation score back to 100%. If you fall into this camp: you’re doing it wrong.

Use Validation…

• To test for unclosed HTML elements
• To check for typos
• To ensure that you haven’t omitted any semicolons
• For peace of mind

---

Validation is Not…

• A game. Don’t waste time achieving a 100% score, when you know exactly what you’re doing. However, do use it to point out your mistakes.
• An all-encompassing checker. While it does test for errors, it does not point out bad practices, accessibility issues, etc.
• To be used as an excuse for not embracing the latest CSS3 techniques. The longer you say to yourself, “I’ll use this in a few years…” the further you’ll fall behind.

---

Conclusion

If you only take one thing from this article, remember that validation is simply a tool. As soon as you compromise your own logic and techniques for the sake of appeasing a validator and achieving a meaningless score, it ceases to be a tool. That said, use it, and use it often!