Importance of validating markup

Perfectly valid markup seems to have become less important recently. There has been increased adoption of techniques like ARIA and RDFa that offer benefits not possible when perfectly validating against traditional doctypes. These benefits include increased accessibility for internet applications and additional semantic information for content like product listings and reviews.

Also, certain levels of invalid markup usually display just fine because of the forgiving nature of web browsers—especially older browsers.

So, why validate?

• Debugging
  When a layout is broken, the first step that should be taken is to make sure the markup is well-formed. Incorrectly nested HTML is a common cause of broken layouts.
• Valid HTML is more likely to be future-proof
  An invalid page that looks fine in one browser now may not look fine in other browsers or upcoming browsers. This is one way the users see a new browser as “breaking the web” when the “breaking” is actually done by the site developers not using forward-compatible markup.
• Easier maintenance by adhering to standard rules
  When previous, existing, and future developers are all working from the same list of valid elements, there is much less chance of confusion about weird vendor-specific or non-standard code.

(See also: http://validator.w3.org/docs/why.html)

Valid does not always mean good

This markup, while technically valid, is not semantic:

<div style="font-size: 140%; font-style: bold; color: #444;">My Heading</div>
<div>
	First paragraph<br />
	<br />
	Second paragraph
</div>

This markup is both valid and semantic, making it superior to the previous example:

<h1>My Heading</h1>
<p>First paragraph</p>
<p>Second paragraph</p>

Valid markup is not always possible

Aside from markup not under a developer’s control (3rd party providers, plugins, etc), some of the newer web development initiatives and techniques have outpaced the standards bodies and use new elements and attributes that do not exist in current DTDs.

• HTML5 is being used today, but solid validation is difficult with a markup language that is still in progress.
• RDFa is being used today, but with a custom Document Type Definition (http://www.w3.org/TR/rdfa-syntax/DTD/xhtml-rdfa-1.dtd). It will not validate using one of the more common XHTML/HTML doctypes.
• ARIA (Web Accessibility Initiative’s Accessible Rich Internet Applications specification) is being used today without a DTD

  “Adding ARIA roles and attributes will not validate with HTML 4.01 or XHTML 1.0, but that’s okay, as ARIA is adding important information to specifications that were written a long time ago. Work is underway defining a DTD that can be used with modular XML, such as XHTML 1.1.”
  http://dev.opera.com/articles/view/introduction-to-wai-aria/

Certain invalid attributes are OK

With the development of new techniques like RDFa and ARIA, there are new attributes being “unofficially” added to existing elements to provide additional semantics or accessibility hooks to documents.

When RDFa is used with a non-RDFa DTD, the document becomes invalid, but will still be fine for SEO, page layout, and cross browser compatibility.

As long as you know what invalid attributes you’re using and the benefits they provide, it may be more worthwhile to have a document that does not validate to existing DTDs because you’re providing additional accessibility or semantic information.

While sloppy coding is no excuse for invalid markup, I believe it’s important to balance the needs of your site’s users with the perceived need to have a perfectly valid page. What do you think?

Michael Herring - Senior Web Developer — Since 2000, Michael has built and designed websites with an emphasis on W3C standards-compliance, accessibility, user-friendliness and cross-platform compatibility. Michael is a member of the Guild of Accessible Web Designers.