Sidebar Semantic Shenanigans
The ever-present sidebar. It’s a staple of the ‘net. You see it everywhere. It’s an accepted design convention allowing visitors to quickly recognize it among millions of sites as a place to find all kinds of auxiliary information.
Now we’re all aware of the importance of keeping our classes clean, meaning that they shouldn’t contain presentational information like “leftbox” or “greentext”, but what about something a little less obvious like “sidebar?” I’ve—slowly—come to realize that the ubiquitous sidebar’s name is presentational. I mean the word “side” can mean only one of two things: left, or right. Just because it doesn’t say “left” or “right” doesn’t mean the word “side” isn’t implying one of them.
Semantically speaking however, what’s being presented in the “sidebar” has nothing to do with the word “side”, but is most often auxiliary information that is usually—but not always—related to the main content block. Hence my decision to name the sidebar on my site “aux-content.” This way, it’s fully autonomous in terms of its ID (I don’t believe in using class names for unique items in a page) and isn’t bound to be a sidebar for the rest of its life.
Now if your sidebar only contained the most recent posts for example, or your blogroll and nothing else, then you could easily name its ID “recent-posts” or “blogroll.” But it should never be named “sidebar.” I mean, what if you wanted to turn it into a footer one day, or a part of the header, or something else?
Go semantic, it’s your safest bet.
Sphere: Related ContentBuy my book
The Art & Science of JavaScript
Advertisement
Advertisement
6 Comments
Sorry, the comment form is closed at this time.
November 14th, 2005 at 2:03 am
Ara,
It’s sooooo easy to fall into the non-semantic trap. Our brains sometimes just think that way, especially since there are a lot of other things we do where presentation and content are mixed. Take handwriting. Or how most people approach a PowerPoint presentation. Most graphics are this way, too.
Thanks for the wake-up call. I’m off to check my site for these kind of issues!
November 14th, 2005 at 7:15 am
I know it’s going to sound dumb, but the reason I wrote this post was because for a while there it hadn’t dawned on me that sidebar was a presentational name for a class or ID.
November 18th, 2005 at 10:00 am
Ara,
nice thought. However I can’t say I completely agree. We are faced with the same problem when it comes to designing classes in code. The name of a class, be it css class or code class, must represent what it does and on what (what data). Data in your case is the html code inside your sidebar.
So, if the content of your sidebar is not easily convertible to any other type of “container”, such as footer or header or what not because it would not display properly (and css classes are all about how it presents the content), then there’s no harm naming it sidebar. Also, if you know your site is not about to change and if it were you’d have to redo it from sratch, then again, “sidebar” is fine.
Don’t forget that using abstract nomenclature is great to make things more “generic”, however it also makes things much harder to understand when you’re looking for something more specific.
I really love the way this works in C++. I’m now learning “generic programming”. And the nomenclature there is to use as generic names as possible. However when you then use this generic class, for a specific purpose, you can create an alias and this alias will have a more specific name. You then use this specific name through the rest of the code. Think of it as “name derivation”. It works wonderfuly.
ex: typedef AbstractFactory MonsterFactory;
now isn’t this just lovely? Any code from then on uses MonsterFactory, which now represents the AbstractFactory with its particular configuration. There is also no doubt as to where MonsterFactory comes from.
Take care and congrats on your great site. I just have to find time to put mine in shape! ;)
November 18th, 2005 at 10:04 am
gee, wonderful, your filter took out everything in my less then and bigger then, so that my example is utterly meaningless!
Let’s try it one more time, perhaps they need to be escaped?
typedef AbstractFactory> MonsterFactory;
November 18th, 2005 at 1:44 pm
geee this sucks!
ok, so the example should be something like this:
typedef AbstractFactory (less then) MonsterCreator&, MonstersList (greater then) MonsterFactory
November 22nd, 2005 at 12:02 pm
Actually HTML classes aren’t uniquely for presentation.
Yes, but at the same time, if you tie your code down to presentation, what do you do when that presentation changes? Root around in your code and try to change all of the non-abstract, highly-specific nomenclature that is no longer relevant?
Oh, and thanks for the compliment! :-)