HTML5, did you really mean that?

Having recently undertaken a major overhaul to our own website, a large part of which was aligning the code to HTML5 standards, we stumbled into a minefield of semantics.

Now don't get me wrong, we have no issue <ironic>"understanding"</ironic> headers and footers. We don't fall to pieces whenever we have to consider if a set of links represents a "major" navigational block.

But, where we are consistently having to stop and think is in the definition of articles and sections. What represents a valid article, where should a section stop and start etc etc. This blog isn't intended to help define these things (there are plenty of excellent resources out there already - see HTML5 Doctor or the Mozilla Development Network for instance), but rather as a discussion as to whether the specific semantic elements of HTML5 are worth the effort.

Why bother with semantics?

Naysayers will argue that the days of structured content on the web no longer exist, that XML and other structured specifications do a better job of handling semantics where they are really needed. They will also say that there is enough badly defined content around such that browsers, search engines and accessibility tools will always have to use alternative means to comprehend the content of web pages. Leave the complexity of understanding to the ultimate consumers of content - browsers, search engines and humans.

So just give up? Stick with what we have?

Is it really that bad?

As mentioned at the start of this blog, the majority of new semantic tags are relatively straightforward to implement without much forethought. The definitions of asides, header groups, sections and articles whilst not immediately intuitive start to fall into place the more you square up to them.

As professional web developers you are not likely to do a single HTML5 implementation in isolation. It may take you a couple of hours to become completely happy with the semantics of your first HTML5 site or even page - dependent on how fastidious you are. However, as every developer knows, the lessons learnt will be taken into every future site and, as such, it is simply not sensible to attribute all the effort taken in implementation to the first site you create. Instead you can divide that effort exponentially by each future site.

When viewed in this context, future proofing your site makes sense. Why not provide current and future browsers with the means to interpret your site more accurately.

Furthermore, whilst Google and other search engines may not rank your site more highly for a specific search term just because you are using semantic markup, it is irrefutable that they are more likely to be able to comprehend the scope and context of your content with correct semantics. In turn they are more able to correctly categorise your site and return your content in the appropriate searches. It is in your interest to make your content as understandable as possible.

Just do it?

All the normal rules of web development apply. Nothing needs to change. As long as you are cross browser testing and have taken some time to understand the semantics of HTML5 then there is no reason not to use them now.

Minor issues with old browsers not recognising semantic tags can be overcome by using JavaScript shims (to provide consistent DOM structures) and avoiding the use of semantic structures directly in styling content.

The implementation of HTML5 tags should be considered part of the same trend as progressive enhancement. As long as you can relatively easily negate side effects for older browsers, why not make your site infinitely more understandable for whatever device is reading it?