The road to HTMHell is paved with semantics — Vadim Makeev

Skip to main content
HTML semantics is a nice idea, but does it really make a difference? There’s a huge gap between HTML spec’s good intentions and what browsers and screen readers are willing to implement. Writing semantic markup only because the good spec is a spec, and it is good, and it’s a spec is not the worst approach you can take, but it might lead you to HTMHell.
Like most people involved in front-end, I started my journey into Web development with HTML. It was simple enough, close to a natural language, and easy to use: you type some tags, save a text file, and reload the browser to see the result. And it would almost never fail if I made a mistake!
Back then, I considered HTML a simple set of visual building blocks. It was too late for purely visual <font> elements (the CSS has replaced them), but the general idea stayed pretty much the same: if you wrap your text into <h1>, it becomes big and bold, if you have two <td> cells in a row, that’s your two-column layout. Easy! I learned tags to be able to achieve certain styles and behaviors. Remember <marquee>?
That was just the beginning: soon, I needed calendars, popups, icons, etc. It turned out I had to code them myself! And so I did, mainly using divs, spans, and some CSS. Back in the mid-2000s, there weren’t any particular “logical” tags or functional widgets, only the ones you’d find on a typical text editor panel.
But at some point, a trend called “web standards” emerged: it suggested to stop using HTML as a set of visual blocks and start thinking about the meaning of the content and wrapping it into appropriate tags: <table> only for tabular data, not layout; <blockquote> only for quotes, not indentation, etc. The people bringing the web standards gospel were convincing enough, so I joined the movement.
Following the trend, we started studying the HTML 4 spec to learn the proper meaning of all those tags we’ve already known and many new ones we’ve never heard about. Suddenly, we’ve discovered semantics in HTML, not just visual building blocks.
Why? Because we started paying attention to the spec, and it was semantically correct to do so. Every decision we make would have to be checked to determine whether it’s semantic enough. And how would we do that? By reading the spec like it’s a holy book that gives you answers in challenging moments of your life. On top of that, there was the HTML Validator’s seal of approval.
But then came the Cambrian explosion that changed everything: HTML 5.
Just after the failed promise of XHTML, HTML 5 brought us new hope. Many new elements were added based on existing naming conventions to pave the cow paths. The new spec has challenged browsers for years ahead, from supporting the new parsing algorithm to default styles and accessibility mappings.
For the Web standards believers of the old spec, the new one was just a promised land:
There was even a logo for semantics in the HTML 5’s design!
Apart from extending the list of functional building blocks, the spec added several semantic elements that didn’t even come with any styling, just meaning. But not only that! Some old, purely visual elements were lucky enough not to be deprecated but redefined. For example, <b> and <i> became cool again, though no one could explain the use cases, apart from rather vague taxonomy and emphasis ones and… naming ships. You think I’m kidding? Check the spec!
Don’t get me wrong, I think HTML 5 significantly advanced the Web, but it has also detached us from reality even further. Especially the idea of an outline algorithm and multiple nested <h1> elements that would change the level based on nesting. It was never implemented by any browser but existed in the spec for a long, long time until finally removed in 2022.
⚠️ Please don’t use the code above. It’s wrong and harmful.
Personally, I’ve wasted too many hours arguing about the difference between <article> and <section> for purely theoretical reasons instead of focusing on good user experience.
Although the spec would provide examples, it primarily focused on marking up content, not UI. Even examples themselves were often purely theoretical with a kind of usage that would be semantically correct, not always practically useful. There’s another whole story about the difference between the W3C and WHATWG spec versions, but the W3C’s examples were usually better.
I’ve seen a lot of weird stuff and did it myself, too. People would often look at the HTML spec as a dictionary, looking up a word in the list of elements for an idea they had in mind. Try to read the following examples through the eyes of a beginner, giving a shallow look at the spec. They totally make sense!
I haven’t seen the <slot> element used on a casino website to mark up a slot machine, but maybe only because I’m not into gambling. But the rest of the examples are real.
At the same time, a lot of people would read the spec carefully and use <footer>, <header>, <main>, and other semantic elements properly. But the reason for that won’t be any different: they would also aim for semantically correct markup only because the spec says so. And if it does, the smartest of us would think it should be good for users, search engines, etc. Right?
It turned out that the spec could be wrong, and semantically correct markup wouldn’t guarantee good practical results.
I don’t blame people who gave up on following the spec altogether and became cynical enough to use <i> for icons instead of naming damn ships. Fortunately, I didn’t go this way. I found another reason to keep caring about markup: user experience and accessibility.
Unlike many other languages, HTML is a user-facing one. It means that our decisions directly affect users.
Fortunately, it doesn’t matter how we format our markup, but our selection of elements matters a lot. So when I hear “this markup is semantic,” it often means that it’s correct according to the spec but not exactly good for actual users. Even though both can be true at the same tim