Avoiding Superfluous HTML5

HTML5 (or rather, the continuing specification of HTML) is very, very good really great stuff. New elements, better semantic meaning to mark-up, more accessible interactivity - it's all leading to some very exciting times ahead, and with those times I hope that we'll start to see more and more amazingly well-crafted products in our digital lives sooner rather than later.

I've been working on a few projects recently that have utilised many of the new features of 'HTML5' (I'm going to refer to it as that, as it's the easiest way to refer to it) and although I am enjoying the ride, I have noticed that the HTML I write these days has got bigger.

Years ago, when I started learning how to code, one of the golden rules was to restrict the amount of superfluous markup you wrote. As well as keeping things tidy, it meant there was less to render by the browser, and as long as you could still achieve the layout and design you wanted then the less code, the more efficient the site, and the better the product was.

Recently I have been getting a little bit frustrated because I have felt I have needed to increase the amount of code to achieve the same results as when I was writing old-school HTML. I'll give you an example - in the old days I would create a navigation menu like so:

It's plain, simple, and the unordered list contains the links that the user will need to browse my site. These days I wrap this unordered list in the brand-new nav element, which semantically makes more sense:

So that's fine, I guess - it's not ideal as I've had to add a new element to what was previously there - but as it's just for one main functional element of the page, then that's ok, right?

Well no, not really - the problem is that I might have more than one group of links on my page that require other nav elements. This means for each one of these unordered lists of navigational links, I add the extra markup to achieve the same result.

The problem is that the extraneous code isn't just restricted to this example either…each new sectioning element can now have it's own h1 (which is excellent), as described on the fantastic Dive Into HTML5, but does that mean that each h1 also needs to be nested in its own header tag? This is where problems creep in, and things could easily start spiraling out of control. What was once a nice, clean document now gets riddled with repetitive extra code that actually, really isn't needed. By adding these things are we making the product better? Is it more semantic, or more machine-readable? And if so does that make the product better?

I would suggest that the header example above could be resolved using common sense really - no, every sectioning element doesn't need to have its own header - the h1 should suffice in many cases. Sometimes the header will be required, but not in every situation.

But back to the nav issue…

WHATWG describes the nav element as "a section of a page that links to other pages or to parts within the page: a section with navigation links".

You will almost always see more important groups of navigational links output as a list, within a ul tag. Looking at that link to WHATWG, you can see that the nav examples mostly contain unordered lists. If this is the case, perhaps we should see the development of a new HTML element or attribute - something along the lines of a navlist tag, or a type="list" to add to the nav tag. This way, we could revert to fewer elements on the page by writing something like the following:

or

Surely browsers could evolve to treat the content like a list of links in the same way as it would other lists, and we create leaner markup.

If measures like this start to be introduced into the specification then I feel that it will help the HTML5 standards continue to improve the quality of products we see day in, day out, on and offline. It'll be easier to create clean products with optimised code, which means everyone wins - the consumer gets to use the fastest-loading interfaces, and the construction of those interfaces can be more solid, and easier to manage too.

WHATWG / W3C - what do you think? I would love to hear what you have to say. HTML is always evolving, so if we can start introducing solutions to make our development lives better, that'd be great. Please!