I have a strong belief in HTML that means something. HTML can be viewed as a vessel for delivering content; however, HTML- and especially more so with HTML5- defines a mechanism with which we can not only deliver content, but describe what the content is. This is what is called semantic markup; it is not an obtuse buzzword, but rather an important design methodology.

It is easy to fall into one of two pitfalls: "just get the thing done" and "write the minimal amount of code possible". One is caused by a developer who does not understand (or does not care to understand) the importance of markup; one is caused by a developer who is foregoing semantics in favor of misguided "efficiency" gains, whether personally (writing less code) or for the server (sending less code.) However, in the long run, this serves only as a barrier to maintainance and usability.

§

There was a large movement towards using div tags for markup, moving away from monolithic table-based markup. This was done in order to reduce the coupling between styles and content, making changes easier, content easier to consume, and code easier to maintain. It also allowed designs to be fluid, flowing around the content rather than constraining content into boxes. Instead of shuffling table cells, we now only have to switch out a class, or in extreme examples, the order of a few div containers in order to update a design. This was an important step forward in the evolution of modern web development. However, while progressive, divs were found to be meaningless. No reasonable heirarchy of data could be constructed; a side-bar was virtually indistinguishable from main content, a site's heading didn't stand out except through primitive h# tags.

HTML5 then gave us elements such as header, footer, time, nav, section, article, aside, and more; new properties and attributes such as input types and input placeholders; and more (which you can read about in the W3C Specs and at the excellent html5 doctor. html5- true html5, not "marketing buzzword" html5- has a rich and beautiful focus on semantic markup that allows for clear consumption and maintainance of content.

It is not only html5 that has semantic meaning, though; looking back through html4 and earlier iterations gives us examples of hr for splitting content sections, table for data, form for form, a for links. Many of these base tags are, however, ignored or forgotten in return for generic div zealotry. Links are built with div tags and javascript onclick events, 'ajax' forms are built using generic elements, and images are simply div tags with background images. We have begun to lose meaning not only to the browsers that consume our content, but also to ourselves, as developers. With semantic elements, one can view an article tag and understand where it begins and ends without following a chain of generic div tags; with a form, one can understand that its contained inputs are part of a collection to be submitted, rather than a random cluster of inputs, any of which might be sent out to a server; with an a, we know it goes somewhere, and with a button, we know it performs an action.

Semantically relevant code is both code and documentation. With consistency, we can reduce the number of one-off styles and the amount of javascript logic we have to write. Instead of coupling our styles to our code, as we may have coupled our content to tables in the past, let us define code that uses elements that can describe what the content is. Style a time element instead of a time class on a span; write javascript based on buttons instead of divs coerced into acting like buttons.

Thus we may reduce our code and provide meaning to our content, while providing a normalized experience to machines who read our content, be they search engines, browsers, or screen readers.

This post is dedicated to my colleague, Tony DeSylva, for whom I wrote this.