Using HTML5 elements
Not so long ago I highlighted the fact that this website had made the jump to HTML5. However, within that post I only highlighted the reasons for doing so without going into much detail.
It had been my intention to talk in depth about how everything had been created and I had originally planned to wait until the site had bedded in before writing this post, however a recent comment within that post has made me do the write up now.
In that post I alluded to the fact that I wasn’t sure if I had used these new elements correctly, if the truth be told, I was in fact looking to my peers to point these errors out, allowing me to address them. Since then I’ve had a few Twitter DMs highlighting problem areas throughout the site.
Now that these have been addressed and after a quick modification to my page layout which was highlighted in the last post, I feel it would be best to talk readers through the pages of the site and pass out some of the information that I have learned since taking on this redesign.
As you can see most pages adopted a strict three column layout, with the main content area on the left, the related content in the middle and the extras, for want of a better word, column occupying the far right hand side of the site.
With this site being coded in HTML5 I wanted to cut out all divs and if I could classes and ids. Therefore the layout follows a structure something along the lines of this diagram below.
Straight away you should have noticed the distinct lack of divs within the source code. I have still kept a div acting as a wrapper, partly due to the fact that I wasn’t sure how to contain all of the new elements. Perhaps that’s something which I can address in a future blog post and perhaps put forward to the spec committee as something which should be implemented. If you do know of a viable alternative then please let me know, although I would like to state that I want to stay away from using a section or article tag, as I don’t believe these methods to be what the elements were intended for.
Dealing with Internet Explorer
I wrote about this in my previous HTML5 blogpost but there’s no harm in mentioning it again, especially if I’m going to be dissecting various parts of the site. As we’ve come to expect, Internet Explorer does not play ball, it struggles to understand these new elements. As a result, Remy Sharp has produced a piece of javascript which will help these pages render as they should, simply link it into your site and you’ll be laughing. However, I should point out that if the end user does not have javascript enabled you will run into problems.
You’ll also need to remember and set your HTML5 elements to display block in your css file.
Let the writing commence
Now let’s get down to the nitty gritty of each individual element. If you’ve been reading anything regarding HTML5 you will have undoubtedly seen the following elements named; header, nav, section, article, aside and footer, all of these links will take you to their matching section in this blog post.
Although there are many more elements within the spec these are the ones that I will be focusing on throughout this article due to the fact that they have been utilized most often.
Header
Every HTML5 site needs a header element, no ifs or buts about it. You’re header element must also contain a heading level. Within this site my header element is the grey bar running across the top of the page, which displays my jQuery hover states that give a little bit more information as to what each page contains.
Some people may think it is a waste that I have not included an h1 tag with my name or brand in there but to achieve a minimalistic look I wanted to incorportate my name into the menu system which as a result freed a H tag within the header. Besides, I’m of the opinion that using an H1 for your logo is a bit of a waste.
Due to the information that was going to be present within the header section I decided to mark it up with an h5 tag simply because there would be more important pieces of information on the page which demanded a higher heading tag.
Update: Since writing this post the header element has now changed to hgroup.
Nav
Originally I had my nav within the header element but was told to move it outwith as it wasn’t validating. However, this is no longer the case and you can thankfully place your nav element within the header. You still need to structure your list like you would normally with either a unordered or ordered list, depending on your preference.
Section
I’ve used the section element to contain my main body of content, which would normally be the content and sidebar areas. This is one such area I am still not sure about but it seems to serve it’s purpose well enough. If you have a suggestion for how I should implement my section element then please let me know.
Article
I’ve used the article tag for what you might expect, my main content area: blog posts and primary content areas where the biggest parts of information can be found.
Aside
This proved to be a sticking point for me when designing the site, if I have interpreted the spec correctly I believe that the aside element should be used for blockquotes etc. something which is closely related to the content but this is not how I set out to work with them. When looking through the spec I didn’t see anything which could relate to a sidebar section, section and article could be used but it didn’t look or feel correct.
I finally decided on the aside element because I would be displaying content which tied in loosely with the main content on the page. Information that you will find in the aside elements range from tags and categories for blog posts to social network links on my about page.
Footer
The footer element is as you would expect, a place where you put all your copyrighted information such as company, vat and telephone numbers. Within this site, I have also included three list items which display further information about myself, the site and my latest comment on twitter.
However, a footer doesn’t necessarily have to be at the bottom of the page. For example, some people have decided to include the footer tag within a blog post, holding information such as date, comments and tags.
Conclusion
I hope this gives you a good insight into how I created my own website and has helped to answer a few questions, opposed to creating them. If there is demand I might look into breaking down other elements such as time or elements like form input fields.
If the above has given you a taste to continue reading up on html5, and if you have a month or two free, then why not start reading the spec which can be found here http://www.w3.org/TR/html5/semantics.html.
Great article Jack. I must say its given me the itch to try out html5 or at least look into it.
Nice article. It won’t be very difficult to make the transition with practical references like this one. So, who’s going to make one for XHTML 2.0?
Nice write up Jack it’s good for people to know how others are marking it up in order for the spec to be finalised.
Re h1’s etc. You can now have multiple h1’s on a page, all within a header element for each article is this not an approach you fancied trying?
Also I’d probably change your About Me, Twitter and What I do headings to h3’s (maybe h4’s depending on the page.)
Nice one Jack. Interesting to see you have your article within section. On my site I have everything within the one main article.
I was going to put my main logo/header in a hgroup but it seems a bit pointless having a hgroup element with only one header in. Hgroup is brandspanking new though so I’m sure it will change.
I love how using html5 we can get away from using loads of div tags, however I find I am adding more tags now such as putting more things in headers or footers, things like that.
@steve
Cheers mate. Any questions give me a shout, my answers won’t be perfect by any means but at least they’ll be “along the right lines”
@msikma
Thank you, although I think I’ll leave that challenge to someone else haha.
@Rich
Nice tip about the H1s. I had never thought of actualling doing that, I’ll be looking into later this evening. It could prove to be very handy.
Regarding the H3s, when I was creating the site the validator threw up lots of errors because I had incorporated H(n) in my footer. Is this no longer the case?
Although, if errors were still to occur I guess I could always move that section outwith the footer.
@Tom
Good to hear from you! As we all know working with this spec is more an experiment than anything else right now.
The article problem posed alot of problems. Infact, if I’m to tell the truth I’ve been a bit sneaky about it. On my index page I’ve wrapped my articles, as you have pointed out in a section tag. However if you go to my articles page, second link on the main nav, you will see I’ve wrapped my articles in an article tag. I’m still currently trying to find the best method and seeing if browser/google interpret these pages differently.
As for hGroup, totally agree, I’m steering clear for now.
Ah right good point, yeah no h tags allowed in footer, didn’t realise you had that stuff in your footer.
Although maybe this is a good use case to put to the whatwg for why h tags *should* be allowed in footers?
Ah I thought of something else, maybe you can ditch the wrapper div and just but the width and auto margins on the header, section, nav etc?
I have been waiting for this post to bring up a couple of things. I would have brought them up before but I wanted to see your thinking behind it first
I had a play about with your site in Firebug the other day and found a way to drop that wrapper div. The body tag should be used as your wrapper
I disagree with your use of asides on your entry pages, and also your use of an aside within an aside. On entry pages, your “post details” aside would be better suited to a footer as part of the article, then the next column could be an aside. On your articles page, you could wrap both columns 2 and 3 in an aside but beneath that they should be sections since they are both the same “aside” (filtering options) but have their own specific grouping (type of filtering).
Whether or not an aside is appropriate for sidebar content is endlessly debatable! I believe it should only be used for things like related links, trackbacks and pull-quotes. Site-wide sidebars listing projects should be in a section. However, if you were on a project page then a list of more projects would be in an aside. I hope this makes sense!
Very nice write-up though, I will do the same once I finish my transition.
@Mike
Using the body for my wrapper is a stroke of genius but then again I don’t expect anything less from you now
With regards to the whole of your third paragraph it’s on the money. When I was building the site I thought I was using the correct elements but now that I’ve read more into the spec I can see that some of the areas you’ve highlighted could be with reworking.
That’s the problem with the spec currently, there’s just too much scope in there. We need a list. It doesn’t need to cover every element, just the main ones highlighting a few things that it can and cannot be used for.
I’m very much looking forward to see your site when you push it live.
@Rich
I’m of the opinion that H(n) should stay out of the footer, the only information that should go in there is stuff that complies with the companies act like company registration number, email and street address, vat number and telephone number etc.
By all means, stick in a section element/div tag if you want to make another section above, pretending it’s still part of the footer. However this is something which again could be debated all day, there’s no right or wrong answer.
On a side note, I’ve got something which I’ll be sending to you in an email this week. It could be quite handy.
@Jack, see your point on the above re footer but remember that the footer element can be used in an individual post (for example) to show tags, categories etc as well. It isn’t confined to the foot of the page. One to think about anyway.
What a brilliant article, thank you so much for taking the time out to write something so in depth.
Reading information like this, regardless of whether it is 100% correct or not, is like gold. I wish more blogs would attempt to comment on things such as these, even when they know their implementations could be incorrect. It’s how we all learn and people will be able to solve these problems out quicker.
I hope I can read another HTML5 post soon.