I recently decided to update the Compass Design website using HTLM5 and CSS3, with the view of making the site more efficient in terms of its underlying code and its load times, as well as bringing it up to date and giving myself an opportunity to work with HTML5.
As we specialise in WordPress powered sites, the site is naturally a WordPress one so I set about identifying how the new semantic elements in HTML5 would work within the WordPress theme environment. It turned out to be fairly straightforward – in most cases.
This site is built using a child of our in-house parent theme, which in turn is an adaptation of twenty ten, the default theme packaged with WordPress since release 3.0. The twenty ten theme uses the html doctype, so is theoretically HTML5. But on further inspection it was obvious that it doesn’t actually use any of HTML5’s new elements. I wanted to change this without breaking the theme.
There are six new elements which are crying out for use in WordPress sites:
<article> = Post
This is a complete no-brainer as far as I can see. The new <article> element corresponds very closely to a post in WordPress. When translating WordPress terminology to the uninitiated, I often explain that a post is like an article.
An <article> is an independent piece of content which could be syndicated in an RSS feed – it is this stand-alone nature which differentiates it from a <section>. Posts are generally fed to RSS, so it makes a lot of sense for <div id=”post-<?php the_ID(); ?>” to be replaced with <article id=”post-<?php the_ID(); ?>” in the loop.
<section> = Part of a post
A <section> is a way of sectioning a page or an article, and isn’t designed to be independent or used for syndication. Within a post in the loop, most sites have a few divs, which might include the post title, post content and meta. Each of these divs becomes a section.
<header> = Header and/or Post title/meta
Another fairly obvious one, although on further inspection this may not be as simple as it looks. A <header> is a heading element for a page or an article. So most if not all of the contents of the header.php template will be in a <header> instead of a <div id=”header”>.
The other interesting use of <header> is in relation to individual articles. You could, for example, use the <header> element for the post title, or for the post title and meta combined. This could be useful for styling these two sections together above the post content. In the case of this site I decided not to use <header> in this context but to stick with <section>, but others may have taken a different approach.
<footer> or <small> = Footer or Colophon, and/or post meta
The <footer> element is designed for the footer of a page or an article. So like <header> it can be used to contain the content in the footer.php template, and to contain information which follows each post, such as post meta.
The <footer> element needn’t necessarily replace all of the content in the footer of a site, particularly if the site has a fat footer with content associated with the current page. In this case the contents of the fat footer may be more appropriately housed in an <aside>, more of which below. In this case the colophon could be placed in the <footer>, maybe replacing a <div id=”colophon”>.
In the case of this site, I used the <footer> element to contain all of the site footer since there isn’t a fat footer. I also used the new <small> element to contain colophon information, as this indicates small print. If your site has widget areas within the footer, you may want to use <aside> elements contained within a <footer> element, or above the <footer> element depending on the site’s structure.
<nav> = Menu and other navigation
The <nav> element, like header and footer, shouldn’t be limited to one place in the site. It’s fairly obvious that it should be used to enclose the navigation menu. In twenty ten the navigation menu is contained in <div id=”access”>. I simply changed this to <nav id = “access”> so any styling of the ID wouldn’t break. For me this makes it much simpler to work with this element as I never found it very intuitive that twenty ten used access as the ID name for the navigation menu.
<nav> can also be used to contain navigation within the content area. In this site I used it to contain the previous and next posts links. You could also use it to contain links within widget areas (in sidebars or a fat footer), if they were solely used for navigation.
<aside> = Sidebar
This was the one which I hummed and hahed about the most. The question was: should the sidebar widget areas be contained within an <aside> element or a <section> element? Some people have suggested that HTML5 should include a <sidebar> element but this wouldn’t be consistent with the new elements being semantic rather than presentational – many WordPress developers prefer not to talk about sidebars at all but about widget areas, to avoid the assumption of where on the page these areas appear.
I researched this one on the excellent HTML5 Doctor site as well as on numerous forums including Remy Sharp’s. There is a debate about this issue on Remy’s blog but according to HTML5 Doctor it seems the HTML5 spec has now been changed to allow the <aside> tag to be used outside an article. Having read this I decided to use <aside> for the widget areas in the sidebar.
So why bother?
So the functionality of the site has hardly changed. I haven’t used <canvas> or anything particularly radical. A lot of clients – although less than used to – access this site with Internet Explorer and I wanted their experience to be as good as or almost as good as those visiting on modern browsers.
I think there are three quick gains from using HTML5 elements like this, though:
- It makes editing code much simpler. It’s much easier to spot the closing tags when not all of the site’s containing elements are divs. This makes editing quicker and less error-prone.
- It aids accessibility. One of the functions of the new semantic elements is to increase accessibility by making it clearer what elements are meant to be doing.
- It speeds up the site. By implementing these simple changes, plus a few CSS3 improvements, I’ve decreased the home page’s load time by 10%. Considering I left a lot of IDs and classes in, this isn’t bad. When the new markup has had time to bed down, and the spec is more stable, I’ll probably go back and strip out any IDs and divs that don’t need to be there because the new elements are easier to target with CSS. But hey, this site is an ongoing project, like many others…