So far I've seen no value to HTML5 tags outside of content publishing ... which is a tiny portion of the web's use. There's no HTML5 support for eCommerce requiring devs to either use older tech (xhtml role= etc) or to fall back on meaningless divs with semi semantic but non standardised class names ... discuss

I was all for using html5 elements. Then i read the aformentioned book - which i linked to, and it was like a slap in the face. Those elements are a mess - there are a few tiny good points. But it's very much for content publishing as rob said. the whole nav, header, aside are a joke. Read the docs… they're all over the place as to how you should use them.

Also, if you style them, and then the user has JS disabled or you haven't included a shim - they wont be recognised in IE. The only way around that would be to don something like div.navigation > nav > ul > li etc. but then what is that really adding?

And for accesibility/screen readers etc. Aria Roles are much better supported than the html5 elements

Aaaand for the google. fuck them.

as much as I hate to see the bastardisation of accessibility technology, my personal view is that "role" is a much more powerful semantic selector. Especially if the standards bodies could agree on a set of roles (ala article, section, product, thumbnail, etc) that had some scope to them.

Hell it's already been adopted by JavaScript engines for precisely this purpose.

I think most web devs would agree that HTML5 (the markup aspects anyway) is half baked and that we're all doomed to another generation of shitty markup being manipulated in a million different ways to actually build web content and applications instead of simply publishing academic content which is the only use case even remotely satisfied by the new specification.

Roles are slowly creeping in that way: paciellogroup.com

Also for e-commerce - mircodata all the way!!

So it really does leave html5 elements in a difficult place.

Some of the new HTML5 elements were made by analyzing how people were already using HTML. Especially when an element didn't already exist for what they were doing

For example, A LOT of people were doing things like <div class="footer"> and <div class="foot"> to create footers so a <footer> element was added

Many of the other new elements were created for similarly

You don't have to use them, but if you want to use them, use them when it makes sense to use them (Ex: Use <footer> when you are actually making a footer)

A motivation for these was to add widely understood semantics to your markup. Sure you can add your own semantics by adding classes, IDs and combining existing elements but not everyone will necessarily know what you meant

Charles, I understand a lot of the additions. Elements like <header> & <footer> work well in the context of most sites as these are, as you correctly state, commonly used patterns.

My issue is more focussed on the in page content markup. Where almost every site has a footer, relatively few have articles and or sections / asides.

eCommerce is a perfect example of this and as a developer I have to choose between a mishmash of badly suited HTML5 elements or continuing with semantically classed or roled <div> elements which does rather render the addition of content based semantic markup to HTML5 null & void.

I suppose what I'm trying to say is that a lot of the new tags are useful, but that they're insufficient for the modern web.

Personally I feel that standardisation of these semantics is key to the future of web markup.

Either loosely via something like XHTML1.1 with modules and elements being defined by DTD, or by retrofitting an agreed set of standards into a completely flexible markup structure - via classes, roles, or microdata.

Heh turns out this is something of a hot topic: brucelawson.co.uk