Colin Cochrane

Software Developer based in Victoria, BC specializing in C#, PowerShell, Web Development and DevOps.

What A Doctype Really Says About Your Markup

I have combed through thousands upon thousands of client's HTML documents since I began working in web development, and even more in my career as an SEO.  Much of this time is spent fixing invalid markup, shaving off unneeded code, and generally doing what the original developer should have done in the first place.  One thing that I quickly realized was that a disturbingly large majority of the sites I came across that were created by "professional" developers and firms seem to have absolutely no idea what a Doctype really is.  This is especially true when I see these developers slapping an XHTML Doctype on their pages, somehow thinking that since it is newer it will make them (the developers) look better.  As a developer who has actually taken the time to pore through the W3C specifications for the different revisions of HTML and XHTML, I find that practice rather irritating. 

That being said, as a developer who actually knows the difference between the various doctypes it is easy to spot markup from lazy and/or ignorant developers.  I should clarify that I don't expect all markup out there to pass the W3C validator 100%, nor do I expect perfect seperation of markup and structure.  However, when you place that doctype declaration at the top of your document, you are essentially saying "these are the rules that this document is going to abide by", and when those rules are obviously ignored I believe that says a lot about the developer who created the page.

Those tell-tale signs are easy to spot.  Self-closing ("/>") elements under an HTML doctype, or lack thereof in an XHTML document.  Capitalized elements and attributes in an XHTML document (xml is case-sensitive remember!).  Undefined elements such as <font> which has a cockroach-like ability of staying around, or attributes that aren't defined for the element they are declared on.  All indicators that the developer doesn't really understand the language they are working with.

HTML really isn't that complicated.  Someone who had never seen a piece of code in their life could pick it up within a week and have a working knowledge of the language.  Unfortunately that seems to be the average professional understanding of it as well, because it is apparantly too much to expect someone who makes a living using a markup language to take a few hours and actually learn how to use it properly.