One of the discussions that arises from time to time in web development circles is that of validating your code. Some will insist your pages need to validate 100% and others will tell you it’s not even worth checking as long as your pages work. Will people care if your pages don’t validate? Will search engines care? How important is code validation?
What Does Validation Mean?
Validating your code is simply comparing it to W3C standards. It’s no different than comparing a sentence you write to the rules of grammar for the language you wrote it in. In fact the grammar analogy is a good one to keep in mind when you think of validating your code.
Much as different languages have different rules of grammar, the code you use can have different rules depending on the doctype you use. Your doctype is setting the language you’re using and code that’s valid under one doctype may not be valid using another.
For example
<p>This is a sentence
validates under html 4.01 transitional or html5 where the closing tag is not required, but not under xhtml 1.0 transitional where the closing tag is required.
I’ve included some screenshots at the bottom of this post to show the full code I used to check under each doctype. You can click any of the 3 images for a larger and readable image.
Note that I also left off the period after “This is a sentence” above, which violates the rules of grammar, but likely doesn’t cause any problems in communication.
How to Validate Your Code
Since validation is comparing your code to W3C standards I think the best way to validate your code is using the W3C validation tools.
If you click the links above it’ll look like they go to the same page, but I assure you they’re different. Click the More Options link to see on each page to see.
There are plenty of browser extensions that will test the page you’re viewing in the W3C validators.
HTML Tidy is another option for validating pages, though it may not offer the exact same results as the W3C validator. One advantage of HTML Tidy is using an extension you can check your pages directly in the browser without having to visit one of the validators.
Why You Should Validate Your Code?
Ultimately validation is simply a tool to help you code better.
The reality is as long as your site and pages display like they’re supposed to your visitors aren’t going to care whether or not the code behind your site is 100% valid. Browsers won’t care much either as they’ll typically render much invalid code perfectly fine.
The only people likely to care or even know how to check are fellow web developers. Most of them won’t care either. Some might, though most probably won’t. Still there are good reasons to validate your code.
The W3C offers 5 reasons for why you should validate your code.
- Validation can be used as a debugging tool – Validators tell you where you have errors in your code. If your page isn’t displaying as expected a validator might very well point you to the cause. Also invalid code that may display fine in one document may cause show stopping errors in another because of the code around it.
- Validation can help future proof your work – Browsers are built with standards in mind. Pages coded to web standards today will work with browsers built tomorrow. Hacks used to get something working may not.
- Validation can be a great learning tool – Fixing validation errors will teach you a lot about how to best code a web page. It will help you get through the learning curve quicker. I speak from experience.
- Validation makes maintenance easier – Standards are widely accepted by the development community. If your site uses valid code another developer should have no problem maintaining the site. Untangling hacks on the other hand is never fun.
- Validation is a sign of professionalism – Getting the small details right even when no one else notices or cares is a sign of professionalism.
Those aren’t the only reasons though. Valid code is more accessible as it’s compliant with standards. It should work across more browsers and devices making it more usable and accessible. Different browsers may treat invalid code differently and sometimes in unexpected ways.
Some will probably tell you that valid code will help your pages rank better. I’m going to tell you those people are wrong. Other than show stopping errors (which validation can help you find) search engines really don’t care much about your code. The home pages of Google (35), Yahoo (167), and Bing (14) all have validation errors.
However all things being equal I would think valid code better for search engines than invalid code. Let’s face it no one can really list every potential show stopping error where search engines are concerned. The safest thing to do in that case is fix all your errors or as many as realistically possible.
Sometimes when you run a page through a validator the list of errors seems so large that it looks like it will take days to fix them. Often a few simple errors are leading to many more. For example forgetting to close a tag early in your document could end up resulting in dozens, even hundreds of errors. Fix those one or two errors and watch as many more errors are gone when you revalidate the page.
Acceptable Validation Errors
Ideally all your pages would be 100% valid, though it’s not practical or even desirable at times to achieve 100% validation.
Some code that’s commonly used just won’t validate. Vender specific prefixes such as -webkit and -moz will never validate by definition. That doesn’t mean you shouldn’t use those vendor specific prefixes.
Hacks for specific browsers (I’m looking at you Internet Explorer) also won’t validate, though it’s unlikely you’ll find a developer who’s never written a coding hack. Sometimes they’re all you have to get the page working right.
Validators will also issues warnings in addition to errors. 100% valid code means 0 errors, but it could include any number of warnings. Some of those warnings aren’t going to be things you’ll want to fix. Many tracking parameters you add to the end of a url will give a warning for example.
In the end you shouldn’t sweat it if your pages aren’t 100% valid. Some errors and many warnings are perfectly acceptable as part of a well-coded page.
Additional Resources
Below are a few articles I collected while putting this post together. They’ll offer similar and occasionally different reasons for why you should be validating your code.
- But it Doesn’t Validate
- Code Validation – Clean Code
- HTML and CSS Validation: Should You Validate Your Web Page?
- Code Validation
- Validating Your Code
My Own Validation Practices
A few years ago I worked to make sure every page I developed was 100% valid and I’d even work to reduce as many of the warnings as I could.
At the time I was learning how to code to the standards and validating pages is one of the better ways to learn. I’m sure I learned to code quicker because I consistently validate every page I developed.
I can’t say I was always good about continuing to check those pages unless the code changed significantly it was unlikely validation errors would suddenly show up.
Today I don’t work toward 100% validation as often as I used to for a few reasons. First I’m past that early learning stage and I’m a better judge of which errors are important to fix and which aren’t that big of a deal.
I also feel pretty confident that any page I develop at this point is going to come close to 100% validation. Maybe not 100%, but probably not all that far from it. Coda, the primary code editor I use is good about alerting me to some errors as I write the code and it completes tags for me as I start typing. I also pull more from a library of code that I know to be valid.
Another reason is that most sites I build end up on WordPress, which means the code I’m developing on top of is already valid. Most of the validation errors you’ll encounter with WordPress come from poorly coded plugins, which is where most of the validation errors on this site currently come from.
I do still validate. Mostly it’s when I’m first developing the template(s) that will later become the working web pages. That’s where I’ve found I’m more likely to make errors.
Summary
How important is it to validate your code? That depends on your perspective. It’s really never that important to make sure your pages are 100% valid, though at the same time if you work to make a few sites 100% valid you’ll find most of the sites you build after will have few if any errors other than the typo variety.
No one outside of the development community will ever care if you write valid code as long as the code works as intended and many inside the development community won’t care either.
Still I think validating your code is a good idea mainly for the reasons given by the W3C. It’ll make you a better coder, help you debug pages that aren’t working, help you and your fellow developers maintain your sites, and ensure your pages work across browsers and time.
You should also validate because you’re a professional who cares about your work. There will come a time when you have to let go of you work and hand it off to your client, but until that time don’t you want to build the best site you can build? Validation will help you get there.
Do you validate your code? Why or why not?
Download a free sample from my book, Design Fundamentals.
And here is what Matt Cutts has to say about Google not validating…
http://www.youtube.com/v/FPBACTS-tyg
That is a disgrace coming from Google. It’s like a professional car body / paint shop saying the paint finish on this repair is dull but most cars on the road have blemishes anyway!
That’s an older video isn’t it? I remember watching it awhile back, though it’s also possible I saw Matt Cutts answer the same to another question.
It makes sense why they don’t validate. To you and me those few extra bytes aren’t a big deal, but to Google they add up to a whole lot.
Good to know that what I’m saying here is consistent with what Matt said in the video.
There was no “xhtml 4.01 transitional” last time I checked. 😛
In my opinion it is just as important to validate, as it is to write using correct spelling and grammar. However it is much more important to use semantic coding ALONGSIDE a valid one. You can have valid coding, but still have it be one huge mess.
d’oh. Good catch. See what happens when I edit things late on a Sunday night. 🙂
Thanks. I’ll fix the post. I did mean xhtml 1.0
I do usually write valid code, but the most imporatnt thing is to write semantic code. BTW: how do you use input autocomplete in xhtml?
Semantic code is important. I’ve never used input autocomplete so I’m not quite sure.
Eg. I want to use my own suggester for search-inputs on my site, but firefox uses its internal autocomplete so mine is hidden under this one. I have to use autocomplete=”false”, which is invalid in xhtml.
Oh I understand. I wouldn’t worry about trying to validate that one line of code. In the end it’s the visitor’s experience that’s most important.
If there’s a way to validate, great, but if not it’s ok to use some invalid code to create a better experience.
I think it’s important to validate your HTML am there’s no excuse for it to not be validated. CSS browser hacks are naughty and shouldn’t be used, but CSS3 and vendor prefixes are another story and something I use all the time. Theres a diff between bad coding practices, hacks, and advanced browser code 🙂
Thanks for stopping by Amber.
I’m with you. I do know I’ve slipped a little in validating at times lately, though I’m pretty sure most code I write will validate. I spent so much time with checking in the past that the validators influence how I write code today.
Agree too about the hacks. The progressive stuff does mean we can’t fully validate our code, but that’s no reason we can’t validate the parts that aren’t trying to push the envelope.
Validating really can help eliminate bad coding practices, which does allow us to experiment more.
I like all my code to validate too, except I make exceptions for embeds and widgets from other sites, like the “Tweet” button or the Facebook “Like” button. Those never validate, but whatever…
You don’t have much choice other than to make exceptions for 3rd party stuff you want to add, though I have at times not used something because it was so poorly coded.
One other thing I’d add to the exceptions list is when using progressive enhancement. Sometimes you want to use vendor specific code, which by definition won’t validate.
This is a great article for those who do not understand why it is so important!
This article shows 44 errors. Why the hell can’t it be valid while it’s about benefits of validation?
1. I assume you didn’t take the time to actually read the post, as I make it clear I don’t think you need to make your web pages 100% valid. There are acceptable validation errors such as using vendor prefixes. Yes, there are benefits to validating your code, but not necessarily to being 100% valid.
2. If you took the time to look through the errors to see where they come from you’ll find most are coming from things like plugins, or twitter buttons, where the code isn’t anything I can or should change.
3. If you understand how the validators work you’d know that often fixing one error leads to many more going away. I’d guess those 44 errors you see probably relate to less than a half dozen lines of code.
4. If you run the pages here that are outside of the blog section, where I have less plugins working and less social buttons, you’ll find very few validation errors.
@ Steven Bradley:
1. “It doesn’t need to validate if it works…” Nice attitude. BTW, I’ve read the article, but using invalid code sounds like:”Google doesn’t need to validate because most of the websites are invalid”. Surely, plugins from invalid sites will make your code invalid.
2.I suppose that most of errors of this web come from Google, and you are right that I didn’t check where they come from. Apologises for this one.
3. I agree with this point. Usually, fixing one error reveals more of them. Naturally, the website code error is not one line problem but the concept error. Why not chase and stamp them out?
4. Alright, social networks, Google plugins (or any invalid site plugins) will usually increase the number of errors but improve SEO.
Note: Why the hell can’t the internet be flawless, valid and nice?
I didn’t mean any insult, it’s just – how often do you see valid website? And why it can’t happen more often
Just so you know when you have a comment with “why the hell can’t…” it doesn’t exactly come across as friendly and it puts whoever you directed it to on the defensive. It will generally lead to something equally unfriendly in reply. My apologies if I came across harsh in my reply, but that’s where it came from.
I do understand your point, but you have to remember what validation is. It’s not some kind of absolute moral imperative we all have to follow 100% of the time or we become bad coders. I do think people should take the time to write valid code for the reasons I pointed out in the post. I know it helped me learn to code better.
But there are certainly times where it’s perfectly fine to write code that’s not valid. Vendor prefixes are an obvious case. It’s not like they’re going to break anything or cause problems for any browser. You could write perfectly valid code and add a few extras for those browsers capable and you’re page is not longer 100% valid.
Where exactly did I say that? I don’t think I’ve said anything to suggest that’s my attitude. I’m saying I think people should take the time to validate, but I don’t think they need to stress if they have reasons to allow validation errors to remain their code.
It would be nice, but sadly we end up relying too much on code we don’t have any control over.
A few years ago I wanted to use some code from Google. I forget exactly what it was, but I’m thinking it was their custom search. It was when I first built this site and at that time (before all the plugins and social buttons) every page here was 100% valid. Google’s code wasn’t. I emailed them to ask if I could rewrite it to make it valid and they wouldn’t allow me to use it if I did. So it never went on the site.
Years later I realize it’s a trade off. How important is what you’re trying to achieve as compared to keeping 100% valid code? Is it worth having every line of code validate if it means providing a lesser experience for visitors to your site?
I’ve got scrolling=”no” on 95% of my pages. Adds up to many validation errors. Should I care?
I’d be more concerned that you’re using so many iframes. Why would you be using them on so many pages of your site?
If you do need them and want to disable scrolling, I’d sooner use CSS
iframe { overflow:hidden; }
or something similar.
Don’t be sloppy. Just fix your errors. In PHP or JavaScript you can’t miss a closing brace or a semicolon so why should HTML be any different. I blame the browsers because if the HTM is wrong they should show an error and not render the page. The only reason there is a debate about this is because some developers are lazy.
IMHO, validation your codes is important for serval reasons.
1. It shows you client that you care about what you do and therefore you earn their confidents in you to continue to hire you.
2. It shows that you are know what you are doing.
3. I always put the two validator links (html and css) on my site.
4. When you show your portfolio to the perspective clients, they will trust you more if your codes are error free.
(After all, would you want hire someone who’s résumé that is permeated with typo and grammatical errors?)
5. In todays world, any Jacka$$ who knows a few html or css call themselves a web developer. By showing your codes are properly written, it make you stand out against the John Doe next to you. You are more Likely to be hired.
6. And for yourself, it is a sense of pride and satisfaction, you can be proud of your work. 🙂
Very true
Another reason to check is when developing in JavaScript you sometimes accidentally have duplicate ID’s without realising it. W3C check highlights this immediately saving you time debugging. Also depending on your framework, some PHP errors are hidden inside HTML but not visible in the browser. Again W3C check will reveal that too. The
I have developed a JavaScript solution that shows a small button at the bottom of your page that calls W3C API and when clicked. The button either goes green or red with an error count. The error report is stored inside the browser console.
Just incluse the JavaScript file while running on your development platform. Willing to share if anyone is interested.
This is a great article for those who do not understand why it is so important! Thanks 🙂