I have recently started working on a new design for my blog. Initially the idea was to just refresh the look and make the layout more flexible (the current über minimalistic layout doesn’t lend itself easily to adding more types of content, like blogroll for example), but as the design phase was wrapping up and I started thinking about the code I realized that this was a great opportunity to do something I wanted to do with it for a long time — convert it to HTML5. Below I go over the new redesign and some of the ideas and reasons behind the things that I do and the way I do them.
So what does “convert to HTML5” mean exactly? HTML5 defines many new technologies for the web — local storage, web workers, semantic elements, (the famous) video element, WebGL, SVG and many more. This is however a simple blog, no information is stored, all potential videos are usually youtube or vimeo embeds, and there’s certainly nothing going on that would require the use of web workers. So for my purposes HTML5 means semantic elements, i.e. tags like
<aside> and a few more.
In terms of the code itself the change is easy — all you do is replace some
<div>‘s with some of these tags and you’re done. Of course things are never so simple. The W3C has very clearly defined roles for these tags and if I want to write proper HTML5 code I need to use these tags according to their roles. This meant I needed to go over my site and figure out what’s what. More specifically, what’s an
<article>, what’s a
<section>, should I use a
<footer> or an
<aside>, and so on.
The new blog layout is a fairly standard affair — main content column on the left, sidebar on the right, a header of course, and a very simple footer. Here is the design for the front page.
So with this layout in mind I started breaking it up into separate elements and thinking about how they’re structure, how they relate to each other, and ultimately what are their roles. When I had a clear picture of that I was able to figure out which semantic elements should be used for which sections of the layout. Starting with the header of course…
This one is easy. The
<header> element is defined by W3C as:
[The] element [that] represents a group of introductory or navigational aids
So of course the main header, with the navigation menu, is going to be wrapped in
<header> tag, but that’s not all, as every article can (and should) have a
<header> as well. That means that any post, whether it’s displayed in full (like on the single post page), or as an excerpt is also going to use <header>. Even the various sections of the sidebar are going to use
<header> for their titles. In the case of posts, in addition to the titles I’m also including some meta information in the
<header>, specifically the category and the published date.
This what the W3C says about the
The nav element represents a section of a page that links to other pages or to parts within the page: a section with navigation links.
Not all groups of links on a page need to be in a nav element — only sections that consist of major navigation blocks are appropriate for the nav element. In particular, it is common for footers to have a short list of links to various pages of a site, such as the terms of service, the home page, and a copyright page. The footer element alone is sufficient for such cases, without a nav element.
It’s clear that the menu should definitely use the
<nav> element, but in my case I also decided that the pagination links at the bottom of the page would use it. It makes sense after all — these links constitute a major navigation element. Of course the categories links also should use
<nav>. Beyond those three there are no more major navigation elements on the site
The W3C defines the
<section> tag as follows.
The section element represents a generic section of a document or application. A section, in this context, is a thematic grouping of content, typically with a heading.
They go on to further say
The section element is not a generic container element. When an element is needed for styling purposes or as a convenience for scripting, authors are encouraged to use the div element instead. A general rule is that the section element is appropriate only if the element’s contents would be listed explicitly in the document’s outline.
From the spec
<section> doesn’t have a very specific semantic meaning, it’s just about grouping related content. I was debating on whether I should wrap the main content in a
<section> tag or not. Strictly speaking the wrapper is there to just make sure that the content is on the left, and that I can put the sidebar on its right, so that would be styling. On the other hand it is the main content, and is a section of the whole page, one of four sections as it were — header, footer, sidebar and the main content. So I decided to use
<section> for it after all. However, the wrapper around both the main content and the sidebar is a regular
<div>, since it just acts as a container.
On top of that there are several more good candidates for using
<section>, things like the comments (section), pingbacks might warrant a separate section from the comments, the various blocks in the sidebar, and so on. The great thing about
<section> is that it doesn’t have a lot of strict requirements — if the content is related (which it usually is, being on the same page) and can be said to be its own section, and if
<section> is not being used for purely styling purposes then it’s all good.
According to the W3C
[an] element [that] represents a section of a page that consists of content that is tangentially related to the content around the aside element, and which could be considered separate from that content. Such sections are often represented as sidebars in printed typography.
Some elements are easy. The “related posts” section of the single post page should definitely use an
<aside>, since it’s related to the post (duh!) but separate from it. I also thought that sidebar is an “easy”
<aside> but then I asked this question — should the entire sidebar be wrapped in an
<aside> and the individual sections within (“about”, “blogroll”, etc.) use
<section>, or vice-versa, i.e. wrap the sidebar in
<section> and its sections in
<aside>? After some deliberation I decided that it should be the former, here’s why.
<aside> element needs to be related to the content around it, while
<section> tag groups related content together, it’s a subtle difference but an important one, and the key here is in the elements’ hierarchy. If we look at the second layout version, then there’s a
<section> tag around the sidebar, which is correct, since it essentially groups thematically related elements; they are related by the virtue of being in the sidebar. However, the
<aside> tag around each section doesn’t actually make sense, because the “about” block is not related to “blogroll” block, or to “twitter feed” block, in the way that
<aside> should be related to the content around it. It’s true that they are all part of the sidebar but their content isn’t related.
On the other hand, if the whole sidebar is wrapped in an
<aside> then pretty much as per the spec, we have the main content
<section> and the
<aside> which is related to it. In this case the relationship between
<aside> and content is more of a high-level relationship, and we don’t care about the actual contents of the elements inside, because that’s what the inner tags are about. In other words, whereas the “related posts” section wrapped in an
<aside> is related to the article through its content, the sidebar is related to main content by just that — being the sidebar to the main content — and we don’t go any deeper than that.
<footer> is also a fairly straightforward element, it is defined in the following way.
The footer element represents a footer for its nearest ancestor sectioning content or sectioning root element. A footer typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like.
Footers don’t necessarily have to appear at the end of a section, though they usually do.
Naturally the main footer of the site is going to use this tag, in addition to that, the tags list at the end of each post uses a footer. I also considered using
<footer> inside the <header> of a post for the meta information (category, date) but
<header> is not a sectioning element and so the
<footer> would still be “the article’s footer” not the “header’s footer”, and that just doesn’t make sense.
There are several more HTML5 elements I’m using in the new design, like
<time>, as well as some microformats whose purpose is to provide common framework for content syndication and make it easier for search engines to “understand” or classify certain types of content. Specifically, hAtom, which is used for syndicated content and hCard, which is used for representing people and places. I might do a follow up post detailing those elements.
Since the new design is still a work in progress many things are changing as I go along, in fact, as I was writing this post I reconsidered the way I use some of the HTML5 tags multiple times and ended up changing my approach in a couple of instances. In addition, the HTML5 spec itself is still not finalized and so there’s plenty of discussion and debate about the best ways to implement it. Still, at least for now, I think the new design is a good start (not to mention visually more snazzy), and I can’t wait to finish it up and put it live.