NB: This page is archived without styles. Go to our home page or read our blog.

What's in a name

If standards conscious designers follow conventions when naming elements on their web pages, can we make it easier for users to create their own stylesheets which will work more efficiently across a wide range of sites?

Andy Budd wrote about Semantic Coding and said,

You'll wrap a <div> or a <span> around another element (or group of element) to act as a hook for your style. By doing this you're adding meaningless markup to your code for display reasons. This makes you feel bad, so you'll try to give these hooks some meaning. You'll put all your branding code inside a <div> called branding and your main content will go inside a <div> imaginatively called mainContent. The question that springs to my mind is does it matter?

This got me thinking about the benefits of naming conventions and I began to realise that these conventions matter, not just for the sake of web designers (and easier site redesigns), but for users too!

My only criticism of Derek Featherstone's article on A List Apart was that it did not go far enough and explore the possibilities of user style sheets for the average web user, focussing instead on web professionals.

His article dealt specifically with print styles where it is relatively easy for web professionals to restyle headings, paragraphs and quotes by creating and applying user stylesheets. But if web developers make use of naming conventions for <div>s too, can we make it easier for regular users to create their own visual stylesheets that will work across a wide range of sites.

Do web professionals already follow convensions?

If standards conscious designers already follow conventions, then the stage is set. So I decided to look at forty designers' sites to see what conventions were being used in common page elements like headers and banners, navigation, content and footers. Here's what I found.

Container div
Used to enclose a page layout in either a fixed width or liquid layout. Names ranged from 'page' to 'wrap' to Ethan Marcotte's 'going-to-hell', but the most popular name was 'container' with a score of 8/40.
Header or banner div
Often used with a large image for site branding. The overwhelming winner was 'header' with a score of 18/40.
Main or global navigation
In a large number of cases, main site navigation was positioned at the top of the page. Naming reflected content and not positioning in most cases, the result was a tie, with 'nav' and 'navcontainer' sharing 4/40.
Left or right side columns
All sites used side column navigation, positioned either left or right (and in some cases both). I was interested to see whether names reflected positioning or content and indeed many sites did contain divs called 'left', 'leftcontent' or 'right'. As most sites used two column layouts, the most popular name was 'sidebar' scoring 7/40.
The main event, the content
Here there was a clear winner, 'content' with 16/40. Variations on a theme included 'maincontent' and 'primarycontent'.
Finally, the footer
No dispute over the winner. 'footer' scored a massive 24/40.

Read the full list of results with URLs.

So a mixed bag. Clearly, some page areas are simpler to define than others. With disagreements on what to name columns or side bars. Naming becomes even more complex when trying to remain flexible in the long-term when thinking about elements in a three column layout. Should I call it column or sidebar, column-a or column-one?

Object orientated programmers have been living by conventions for years. And now it appears that among standards based designers at least, naming conventions are organically being created. I personally believe that this is a very good thing. Jakob would be proud.

So what should we name our elements?

Here are my suggestions for main structural divs

And for other page elements

Wrapping it up

So, what do you think? Should we conform to conventions for naming, however they are formed? Is it right to stick to 'content' and 'main-nav' for the sake of our users' control or is that just too boring? And do we want to make it easy for others to change our precious designs on a whim?

Update

Eric Meyer's recent comments about my original What's in a name column have promted me draw some conclusions. My original thinking lacked depth, so I started thinking of a multi-level approach that would allow for the greatest flexibilty within a common framework. So I have posted a new column as a follow up.


Replies

  1. #1 On May 29, 2004 04:54 PM Colly said:

    Finally, I'm glad this issue is ripe for discussion. I'm hoping that as a community we can quickly tighten this vocabulary and establish some core naming conventions.

    I've followed up this article over at www.collylogic.com and it'd be excellent if others in the community can also flag this up...

  2. #2 On May 30, 2004 12:48 AM Tom Harpel said:

    I known that terms like Nameplate and Masthead are used in the print publishing world. Why not use those instead?

    Sidebar usually refers to some ancillary content related to the main content being presented. On most web sites, however, the sidebar contains stuff not at all related to the main content of the page. It is more like an index and a colophone and a table of contents, all roled into one.

  3. #3 On May 30, 2004 03:55 AM Andrew Robinson said:

    Having become more and more interested in getting content seperated from style seperated from functionality, I worry about putting any divs or spans that have anything to do with presentation in the markup.

    I've also discovered that's nearly impossible!

    But when it is required, I try to keep the naming of those ultimately presentational elements as close to the semantics of what the things is. So I would hesitate to call something a 'sidebar' or 'navLeft' or something because I don't know that it will always be on the left, or on the side. I'd prefer to call it 'primaryNav' or something to that effect.

    I like Tom's comment about misusing 'sidebar'. Good point!

  4. #4 On May 30, 2004 06:30 AM kartooner said:

    Andy, great article.

    I think I'll take your naming conventions into account and implement them accordingly for kartooner.com.

    It just makes sense to streamline and essentially globalize, and standardize, what each of these div sections should be named. Among the adding benefits are less confusion over what a #pagewrap, #wrapper is over a #container (which sounds more appropriate to me).

    Ethan's use of #going-to-hell is funny, but doesn't really add any sort of semantic meaning, further backing up your notion that avoiding this kind of markup is not only recommended, but necessary.

  5. #5 On May 30, 2004 07:23 AM Richard@Home said:

    I'd also like to add 'boxout' to the list - to describe a piece of content that is separate - but releated to the main content. Kind of like an aside...

  6. #6 On May 30, 2004 03:27 PM Cameron Adams said:

    Wow, must have taken you a fair while to do that Andy. Particularly poring over some of the horrid code on my page :o]

    I think that using the word "container" is actually a bad idea. Mainly because what do you call a div that goes around a container?

    When I'm doing some funky graphic effects, I generally find myself adding a div or two. Originally I thought about wrappers around the outside of an element, which would naturally lead to the "container"situation. But now, when I'm coding semantically, I create the structure "menu", "content" etc. then add inside those. Because of that I've started thinking of them like the DOM -- as innerHTML -- calling them menuInner, etc.

    I feel it's a bit more scalable when you have to add a couple of divs, plus the id that matters most -- "menu" -- remains at the highest level; more maintainable code.

  7. #7 On May 30, 2004 07:24 PM Taylor said:

    I am all for setting up some (loose) guidelines for naming conventions, to really take advantage of user style sheets and what not.

    Header, Footer are givens. As far as nav (and others), I'm siding with Cameron on keeping the important id in front (i.e. navMain, navSub etc).

    Great entry, and your style sheet scouring is commended :)

  8. #8 On May 30, 2004 11:24 PM Makarkey said:

    Interesting comments both, on CollyLogic and elsewhere. I agree that my suggestions are more about structural 'place-holders' than pure semantics (point well noted Anne),

    I still believe it worthy to strive for conventions, what suggestions do you have?

  9. #9 On May 31, 2004 04:43 AM Bob Ryskamp said:

    It makes it fun to use EditCSS on Mozilla, too - visiting another site with the old site's stylesheet loaded:

    https://ryskamp.org/brain/design/editcss-and-userstyled-sites

  10. #10 On May 31, 2004 11:23 AM Adedeji Olowe said:

    I think it's high time we had a naming convention. Now that layout and css skills are becoming so important, project continuity is key.

    Ever imagined spending quite a long time understanding which div is what is a sea of css molasses?

    Same strict standard should not be applied to the web as traditional development. It would be good for everyone.

  11. #11 On May 31, 2004 02:42 PM Ahmed Zulkamal said:

    What a surprise to find my name there!
    I'm sorry you had to go through my coding mess(part of which is MT's fault though!) before I could clean it up properly.

    I usually name divs "on-the-fly" and what seem most "logical" to me at that moment.
    I've used main for quite some time to define the main div for the whole site. However, I've now changed it to 'container' as this certainly makes more sense.

    I guess everyone's agreed on some sort of naming convention then?

  12. #12 On May 31, 2004 03:48 PM blackdolphinstudio said:

    Working towards building up a template of site layouts that I can pull from to save some time I find that standardising the approach to naming such divs is the way forward. My first div, for example, is always the container div.

    Where I differ from Andy I think is that I tend to use column1, column2 etc for marking up the columns, and whatever appears in them for that matter.

    It would be good to be able to name the closing div as well, as looking through a mountain of divs at the end of the document it can be quite confusing to know which one is which. I tend to leave an empty line in between the end of one div and the start of another, where possible. HTML comments help a lot too!

  13. #13 On May 31, 2004 09:28 PM Mordechai Peller said:

    This is an issue which I, too, have been giving some thouht lately.

    First, to follow up on a couple of earlier comments, "nav-whatever" has several advantages, such as the "|=" selctor. Think of how much easier it will be for people for find your navagation with:

    a[class|="nav"] {font-size : 8em;}

    (OK, maybe not the best example. I know I sometime blow thing out of proportion, but you get the idea.)

    Second, as Andy alludes to, by properly naming the div's added just for a hook, like magic, bloat becomes semantic mark-up. Just don't get too carried away, or you'll have bloat again--albeit standards complient and semantic bloat, bloat none the lesst may be. (Still beats tables, any day)

  14. #14 On June 1, 2004 12:19 PM Jonathan Snook said:

    I'm going to play devil's advocate.

    The HTML language has tags that are purely unsemantic. I feel no shame in using div's and span's. Should a painter feel shame in using an airbrush over a paintbrush? They are but tools (and easy ones at that!) that allow us to publish quickly and easily to the world.

    Like, how useful is a span on its own? It screams for a class or title tag. But can we standardize every possibility that a span may have? Can we for div? Unlikely.

    And should we? The A List Apart article talks of user style sheets. But what if every site a user got to specify his own style sheet? Should a site author even bother doing a design? Why would (s)he? Who would see it?

    Give me my unsemantic HTML!! Long live the BLINK tag!

  15. #15 On June 1, 2004 01:28 PM Tom said:

    ===========
    But what if every site a user got to specify his own style sheet?
    ===========

    That is already reality, and we can't do anything about it.

    Taking that as fact, all that is proposed in the article is that the convention for naming div's is standardised. Noone would stop you from using supplementary div's too, but your 'standard' ones would be just that.

    I suppose one concern might be that if a large portion of the design community used a standardised naming convention for page div's then this would drive conformity to a particular 'layout' to ensure that your pages remain 'compatible' with the rest.

    I think that possibly the CSS Zen Garden negates the need to worry about conformity of design being driven by using a common page structure.

    So, when will the W3C be publishing their 'page structure standard' then?

    PAge Structure Template - PAST

  16. #16 On June 1, 2004 01:41 PM Phil Baines said:

    Interesting idea you have here Andy, and some interesting observations.

    One point though; If we were to all adopt the same naming conventions, might it not start to limit our creative ability to find new layouts, and structural designs?

    I mean, if we are all thinking 'header, footer, content, sidebar, footer', will we start limiting ourselves to designs that include these things, and nothing else. What if someone wants four content areas, and no sidebars?

    I do think that sticking to some form of naming conventions across companies (multiple designers working together) is a great thing. But can we apply them to something as broad, and as big as the web?

  17. #17 On June 1, 2004 01:43 PM Phil Baines said:

    p.s. I should have read the other comments in their entirity me thinks. Since my point, is not new.

  18. #18 On June 1, 2004 02:52 PM Malarkey said:

    Phil

    Does Dave Shea limit your creativity by standard names on divs (#preamble etc.) in Zen Garden? No.

    My point is that is you want a header, call it 'header', if you want a footer, call it 'footer' and we will naturally establish other conventions too.

    That is not to say that you *must* have a header, that it need be red, white or blue, must contain a logo or even search box or whatever. Other conventions for more minor elements (#links-external, #search-results) will surely follow.

    This is no different to object-orientated programming, makes development easier to understand for new developers, and opens up greater possibilities for things like easier user stylesheets.

  19. #19 On June 1, 2004 04:39 PM James at Practical CSS said:

    This one hits home for me, since I've recently been working on a project (see my link) that seeks to establish a sort of higher-level version of this -- a set of full markup "standards" that can be used not for arbitrary regulation, but rather to give designers a common language.

    If we could get together a basic consensus for div names, markup guidelines, etc., it would make sharing and adapting stylesheets much easier (which is the whole point of the Practical CSS project).

    The template we've currently got seems to be very close to the standards described here. I'll still need to think about whether to change "everything" to "container" though. :-)

  20. #20 On June 1, 2004 06:51 PM SL said:

    I've been using my own reusable CSS structure for a while and it's suprising how versatile it can be, providing how simple it is. Of course, it can't fit all one's needs...

    So I figured that we might need something like CSS schemas: reusable CSS structures drawn from a common vocabulary. A general vocabulary to build Zen Gardens, if you will...

    It seems like many people here are working in parallel towards a similar goal. So, shouldn't this discussion be moved to somewhere else, like on a wiki, where everyone would bring in their various contributions and build on them?

  21. #21 On June 1, 2004 07:36 PM James at Practical CSS said:

    SL, you've hit the nail on the head. That's exactly what I'm trying to get going at https://www.practicalcss.com/ :-)

  22. #22 On June 1, 2004 09:07 PM Chris Rizzo said:

    Generally I've found that when it comes to naming conventions some people get it and some don't. I'm in the get it group so this subject is near and dear. For those who don't get it, naming is something that is done at the spur of the moment with little thought about what that name will mean to another user, what it will mean 2 years down the road, or even if it will make sense to the namer when they see it again. Examples of very poor names: "new" (It's only new for a moment then it's old again, and what happens when something newer comes around?), "bottomofpage" (Bottom of what page? There lot's at the bottom of the page, which is it?), slice00_01 (Excuse me? Where is it, what is it? Where's my secret decoder ring?) That's just a few off the top of my head. Granted these aren't only names you would see used for element definitions, but also for file names of documents and images.

    Most of the suggested structural names in the entry above sound good to me and I use them already. They will make sense to anyone who reads the document, and they won't take any time to decode. With clear naming conventions comes clarity of thought and ease of use. That to me is value of using them, I don't have to waste time trying to hunt down the meaning of slice00_01. It keeps me sane.

    If anyone comes up with another name for footer that makes as much sense as footer then why not use it?

  23. #23 On June 1, 2004 09:24 PM Blake Scarbrough said:

    I try to keep many of my selector names short. Why? to save bandwidth, yes it is only a byte here or a byte there. Also I tend to always name my navigation nl (navigation list), because in xhtml 2.0 they are planning on creating a new tag called nl in place of everyone using ul, so I thought I would get a jump start so I am familiar with it when we move to xhtml 2.0.

  24. #24 On June 2, 2004 12:18 AM Phil Baines said:

    Since you explain it like that Andy, I can see where you are going with this. I like the idea. As long as it is truely flexible.

    So what is the next step? An 'Structural markup naming convention sheet.'

  25. #25 On June 2, 2004 08:04 AM Tommy Olsson said:

    But what about the small minority of world citizens whose primary language isn't English? We might want to use id's and class names that make sense in our own languages.

  26. #26 On June 2, 2004 09:35 AM Phunky said:

    that is true, but i belive you should just use the same names just in your language.

  27. #27 On June 2, 2004 11:22 AM Phil Baines said:

    Tommy, you do have a point. But then again, most markup and programming lanuages are based on english. Even if it is american english (CSS' color - with no U).

  28. #28 On June 2, 2004 11:24 AM Phil Baines said:

    On a side note, and off topic. Andy, this brit pack thing is really taking off. I can't remember if I thanked you for adding me. Thanks!

  29. #29 On June 2, 2004 01:50 PM Adam Taylor said:

    Nice article, and good points. One of the additional reasons to use readable, logical markup is for those who come after...

    We've all had to work on code produced by someone else, and a sensible set of ids and classes makes the thing much clearer to grasp.

    (*Another* advantage over table markup, as if we needed more.)

  30. #30 On June 2, 2004 05:48 PM Andy Budd said:

    Remember that many of the sites in your list use content management systems such as MT. If the authors started off by adapting the default templates (as I did initially) the conventions will have more to do with the CMS the sites are using, rather than author choice.

    The quickest way to build a convention would be for MT, Blogger, et al to agree on a naming convention or even use a standard HTML template (ala zen garden). That way, it would be really easy to share style sheets in a similar way to Doug and Dave's recent April fools prank. Of course, it would also make it even easier for people to use others style sheets without permission.

    On the naming convention front, I quite like mainContent and secondaryContent rather than content and sideBar as it's named based on hierarchy rather than layout.

    I like branding rather than header as it's more descriptive. When I think of headers I think of chunks of HTML that I can include server side and may include the head tags as well as any site branding.

    I'd avoid banner as a few of my site visitors have said that their banner ad blocking software has removed my site branding. I should really change the name to branding but haven't quite got round to it yet.

  31. #31 On June 3, 2004 05:02 AM France said:

    For what it's worth. https://www.sprintpcs.com templates (other than homepage) follow a strict basic structure.

    - navI
    - navII
    - surround
    -- navIII
    -- bodyArea
    -- footer

    Fairly routine, I suppose. However, once I had to whip out the https://www.sprint.com homepage, I had maybe a day to get it out. By then, I was tired of trying to come up with selector names, so I just resorted to high school Spanish - contenido, separeseDos.

    I'm sure Senora Lopez would give me a D-minus for the lame attempt.

  32. #32 On June 4, 2004 04:06 PM Timo said:

    Since you are attempting to use fairly natural language in most cases, why abbreviate 'navigation' to 'nav'?

    I am using almost exactly this list of selectors on my site, thanks for putting the effort into a little bit of standardisation.

  33. #33 On June 4, 2004 04:45 PM Malarkey said:

    (blogging from an Amsterdam coffee shop :) )

    There have been some great points (in my absence) that are making me re-think some of my original names. I agree with Cameron when he suggests the convention of 'device-priority', ie: nav-main and nav-sub, content-main and content-sub. Mr. Budd is right to suggest 'branding' rather than 'header' (what happens if header goes down the side...)

    Timo, the abbreviations come from a desire to shave a few bytes off the XHTML and CSS files.

    Nobody (I think) is saying, "No conventions please, I'm a designer!"

  34. #34 On June 5, 2004 12:46 AM Phil Baines said:

    Amsterdam! not fair! come back to wales you little swine, sneaking off indeed!

  35. #35 On June 8, 2004 02:03 AM David Eads said:

    I'm coming to this a bit late, but I think what hasn't really been addressed is a significant part of object oriented programming, which has been mentioned as a parallel. That's documentation. A standard naming convention is obviously a good idea. But, every once in a while, a designer will not only not use some piece of the convention, but may need to extend the convention. In those cases, I would propose that a best or preferred practice would be including a small document describing these special IDs and classes. I've been following a naming convention for my recent commercial sites, and have documented them this way, and it's worked out pretty well. But if such documents were available to the public through some non-distracting mechanism, I think site structure would be that much more comprehensible for those trying to learn and those called in to maintain other people's designs.

  36. #36 On June 8, 2004 04:38 AM France said:

    To go with my comments somewhere above, I forgot to add the holy 'brand' section. So my vote is obviously for 'brand' or 'branding' instead of 'header' or 'banner.'

    But then I don't see how I could have chosen a name other than 'brand' for a few reasons: 1) I suppose I was inclined to choose that word anyhow given my (not-sure-I-earned-it) Minor in Marketing; and 2) you can't go a full paragraph in Sprint's communications a bragging about their our brand recognition/penetration.

    Such is the life in a corportate stronghold :)

  37. #37 On June 10, 2004 01:58 PM ACJ said:

    I don't like "sidebar" because it says something (though somewhat remotely) about the presentation, which it shouldn't.
    It's not as bad as the infamous class="blue" but it comes close.

    Your "sidebar" will not the on any particular side when served via Netscape 3, Lynx, Links, a braille machine, a screenreader, etc.
    Also, a user style sheet could, for example, place the "sidebar" on top, making url/#sidebar confusing and... just plain wrong.

    One could also argue that the same (with lesser strength) is the case with "header" and "footer" since user style sheets, in the same way, could place a "footer" on TOP of a page. "footnotes" and "banner" might be more appropriate since those terms say more about the content and less about the presentation (and those are things we want to separate, right?)

    Then again, there's far bigger issues one could be breaking his or her head over. Things like semantically correct use of markup elements, protection of wild life, and world peace.

  38. #38 On June 11, 2004 09:11 PM Carey Morgan said:

    Flexible standards are better than lowest-common-denominator kind, so I propose we choose names that allow for simple naming for simple sites, but with common-sense overlapping naming features. For example, in a page with only one content area, there is no need to refer to columns, but multi-column pages might be designed in such a way that the columns are enclosed in a more general content area. I believe we can choose names that consciously allow for this flexibility. Let me sum up this discussion into a revised draft of a naming convention along with a couple ideas that flesh out my comments here:

    Page container: container

    Branding/header section: branding

    Main navigation: nav-main

    Next navigation: nav-sub

    Alternate navigation levels: nav-sub1, nav-sub2 (could replace nav-sub when used so that nav-sub and nav-sub1 are functionally the same)

    Main content: content-main

    Columnar content: content-col1, content-col2, etc (could replace content-main when used, or could be contained by content-main)

    Supplementary content: content-sub (such as related topics, a quote, etc)

    Footer section: footer

    Copyright/legal: legal (is my Privacy Statement a copyright issue? no)

    Search: search

    Search results: search-results

  39. #39 On June 19, 2004 02:44 PM Kevin Etter said:

    I use id names to augment, if not replace HTML comments. 2 birds 1 stone method. The CSS hook and a design aid all in one. Sometimes heading tags aren't meaningful when compartmentalizing a page.

  40. #40 On June 19, 2004 05:40 PM patrick h. lauke said:

    personally, i feel that "sidebar" as a name is still tainted with a "visual" thinking aspect that irks the absolute purist in me. then again, i can live with that most of the time ;)

  41. #41 On June 19, 2004 11:41 PM Iain said:

    I realise this is now quite an old post, but I think this is worth mentioning.

    I found that Norton Internet Security on its default settings was stripping out anything with the word 'banner' out of web pages because it assumed that it was advertising. Anything with 'header' is not stripped out so for that reason it's a better choice.

  42. #42 On June 20, 2004 01:03 PM Malarkey said:

    Eric Meyer's recent comments about my original What's in a name column have promted me draw some conclusions. My original thinking lacked depth, so I started thinking of a multi-level approach that would allow for the greatest flexibilty within a common framework. So I have posted a new column as a follow up.

    https://stuffandnonsense.co.uk/archives/whats_in_a_name_pt2.html