Header and Footer in the Semantic Web

A couple years ago I read through Andy Clarke’s Transcending CSS and it really made me think about semantic naming conventions I had otherwise taken for granted. By now, most of us (at least people reading this blog) practice using semantic markup and meaningful class & ID names. But can we do it better? Probably. There’s always room for improvement.
Andy’s book was (still is) filled with many techniques that I hadn’t seen before. I had fallen into the trap that many designer/developers fall into. I was doing things just because I had seen other others doing it and assumed it was the best way. This is why most people still use <div id="wrap"> even though it’s usually unnecessary.
I’m mainly talking about semantic div naming. Specifically "header" & “footer”. I’ve had a while to think through this, so bear with me here.
Basic semantics
The basis of the semantic web is to look at content first, and then decide which element to use, based on that content. Using a list for navigation rather than a paragraph with line breaks (for a brutal example), using an h2 instead of regular bold text, things like that.
Semantic elements extend beyond just XHTML, it extends into your class and ID names. We’ve all seen articles telling us to use names like "error", rather than "red" and "highlight" rather than "yellow". These names are more meaningful and leave room in the future changing the CSS behind them, while still keeping them meaningful.
The same principle should be applied to ID naming, but for some reason, it hasn’t fully taken off. We’re using names like "header", "footer", and "sidebar" in our every day development. On the surface they’re fine, but in the long run they can really hinder future design changes.
What information can be gathered from these div names?
Header
From the name alone, you can tell that this element is at the top of the page. From experience we can assume it also contains some kind of information about the site (name, logo, tagline, etc.). But it’s definitely at the top of the page.
Footer
Footer tells us this is located at the bottom of the page.
Sidebar
The name "sidebar" contains no information about what it contains, just that it runs along, either the right or left side of the page.
The popular way
<div id="header"></div>
<div id="nav"></div>
<div id="main"></div>
<div id="sidebar"></div>
<div id="footer"></div>
What if you want to put the logo somewhere else? Maybe your copyright and contact information isn’t stylish at the bottom of the page anymore? Or you just want to move that sidebar where your "footer" is? You’ll have to rework the markup, move code around and waste time. This takes a valuable function of out CSS, you should be able to completely redesign the layout of your site without touching the markup (unless you want to add stuff, of course). That’s the true power of CSS.
Advanced Semantics
Andy Clarke proposed that we actually look at the content contained in these divs before give them labels and lock them into a role that could change in the future.
Andy’s suggestion
<div id="branding"></div>
<div id="nav"></div>
<div id="content">
<div id="content_main"></div>
<div id="content_sub"></div>
</div>
<div id="site_info"></div>
My edits
I’ve made some suggested changes to this code, I’ll get into the why of that in a little while, but for now, here’s how I changed it:
<div id="branding"></div><!--/branding-->
<div id="nav"></div><!--/nav-->
<div id="content">
<div id="content-main"></div><!--/content-main-->
<div id="content-sub"></div><!--/content-sub-->
</div><!--/content-->
<div id="site-info"></div><!--/site-info-->
What information can we gather from these div names? (Let’s just look at the 3 we’re talking about)
Branding
Logo, tagline, topics, information and graphics that brand this as an individual can be found in a div named "branding". Best of all, it gives no positioning–relevant information, so in the future (or present) this area can be moved and modified in any way. As long as the content stays meaningful to branding information (which is not usually something that changes in a redesign/realignment), all will be well on the web.
Content-sub
This is old "sidebar"; "content-sub" is labeled as secondary content, it can be positioned anywhere, and will most likely continue to be secondary information in relation to "content-main". And both are contained in a div labeled as "content". You can always add more elements in there like "content-level-three" to accommodate a growing site. But, I find that "main" and "sub" usually cover everything.
This will clean up your style sheet as well:
#content{}
#content-main{}
#content-sub{}
Site-info
"Site-info" replaces the old "footer". The footer usually contains content about the site: archives, copyright, maybe a contact link, etc. And there’s no rule that says that information needs to be at the bottom of the page (there isn’t, I checked). It’s fine if it’s there, that’s where mine is, but in the future if you want to move it the div name will stay semantic and meaningful.
The changes I made
I made some changes to Andy’s code for a few reasons:
- I can never leave well enough alone.
- I always close out my divs with a comment telling me which div got closed so there’s no confusion in the future.
- The underscores: I switched out the underscores with dashes because I came across an article about using underscores in CSS.
In old browsers the underscore in ID and class names had to be escaped like:
p.urgent\_note {color: maroon;}
Or there can be some bad layout problems. Now, this is a big "Who give a crap" in today’s web since no one uses these old browsers anymore, but I see it as a small change to my CSS to make it slightly more degradable just in case some strange user comes by. And it’s really no extra work to do this, which makes it even better.
Closing
I’ve been using this technique for a while now and I love it. When I did my last redesign, it was just a straight style sheet swap. I don’t know if anyone remembers what that looked like, but this is totally different. It was very simple, fast and I hope some readers out there give it a try.
Thoughts? Want to tell me I’m wrong? I’d love to here it.
You can leave a response, or trackback from your own site.
« This Week in Links 11/11 | 5 Ways to Build a Better Team »
|
Comments (15)
|
Trackbacks & Pingbacks (3)
-
[...] Best of all, it gives no positioning–relevant information, so in the future (or present) this area can be moved and modified in any way. As long as the content stays meaningful to branding information (which is not usually something … Read more [...]
-
[...] CSSKarma.com » Header and Footer in the Semantic Web – Calling for abandoning 'header' and 'footer' for more semantically correct monikers. [...]
-
[...] CSSKarma.com | Header and Footer in the Semantic Web Sensible argument to rename header, main, sidebar and footer divs to branding, content_main, content_sub and site_info respectively, to move away from positioning info. [...]
Leave a Reply



Great article Tim, this was one of the first things i started using after reading Andy’s book, you just made me want to re-read it again.
Good stuff Tim! I didn’t know there was a definitive reason for switching from underscores to dashes. Good to know!
Thanks for this article which made me follow through on what I had already partly begun: not using class/id names like “left” or “right” or similar. Funny enough, I still kept the “header” and “footer” names. No more!
Great article, but I’ll have to pass on the header and footer rename. I strongly believe that the information contained on the Header y really important for the company as it makes easier to the user to remember the site or leave a good impression, that’s why I believe it always has to be on the very top of the page.
and the footer is a really relevant information about the website, but still only relevant for the ones looking for it, and is almost like a habit to look for that kind of information on the bottom of the page.
Having said that, once again, great article.
Cheers.
I agree. I have been doing this since I read Andy’s book. We should be describing the content when naming classes/ids and not the where it is displayed or what it looks like.
@pab Andy has some weird stuff in that book too. I remember him suggesting that all content be put into one long unordered list.
@Hill, yea I read that after about 3 months of using the underscores. I’d like to actually see it break something though.
@Thorsten I agree! I always thought it was weird that header and foot stuck while utility classes got all the semantic attention
@Juan Fair enough, it’s not for everyone, but try to examine to content you’re putting in that header and ask if you’re doing it because it makes sense or because it’s been done like that for so long
@jt Thanks! I’m glad there are like-minded people out there, I wish we could get Andy to chime in on this post too
Great article. I’ll definitely be changing the way I work now.
I used to use comments at the end of each div but this seemed to cause some kind of bug in IE6 where the last few characters of each div were duplicated – have you not experienced the same thing?
Using dashes for class names can cause problems in javascript and jquery as they can get treated as minus sometimes
i still cant deicde whether to use
myclassname
MyClassName
my_class_name
my-class-name
shucks………
@Tim: Chiming in? Your wish is my command! It’s nice to see this topic still getting attention.
I’ve been updating my thoughts about naming conventions again recently.
Weird stuff in my book? What could you mean?
@Mich Yea, I’ve run into that issue a couple times, but only when I use a lot of comments. Generally speaking these are the only divs I use on a page:
-branding
-nav
-search
-content
-content-main
-content-sub
-site-info
unless there are some extra nav element (like in this site)
This specific page is a bad example because there’s some wordpress code I haven’t got around to cleaning up yet.
@jimmy have you been able to pinpoint the jQuery problem with dashes? I bet the jQuery developers would lie to hear about something like that
@malarkey Hi Andy, wow, thanks for chiming in
! Thanks for the link and the update (and of course for writing the book.)
The only real weirdness that stuck with me was nesting nesting everything in a
UL. I tried it once, and it actually worked really well, but never felt quite right. But I’ve been using the new ID naming since the day I finished reading the book! Absolutely changed the way I develop web sites. Thanks!Ah – why worry about supporting a browser from 7 years ago? The only browsers you should worry about are IE6, 7, (8 beta 2?), FF, Opera and Safari.
Yep, this makes sense Tim. Here’s a question for you, when will XHTML be modified to encorporate new semantic tagging? I mean, yes <strong> is better than <b>, but when will I see a or type of tag? Just curious if you knew anything about that.
Thanks for the great article, I’ll start using this myself too.
@Ellis The overall goal should be to make a web site work for every person who comes to it. Since the browsers effected by the underscore are so old I don’t recommend putting in that much effort to help them, but using a hyphen instead of an underscore is such a small thing and it makes a big difference.
@charlie moving at the speed of the W3C, a new version of XHTML might be long after I die. I did hear that HTML 5.0 is trying to be more semantic with tags like <nav> in the spec, but of course it’s a long way from finished.
Maybe we’ll see some official cooperation when Doc Brown’s flying Delorian descends on Hill Valley.
I’m slapping my head, I was thinking underscores would be better than dashes when I made that comment, but dashes are better for naming conventions after looking back over some stuff.
Thank you for an excellent article. One slight correction: in the stylesheet example you need hashes (#) before the elements, since those are after all IDs (e.g. #content{} ).