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.

The fact that presentationally it appears at the bottom does not make it a footer.

But also, doesn’t the term “footer” imply that a footer element is to appear at the bottom?

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.

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.

@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.

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, footer than div, div, div, div with 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 the role attribute, but it suffers from the same first problem as class names even though it’s not a bad idea.

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?