The other day someone on another post asked a question about validating your stylesheets. This person is concerned with the fact that the validator views vendor prefixes as errors.
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.
I almost never validate anything I build lately, be it HTML or CSS – as against to the past. Back then I also considered validation and a 100% valid code as the holy grail, but as you state rightly, as long as everything looks and acts the way I want – and especially in every browser – the code mustn’t be too bad. But maybe I will use this post as an opportunity to at least validate my HTML in the future.
Great article. And like you mentioned, I just validate my style sheets to figure out general errors if any.
There is something satisfying about seeing your code “Validated” though.. I will ignore the stylesheet validation but I still love to get that pat on the back for getting the HTML right. I am a bit OCD so for me I get an even bigger kick out of getting validation on a “strict” XHTML than I do “transitional”… I know I am a bit strange but.. it takes all types I suppose.
I once had a boss (supposedly the “webmaster”) who would never allow anything to go live unless it 100% validated. No amount of explanation about vendor prefixes and the like would sway him. In the end, I resorted to letting him check with a validator and then updating it later. Needless to say I no longer work there.
Validators are there to make sure you don’t have any errors in your code, just because your code looks right in a browser doesn’t mean it’s going to look good on all devices and one of the main ways to ensure it will is valid code…
brent
Validators mean absolutely nothing to be honest. Sure if you need them as a tool to check for errors then use them but that’s not their objective, the objective of validators is to validate so in theory if your code doesn’t validate then its wrong BUT since the validators are VERY FAR from being realistic they’re worthless, I should also point out that in order to have a validator actually mean something it has to be built by an entity which has some authority and W3C WANTS to have the authority but in reality browser devs still do whatever the hell they want so people developing websites are always f***ed and have to come up with tons of fixes and vendor prefixes in their CSS in order to have things work. So all in all, people making websites are the only ones doing things right (the good ones anyway) because browser devs keep messing up and W3C is slow has no authority.
Great article, Thanks Again. I just validate my stylesheets to figure out general errors!
It is i nice article.
I always do validate both the HTML and CSS.
I believe that it is a necessary step that should be done.
It is important to find out if your markup is correct and fulfill the required standards.
If it is cross-browser compatible or not, looks good or not; is another history.
This is an interesting article in that it sheds light on one perspective of validation. I’m in college right now studying web design. Currently the class I’m taking insists on valid code using the W3C validator tool. Now, and this is important I believe, is that CSS 3 code such as the border-radius and text-shadow properties do not yet validate. So if I were to follow the example set forth by my school, I may as well disregard using CSS 3
And that’s exactly why many schools need to update the way they teach web design.
Don’t listen to your school’s standards: Browsers and users don’t care about “valid” code. In my opinion, the code is “valid” as long as it does what you want it to do.
I disagree. When people are first learning, it’s important to start off with good habits. It’s a decent safety net and learning tool. Once you know you’re way around, then you can start to doing what you think is best.
Thank you so much, I finally validated my css3 and it was valid xD so was my xhtml ;)
I never use validity before reading this article because I don’t had the idea why it does necessary. I need change the menu day by day so I’ve to change all my pages, it is hard. Is it possible that I make change in one place and all pages menu updated.
Never really bothered validating my CSS.
All works fine.