Here are my thoughts on this subject, with some tips on using the CSS validator, if you decide that you’re still concerned about validation to some degree.
Validation is Just a Guide
This is the most important point here. You should not view validation (even markup validation) as the holy grail of good code. The validator should just be a useful guide that helps you correct any actual errors that you’ve missed.
I rarely validate my stylesheets. I will validate markup when a project is finished, but I’ll almost never validate my stylesheets. I know that CSS hacks and vendor prefixes will cause all sorts of errors and warnings to be spit out, so for that reason, I rarely bother with it.
If my CSS does what I want it to, then to me it’s valid. But occasionally I will check large stylesheets for actual errors. It’s just not something I do as habitually as markup validation.
Use the Validator’s Options
Of course, if you must validate your CSS (because you want to show your client or you have a boss who doesn’t understand that validation is of minimal importance), then you have some ways to get around some of the errors produced by the validator.
Many people don’t seem to realize this but both the HTML and CSS validators on W3C have a “more options” section that can be opened to allow you to tell the validator how to handle certain aspects of your code:
When you open this section of options, here’s what you see:
So using these options you can do three things:
- Change the “Profile” to “CSS Level 3″
- Change the “Warnings” to “No warnings” or “Most important”
- Change the “Vendor extensions” to “Warnings”
Because of those last two options, you’ll see zero warnings or errors for vendor prefixed CSS — because you’ve told the validator not to list any warnings.
As an example, this site shows 100+ errors and about 100 warnings using the default validation options (see what I mean about validation?), but only about 50 errors and zero warnings using custom options.
It’s Still Problematic
Unfortunately, because the validator still doesn’t recognize many CSS3 properties even without the vendor prefixes, you’ll still get many errors (like my site does). And it will never accept hacks as valid, so those too will show up as errors.
I believe if you were to leave out the standard properties that don’t work without prefixes (like transitions, for example), then you could minimize the number of errors even more. But I don’t think that’s good practice, because when those properties do become standards, you’ll want those in there.
Link Directly to the CSS3 Validator
Finally, if you need to do the cheesy “this page is valid” thing using a W3C badge, you can link to the CSS3 validator directly with a URL, like this:
<a href="http://jigsaw.w3.org/css-validator/check/referer?profile=css3">Valid CSS</a>
So the live link would be something like this. Also, as shown with a couple of the links I used above, you can add options to the URL, to ensure the links are minimal. Just choose the options you want, then copy and paste the URL as is.
Conclusion: It’s Just a Means, Not an End
Validation is highly overrated, and many experienced developers understand this. If your boss or client is demanding the green screen for both HTML and CSS validation, then you need to kindly point them to this or other articles that clearly show that validation is not necessarily the desired end result.
If your code works, and is as cross-browser compatible as you desire, then your page is “valid”. Use the validator to track real errors that you might have missed, and don’t expect validation to solve all your development problems.