using header for site headers?
Even though the html vocabulary isn't all that large or all that difficult to understand, it is not entirely free from ambiguity. Elements like 'address', 'figure' or 'article' may sound pretty straight-forward at first, but it's still easy to misinterpret them and w3c's definitions aren't always very helpful. Which leads me to the following question: should the header element be used to mark up site headers? The answer is of course not as clear cut as I had hoped.
defining header
The header element represents a group of introductory or navigational aids.
So that's what the w3c has to say about headers. Introductory or navigational aids. But an introduction to what, or navigation related to what? The way I see it the content inside a header element always relates to the main content featured in the wrapping section. This ultimately leads to a more difficult problem though:
site vs page
The web is but a collection of pages. A "website" as such doesn't really exist. Because pages are served from the same domain and because those pages are branded in the same way, we consider a collection of pages "a website". But there's really no strict, technical bond between these different pages that irreversibly connect them to a certain site.
Likewise, there is no way to correctly express the difference between site information and page information in html. Ideally the site elements (site header and site footer) would wrap all pages in a single html document, but that's hardly feasible. So each page we build is a combination of site and page elements, which doesn't feel all too correct from a purely structural point of view.
Complicating matters more, when taking ajax into account you could technically build your website in such a way that it's just one page with dynamically loaded content. in between the site header and site footer. In that case you could argue that the site header actually spans all the pages, even when they aren't necessarily present in the code just yet. We can just consider that an extreme case of lazy loading, right?
more header definitions
A header element is intended to usually contain the section's heading (an h1-h6 element or an hgroup element), but this is not required. The header element can also be used to wrap a section's table of contents, a search form, or any relevant logos.
The w3c expands on its short definition, but once again fails to really clear up all grey areas. Site headers do contain logos, possibly a search form and maybe even some headers, but do they relate to the page content?
On most sites, site headers only contain elements that are meant to pull you away from the current page, rather than introduce the page. Site headers often contain navigation to other pages, search forms with results to other pages, a logo that might take you back to the homepage, .... Probably one of the only elements that does belong there is the language navigation, as it directly influences the content on the page you're on (if you have a symmetrical navigation scheme that is).
Furthermore, a header contains information that could and/or should be useful before accessing the actual content. Is this true for a site header? It could be when you are visiting the homepage, as the site header introduces you to the site's owner and content structure, but on all the other pages the site header is actually in the way of the page content. Instead of introducing you to what is on the page, you are tempted to leave for other pages on the website, even before getting access to the content of the page you requested.
conclusion
In some (rare) cases the header element would suit a site header. On a homepage it wouldn't look out of place, on a single-page ajax-site it would work out too. But apart from that I think site headers don't deserve a header element. They introduce nothing, they lead you away from the page content and structurally they would have to be placed in front of the page content. This just doesn't sit well with me.
On my own blog I've extracted all site information and placed it in its own div right after the page content. It's far from ideal, but for now I feel this is probably the neatest way to work around this problem (+ it also allows me to easily style the site information as one single blob of content).