Introduction: Semantic HTML

HTML 5 introduced a number of new DOM elements that made meaningful semantic HTML a real possibility. Semantic markup gives developers, designers, and content creators a common technical language. It also delivers inherent accessibility without the need for ARIA tags.

In my experience, however, a combination of the somewhat difficult to decipher W3C standards documentation, browser support quirks, and the slow transition from HTML 4 standards and techniques makes the proper use of semantic markup ambiguous at best. A quick search of Stack Overflow confirms that I am not alone in thinking this.

The Problem with Semantic Elements

Web developers and designers were handed a new set of specialized tools but the instruction manual for building a website was never updated, so to speak. Elements such as SECTIONs sparked debates over what exactly is a SECTION and maybe more importantly, what isn’t a SECTION. It introduced new ambiguity to old friends such as the H1, which no longer was simply the most important—or, God forbid, simply the largest—header on the page, but could now be the first heading in an ARTICLE, which might itself contain SECTIONs, and while we’re at it, why wouldn’t the first heading in a SECTION be an H1…and so on.

Time and effort were wasted as developers and designers argue and ruminate over the appropriate element to use in a given situation rather than just building the page. Some, including myself, became frustrated enough with the analysis paralysis to ditch semantic HTML and go back to that perennial favorite, the DIV. Why?

Too often, the answer to questions of which element is the right element to use are answered with, “Yes”, rather than something definitive. The result is inconsistency, as even the same developers choose different elements between similar situations in different websites because they never arrive at a definitive answer. In the effort to produce quality, semantic markup, we produce inconsistent, inefficient nonsense.

There’s a better way.

The Solution: Standards for Semantic Markup

I’m going to give you a mantra. This is the mantra of the markup method I’m proposing, and it is based on my work as a developer over a decade. It is heavily influenced by the wisdom of my peers, by my brief time with Python, and by maintaining my own old code. Here it is:

It is better to be consistently wrong than inconsistently right.

When you’re trying to build something, it’s better to have a method that needs to be changed than to have no method at all and accidentally get things right from time to time. You can change the method. You know why it isn’t working, you can isolate the needed change, and when you can make it you can evaluate the results.

So, thinking about a process, when faced with ambiguity, or with a decision that doesn’t have an obvious right answer, it’s better by far to pick one option and stick with it than to reevaluate each time. Your odds of success over the long haul are better, and you can eliminate wrong answers or cement right ones into your process. Most of all, you save time and reduce stress.

In that vein, I want to present a modest proposal for a set of semantic markup standards. In the next few posts, I’m going to outline a set of standards I use for semantic HTML markup. Stay tuned!