Want truly semantic HTML? Maybe we should drop the strict tag names…
If HTML wanted to be truly semantic, to offer the most flexible and descriptive structure it can, it would ease back a little and absorb a bit more than just closing tags and proper tag nesting from XML: it would allow developers to create their own HTML elements, based on what their page requires…
Think about it: We all decided we hated <table>s for layout right? So we switched to <div>s. Lots and lots of <div>s. So many <div>s, in fact, that a word was created for this situation: Divitis. But what is a <div>, anyhow? So, now we have <section>s! Wow, so much better, right? We’ll soon have no <div>s at all, but rather <section>s here and <section>s there… And how long before someone coins the term Sectionitis (oops, too late, I already did!)?
At least <article> has some meaning, but what if your website doesn’t contain articles? What if it is a review site? Or recipes? Or poems? Why can’t your website be a series of <review> tags? Or <recipe> tags? Or <poem> tags?
Currently all modern browsers allow you to create any tag name you want (except IE, of course, but a small bit of JavaScript can even solve that). And the CSS is easy enough, just declare which of your custom elements should be block and which inline, and there isn’t much more to it than that!
Ah, semantics, you say! How can search engines and bots be expected to decide what all those different element names mean, right?
Do we really think so little of Google and Yahoo and Bing and AOL? In fact, it should be no issue at all for Bing, it is, after all a decision engine!
So, for real semantics, for a web that is truly scalable and will be ready for whatever we may dream-up down the road, let it grow! Let it become whatever it needs to become, whenever it needs to become it…
Thanks for listening, now how much do I owe you?
Atg