10 Reasons Why Your Code Won’t Validate (and How to Fix it)

W3C validation isn’t very forgiving at times, but it allows you to see errors that are generated by your markup. Lots of errors and warnings thrown by the validator are a good indicator that your XHTML isn’t in very good shape, and might not look consistent across different browsers. Here are 10 sneaky validation problems that trip developers up, and how to avoid them.

Before we get started, here are a few good practices to remember when using the W3C validator.

  • Don’t sweat the warnings – If the validator says that you have 12 errors and 83 warnings, just worry about the errors for now.
  • Knock off errors one at a time – Work your way straight down the list, top to bottom, knocking off errors one at a time. The HTML is read by the browsers from top to bottom, so the errors show the same way.
  • Re-validate the code after each fix – Oftentimes one error can be causing multiple errors down the page. Alternately, some “fixes” can cause more errors, if done improperly. Re-validating after each attempt can ensure that you’re completely fixing the problem.

With those basic tips out of the way, let’s have a look at some of the reasons why your markup isn’t validating.

1. An unclosed div tag

One of the most common reasons why layouts don’t validate. It never ceases to amaze how often this is the culprit for a funky layout. Unclosed div tags are one of the most common layout mistakes, and also one of the hardest to diagnose. The validator doesn’t always point to the proper unclosed div tag, so it’s not always easy to find the needle in the haystack.

2. A rogue embed tag

In the early 90′s, browsers like Microsoft and Netscape started recognizing unique font declarations which were never standardized. Unfortunately this means that the W3C validator still doesn’t recognize some important HTML tags like ‘embed’, even though they’re widely used to this day. If you’re really looking to get that strict DOCTYPE validation, you’ll have to ditch the embed.

If you really want to have valid markup and embedded media, try using the Flash Satay method.

3. Improper DOCTYPE declaration

A frequent mistake is either not declaring a DOCTYPE, or declaring the wrong DOCTYPE at the head of the document. As a general rule of thumb, Strict DOCTYPE is the highest validation to shoot for. Strict validation means that you are webpages have the best shot at displaying properly across all browsers. Here’s what a Strict declaration looks like:

4. Trailing slash

If your site isn’t properly validating, then there is a good chance that the reason is a missing trailing slash somewhere in your code. It’s very easy to overlook something like a trailing slash, especially in elements like image tags. For example:


This won’t validate against a strict DOCTYPE. Add a ‘/’ before the img tag ends in every case to solve the issue.

5. Align

You’ll be fine using the tag “align” if your DOCTYPE is set to Transitional, but if you’ve taken the higher road and chosen a Strict validation, you’ll see errors. Align is another depreciated tag that shouldn’t be used anymore in markup. Instead of align, try using float or text-align to shift the element.

6. JavaScript

If you’ve declared a Strict DOCTYPE, you’ll need to wrap CDATA tags around your JavaScript code. This aspect of validation has tripped up many a developer, as sites tend to use in-line JavaScript for things like ads and tracking scripts. If you have to include JavaScript, just add these tags before and after:


7. Images always need ‘alt’ attributes

If you haven’t noticed by now, images are a major potential stumbling block for good validation. Aside from trailing slashes, they also require alt tags that describe images, i.e. alt=”Scary vampire picture”.

Search engines are also relying on this alt tag to help identify images on the page, so it’s good practice to add the alt tags anyway.

8. Unknown entities

Entities are another small pitfall that tend to stand in the way of validation. Instead of using things like the “&” symbol, it’s a good idea to use properly encoded characters. Here’s an entire list of properly encoded character entities for use in XHTML markup.

9. Bad nesting

Nesting is when you have elements inside of elements, like so:

Sweet!

It’s quite easy to get mixed up, and mix is the order of nested elements. For example, starting the strong tag before the div tag, but closing the div tag first. This may not alter the look of the layout, but it will definitely keep your markup from validating.

10. No ‘title’ tag

While it may seem like an obvious problem, many developers (including myself), still leave off a ‘title’ tag in the ‘head’ section every now and again. If you see the error “missing a required sub-element of HEAD”, then you know that you’re missing a title tag.

If you found this post useful, please vote for it on Digg.

Add Comment

Discussion 111 Comments

Comment Page 2 of 2 1 2
  1. aravind says:

    agree.. validation is essential.. but still many of the RTE’s coming with various Content Management Systems doesn’t follow any standards. It makes almost all the CMS powered websites I developed non-standard!

  2. thetooth says:

    i still find it amazing how many people don’t have this basic nolage and how these people manage to ever make web pages :D

  3. Snookerman says:

    4. Trailing slash – you only need that if you are using XHTML and you would only use XHTML if you don’t want to support IE. If you want IE users to be able to see your site, you would use HTML and then you wouldn’t need any trailing slashes.

    9. Bad nesting – the “faulty” example you used is actually not bad nesting at all.

    Also, there are many other more important issues that you didn’t bring up..

  4. Martyn says:

    The one that always gets me is an empty alt tag, but I tend to always validate throughout the coding process.

  5. Kevin says:

    I had the doctype problem and didn’t realize what was wrong for 6 months before. I must have erased it accidentally out of my index page (which would not center align), but all other page in the site had it.

    It was by chance that I discovered it one day, but I vowed to never make that mistake again. Luckily for me none of the site’s users ever noticed.

    Great article!

  6. iPad says:

    Thanks! great tut!

  7. christian says:

    The websites are implementing increasingly complex libraries that make it difficult to have a validated code. Thanks for the recommendations.

  8. Jennie Lyon says:

    Hi,
    My blog http://www.sweetgreens.blogspot.com‘s feed won’t validate? When I click on the feed button on ie7.0 I get a DTD error? Any ideas?

  9. Adam says:

    I tend to validate against XHTML 1.0 transitional mostly, as I like to be able to use target=”_blank” for some links (pdfs, external links etc).

    Don’t really want to have to use a bulky JavaScript option to get around it.

    Shame 1.0 Strict doesn’t support this.

    • Martin says:

      It can be validated if you use this: onclick=”window.open(this.href,’_blank’);return false;” instead of target=”_blank” in your href tag.

  10. danreb says:

    Very nice and interesting articles
    Thanks.

  11. Blacksnipe says:

    If you have a Mac, and you want to get rid of the entities mistake, simply download the Dashboard Widget from the Apple website. Here’s the link: http://www.apple.com/downloads/dashboard/developer/htmlentitycharacterlookup.html

  12. Dave says:

    Or maybe your code doesn’t validate because you don’t know how to write it? Gah. I hate stupid coders. Web coding is NOT THAT F*CKING DIFFICULT. I rebuilt an entire website in Firefox 3, using pure CSS. It is 100% standards-compliant, AND renders almost pixel-perfect in IE6, with no hacks whatsoever. It really isn’t as hard as you people make it out to be. So stop whining and learn how to code.

    • Greg says:

      “almost” pixel-perfect isn’t good enough for many people.

      On the other hand, I’m sick of IE6 workarounds and will never enslave myself to them again (like the majority of the web dev community since IE8 appeared, it seems). Ugly transparencies? Float issues? Don’t care anymore.

  13. JK says:

    hi,
    Most of you that read this will blow me off is my guess…but someone might actually answer…I am not a web-designer, but a new business owner and have a website. I did the test and got many errors on my site trying to validate…many in #’s of more than 50…I pay for a site thru a good size company in Boston. Obviously if I try to do any of these fixes, maybe I could learn it..my guess is probably not…most likely will screw it up…anyone want to contact me and offer some advice for what my next move should be..which direction I should go???If no one can offer anything, then I’d be surprised…but it’s not easy to find good help and after reading all these answers…perhaps someone might help another by telling me if my current web designers are screwing my business…or not……Any takers?>
    JK

  14. Hugo says:

    the CDATA thing should not apply for every self-respecting XHTMLdev, put ALL of your javascript in an external file. (Best in 1 file to reduce the number of HTTP-requests)

  15. Rishi says:

    Can anybody please help me….
    if (this.value == ”) {
    var errorMessage = ‘Required’;
    $(”) /*Error Generated*/
    .addClass(‘error-message’)
    .text(errorMessage)
    .appendTo($parent);
    };
    I am getting error in this part which is inside the script tag. It says ‘span’ is not permitted here. I am adding a span to a paragraph dynamically. Any help would be appreciated.

    • Rishi says:

      if (this.value == ”) {
      var errorMessage = ‘Required’;
      $(”)
      .addClass(‘error-message’)
      .text(errorMessage)
      .appendTo($parent);
      };

  16. It’s sometimes frustrating to validate a page when everything seems ok. But then again who can beat the validator?

  17. Nuruzzaman Sheikh says:

    Does Dreamweaver validator do the same thing as W3C validator?

  18. Craig says:

    Excellent list for good coding practice, Thanks for the reminders!

  19. Thank you, excellent article on fixing validation and the three tips are very important, Thank you! LT

  20. Amanda Smit says:

    Can be so frustrating when a page won’t validate, so these 10 reasons on how to fix it are so helpful, Thank you for sharing these.

  21. Vipin says:

    Thanks, “6.JavaScript”, explanation saved my life.

  22. Ivan says:

    These are great, thanks for the tips Glen! Was wondering… what about google adsense validating errors? The W3C validator doesn’t recognize symbols like: & and other symbols in the script and validator thinks them for entities. There’s a friend of mine who manages a blog, where he have 30 errors only because he added adsense.

  23. Hi there,

    at the risk of angering other commentors if they are still reading this – I am NOT a good coder though learning fast. I find it very hard to go from Validating my code and finding the errors with WC3 Validation to actually findimng where these lines are in my wordpress site.

    I’m clicking around in the various modules like an idiot and trying to ‘code-walk’ my way to the offending bit of code. Some I find but most I end up giving up. Is there an easier way to pinpoint the offending bits of code through the WordPress interface (as that is after all the true source from which the resulting code is generated),

    oh and thanks for a great post – I agree with all of these common faults and solutions and am starting to learn what is good and not so good practice via a few runs through the W3C validator – I just can’t easily find where in my code to apply it.

    p.s. I don’t think the errors on my site are actually from me, I think they’re from plug-ins on my site which update various files…

    thanks,
    Alan

Comment Page 2 of 2 1 2

Add a Comment

To add a code snippet to your comment, please wrap your code like so: <pre name="code" class="html">YOUR CODE</pre>. You can replace the class name with "js," "css," "sql," or "php." If there are any "<" or ">" within your code, please search and replace them with: &lt; and &gt; respectively.