This is an update from the previous article since the spec has changed to allow footer to have the same content model as header.
Update
When I wrote the previous version of this article a few months ago, I knew, as I’m sure many of you also knew, that this element in particular would be subject to change as the HTML 5 spec neared it’s completion. The problem was simple, the footer element just didn’t feel 'complete', it just didn’t offer the same flexibility as other elements. Now that’s changed.
In summary, the content model for the footer element has been changed to allow sectioning content like header or like nav. In fact it now works in very much the same way as the header element. However, it’s important to note that footer isn’t sectioning content and doesn’t introduce a new section.
If you’ve been working on a site and have incorporated a wonderful new footer with everything that it now allows please feel free to post a link in the comments to show other readers just what you can get away with.
Below is an updated copy of the original article.
Old Article
For some time now we’ve become accustomed to seeing <div id="footer"> at the bottom of web pages but with the introduction of HTML 5 it’s time to say goodbye. With the addition of the new <footer> element we now have more scope and flexibility.
According to the spec
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.
Lets get started
Before we get stuck into dissecting the new element, let’s lay the foundations for the article and cover the basics. As we’ve already mentioned above, most people would have laid out the footer as follows
<div id="footer">
<ul>
<li>copyright</li>
<li>sitemap</li>
<li>contact</li>
<li>to top</li>
</ul>
<div>
However with the creation of HTML5 this is no longer the case. As you may already know, there is now no longer the need for the <div> element for many elements. In our case, when referring to the footer, the appropriate markup would be <footer>
<footer>
<ul>
<li>copyright</li>
<li>sitemap</li>
<li>contact</li>
<li>to top</li>
</ul>
</footer>
As I mentioned in the first paragraph, originally the <footer> element was only utilised once within our pages but with the introduction of the new element, this no longer needs to be the case. The <footer> element can now be used multiple times and to display all the extra information.
Using the footer element
An important point to note is that you are not restricted to use one <footer> element per site, you can use multiple footers, each of which will then become the <footer> for that section of the document. You could therefore have a <footer> for a <section> or an <article>.
Section
<section>
Section content appears here.
<footer>
Footer information for section.
</footer>
</section>
Article
<article>
Article content appears here.
<footer>
Footer information for article.
</footer>
</article>
To see an example of the <footer> within an article/section look no further than this very page. Scroll down beyond the article and you will notice the light grey text section, which falls directly after the “further reading”. This grey text section which gives information about trackbacks, responses, tags and categories is infact using the footer element.
Footer
We’ve already outlined what the new footer can look like above.
Other Thoughts
I was initially thrown off-course by the presentational name of the element; my use here isn’t at the bottom of the page, or even at the bottom of the article, but it certainly seems to fit the bill – it’s information about its section, containing author name, links to related documents (comments) and the like. There’s no reason that you can’t have more than one footer on page; the spec’s description says “the footer element represents a footer for the section it applies to” and a page may have any number of sections. The spec also says “Footers don’t necessarily have to appear at the end of a section, though they usually do.”
Bruce Lawson – http://www.brucelawson.co.uk/2009/marking-up-a-blog-with-html-5-part-2/
Conclusion
The footer element offers the chance to define web pages giving them the correct semantic mark-up that they deserve but it’s vital to use these new found tags as they were intended for. Let’s not get carried away and misuse this tag like we have done with tables and divs.
12 Responses to “ The Footer Element Update ”
Comment by DRoss at
Ok so “old” you’re saying it’s basically used to replace div id=footer.
I don’t get what’s different.
Maybe you had it wrong to begin with but now it’s changed to be like the way you described it in the “old” article?
Comment by Aleksey at
>> If you’ve been working on a site and have incorporated a wonderful new footer with everything that it now allows please feel free to post a link in the comments to show other readers just what you can get away with.
Site navigation with
navinfooterhere: The Charity Spring; site still in progress.Comment by Samuel Koh at
Please help to enlighten me on this. While I’ve just gonna start digging into html5, these new element tags looks to me like they could easily be created in xhtml.
footer{position:relative;float:left;clear:both;}
more codes in here
These elements can also be repeated in different places in the dom. So what’s the distinction of html5 footer element in this case?
Comment by Aleksey at
@Samuel: The point is twofold:
1) as you have noticed, these elements can be created in XHTML, which makes HTML 5 backward compatible and
2) it is more semantic to say
header,article,section,footerthandiv,div,div,divwith non-standardized class names.You can say
class= header, head, heading, top, etc. and there is no way for a machine to know if it really is a header. HTML 5 lets you specify that. We understand it because the CSS creates the look and our mind fills in the details; machines, on the other hand, aren’t that smart.There is another way to do it by standardizing the class names
header,footer, etc. but that makes it longer to write out:<div class="footer">vs<footer>and it starts presuming things about class names and makes them more restricting in a way. There’s also theroleattribute, but it suffers from the same first problem as class names even though it’s not a bad idea.Comment by Alohci at
Am I right in thinking that <footer> differs from <div class=”footer”> only in that it has defined semantics and slightly different author conformance requirements? i.e. They are identical from a browser processing perspective?
@Aleksey, Are there any semantic extraction utilities that can make use of <footer>? I can imagine a search engine weighting text in <header> over body text over text in <footer>, but if they did that <header> would become the new meta-keywords.
You mention the role attribute – footer maps very nicely on to the “contentinfo” ARIA landmark role, while there’s dispute of whether header maps on to the “banner” role or not. But if there were a role for header, it would be much better than using <header> and <footer>, because it could be used now in a completely backward compatible way without recourse to HTML5 shivs or the like. If the possible values of role are an enumerated list each with defined semantics, then a validator can check for conformance just as easily as it can for specially named elements, and semantic extractors could extract the sections just as easily.
Comment by Aleksey at
@Alohci: Almost. By default, the browser doesn’t know what a
footeris yet, but once it does, I will imagine it will render it the same as adiv.There aren’t any utilities yet, but there definitely will be. I can imagine they will be useful for screen readers.
The thing with avoiding the HTML 5 shiv is there will still be new elements introduced no matter what, so why throw out the sectioning elements to avoid shivs? Not saying you’re suggesting it, but we either make no new elements, or we make all the new elements that will be useful; it makes no sense to go halfway.
Comment by Juraj at
XHTML is not backward compatible.
Comment by Aleksey at
@Juraj: You took that out of context: I said HTML5 is backwards compatible, not XHTML.
Comment by Shaun Robinson at
I am getting HTML validation errors when I put a h1 in a footer tag.
I know it probably is not allowed, but there are so many times a header is needed inside a footer! Especially with big, modern footers. Please see http://www.rubious.co.uk and advise.
Comment by Alohci at
@Shaun – In my opinion, your footer is not semantically a footer, it’s an aside or a section. Only the aside at the end of your footer is semantically a footer from HTML5’s point of view. The fact that presentationally it appears at the bottom does not make it a footer.
Comment by landscribe at
@Alohci
But also, doesn’t the term “footer” imply that a footer element is to appear at the bottom?
Comment by Alohci at
@landscribe. I think the best way to explain this is so say that while the term “footer” implies that it is to appear at the bottom, the tag name “footer” does not.
See the “Other Thoughts” quote from Bruce Lawson above.
Remember that modern HTML is a semantic mark-up language. Purely presentational elements are deprecated in HTML 4 and obsolete in HTML 5. So <footer> doesn’t imply “this is to appear at the bottom” which would be a presentational statement, instead it implies, this element contains information which, from a typographic standpoint, is ordinarily placed at the bottom. The quote in the original article, “A footer typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like”, is not just guidance about what to put in footer element, it’s what the definition of the footer element is
This means both that content placed at the bottom does not necessarily belong in footer element, and that footer elements need not appear at the bottom of a page or section.