Semantics is a tool with future potential

Smashing magazine has kicked off an interesting discussion about semantics in HTML. It started with a post entitled ‘Our Pointless Pursuit of Semantic Value’. In a rather confrontation tone this post ripped apart many of the commonly held ‘arguments’ for creating semantic code.

Despite the tone it made some good points. On occasion I have expressed concern about the level of obsession some have with code being semantic. It is often used as a weapon to criticise others and the way they code, rather than for any legitimate reason.

However, in this case I find myself agreeing with Jeremy Keith’s (partial) rebuttal. Although an obsession with semantics is unhealthy we need to be careful not to swing too far in the opposite direction. Semantics does have value here and now. However, for me what is more important is the potential it has for the future.

As Jeremy says at the end of his post:

The specification is still being put together and our collective voice matters.

By having this discussion now and by working out how semantics operate in the real world, we will hopefully establish a standard for future applications. While now semantic code is only sparsely used it has the potential to improve accessibility, data retrieval and user experience. If we simply dismiss semantics as pointless then this potential will never be realised.

  • The funny thing is that very little people seem to see semantics for what they really are: future-proof code. Imagine that in some far future we have to convert all of our html to some new format. Would you rather have it written according to *some* semantic principle? Or would you rather have tagsoup?

    Even if the code doesn’t really add any machine-readable value or screenreader-value in the foreseeable future, it is simply more human-readable. And more human-readable code makes it so much more flexible to process afterwards. It’s all about continuity, really.

  • Semantics are important in that they really allow another developer to come into your code and see what’s going on. I can’t tell you how many times I’ve had to look at someone else’s code and tried to decipher what #ijfodisjf went to. 

    And I agree with Xavier, it’s about future proofing.

  • I strongly agree with Amber, I have to work with some really bad code on a regular basis and often get to the stage if I see another nested block of divs I’m going to shoot someone!
    That being said, I do think there are times you can throw semantics out the window – for things such as rapid prototyping, but this code should never enter a production environment. “Should” being a big key word there…
    I blogged about this also recently: