Valid (X)HTML Markup in 6 Steps, Like Correct Spelling

The last hour, I’ve been busy trying to get my site’s markup valid. The frontpage now validates, but there’s till work to be done to the other pages. So after reading Dennis Forbes’ post, I noticed I’ve been running for the past year or so with invalid markup and nobody ever pointed that out. One might rightfully wonder: does it actually matter?

Personally, I think it does and I feel I need to fix the remaining problems as soon as possible. I might even go from the “XHTML transitional” to the “strict” doctype, just for kicks (and other advantages). Not only will good XHTML give a tidy impression to visitors, but it is also one of the most reliable ways to make sure your site looks the same on all browsers and operating systems. And if you go for XHTML instead of HTML is will also be able to use neat stuff like XSL.

In order to get my pages in order (still a work in progress), there were actually only 6 errors that keep repeating. Because I’m running WordPress, it isn’t always easy to find the source. It could be a plugin that inserts some HTML somewhere or part of the header, or was it in the sidebar?

  1. If you copy from webpages, make sure you are copying code pieces without layout. The build in TinyMCE editor is great, but if you copy a piece of code from a webpage, it sometimes pickes up HTML codes that you can’t see, but that will mess up your pages. For instance, I had problems with HTML comments (two dashes were copied as one long).
  2. Close your tags. This is the most basic rule of them all if you are creating XHTML, but it is very important. It’s easy to write
    instead of
    , but only the last one is correct.
  3. Put alt tags on images. And don’t just put in some random piece of text. Try to make it descriptive, because blind people need them to fully enjoy your website. As do people with slow connections (they are still out there)
  4. Encode special characters. This is again a XHTML requirement. Probably the most popular special character you’ll run across is the ampersand (&), you should write it as “&” Don’t worry about your blog posts, the build in editor will take care of it. This is just for the templates.
  5. Uppercase and lowercase matter. Tag names should all be lower case, so <META …> is not the same as <meta …> Obviously the actual text can be any case you wish.
  6. If you give id’s to div’s (or other elements), they should be unique. This is not only a requirements, but if you plan on adding JavaScript to your site, you will save yourself a lot of headaches if you keep this in mind from the start.

If you want to test your own site, you can do so, entirely free of charge, at the W3C Markup Validation Service. Good luck with those tweaks.

Image credit.