Elemental Nomenclature

Published 15 years, 3 months ago

A while back (so I’m slow), Andy Clark did a bit of digging and compiled a list of the most common ID names used to label pieces of layouts.  I’m out of step on every count except for the footer.  Does that mean I march to a different drummer?  Probably, given my musical tendencies.

Andy’s work interested me quite a bit, not least because he actually sifted through the markup of forty sites (this one among them) to compile his list.  I was also happy to see someone taking a practical approach to the question of naming conventions.  From time to time people ask me about CSS best practices.  While Andy’s conclusions aren’t necessarily the final word on naming best practices, they are a useful starting point for such inquisitors.  Some complained that by listing the ‘best’ (read: most common) names, Andy is stifling creativity, which strikes me as being faintly absurd.  Does the existence of blueprints for ranch houses stifle architectural creativity?  I mean, yeah, maybe sometimes they should, but in general I think the world is safe for Dutch Colonials and skyscrapers.

There’s certainly room for more detailed and extensive work on the subject of naming conventions, as well as other best practices (apparently people are souring on that term, but until I hear something better I’ll stick with it).  I just hope that more people do work like Andy’s, looking at what’s been done as opposed to endlessly theorizing.

Andy also mused:

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?

I’m all for it; giving users the ability to restyle this site on a whim is what led me to propose CSS signatures, and employ one on this site.  Does my site design not serve your needs, or bore you?  Create something better suited to your tastes!  I promise I won’t mind; in fact, I’d like to see what you devise.  If a set of ID naming conventions does firm up, I’ll likely adopt it here so visitors can restyle my site consistently with others that use the same nomenclature.  This is, it seems to me, the least I can do.

  • Published
  • Categorized under CSS
  • 21 responses so far

  1. Now, if only more people thought like that, maybe I’d get better use out of my user stylesheet…

  2. Your lucky :-) For the current version of meyerweb.com, I only changed font-size & font-family (reminds me, I have to target this textarea as well… so small for my tired eyes). And yes I wished other bloggers would use a site signature as well. Seeing #blog at the top of a page is a little sad.

    As for the naming conventions. I’m no sure. I’ve used my fair share of #wrapper, #header of the years, but I feel slightly bored by those names now – and in a recent redesign, a #wrapper became nothing anymore but a style hook, and #header became rather a side-bar.

  3. CSS Signatures — here is one practical reason to use XHTML 1.0 Strict, regardless of how it is delivered: you can use an id for the root element, thus allowing the user to style everything.

    I had restyled your site a long time ago, and since I never use your sidebar, I replaced it (via CSS3) with a photo of Michelle Pfeiffer. But what I had trouble with was the padding on your root element. You apply a signature to the body, hence the problem of the root. I got around that by changing the position, and width of the body. What remained was a small stripe of grey at the bottom. The only thing I could do to get rid of this was to append null generated content, color it blue, and append to the body, to finally position it absolutely at the bottom.

    It all could have been much simpler if the signature was appended to the root, which is allowed only in one (one, as in three minus two, which isn’t all too many, sadly) doctype.

    Anyway, ever since I read about them, I have been using signatures on all my sites, and always have been recommending them to others as a… best practice :]


  4. CSS Nomenclature
    Eric Meyer: Elemental Nomenclature. If I had to name everything the same it would stifle my creativity so much I think I’d go back to tables. A better start to this would be instead of looking at the naming scheme of a dozen or so web designers, look …

  5. Personally, I think that naming conventions are subject to two main issues:
    1. Internationalization. As a non native English speaker, I prefer to assign non english names to my IDs and CLASSes, so to better browse through my code.
    2. Site structure. There is an universal naming scheme that is capable to include all or even most of the different websites out there? Haven’t we yet discussed enough about semantics to start again on a whole new level?
    In my opinion, naming serves best as a reference for the coder, otherwise, I will be able to use my H1 instead of my DIV ID="Header"!

  6. People should just label it for what it is, and yet we still see so many div id="left" things going on. I seem to remember saying something about this two years ago.

  7. As I have commented elsewhere, I think a lot of the software design’s ‘best practices’ are lost because most web designers are not trained in software design. Granted that html is not a programming language, but as designers often need to know js, php, etc. those techniques could help immensely. But as html is separated from css the more that both can develop.

    The more that html mark-up is standardized, the more coding can be separated from designing. Designers should be left to really focus on the look of things and programmers should be left to code. This would also help to keep html semantically clean and force css spec’s to continue to evolve. I think the more html and css hold hands the more they hold each other back. It’s always hard, but the couple needs to divorce for both to really grow.

    I’ve written more on this subject because I am reading a great book on coding (Eric really should join the Amazon associates program so I would link this one for him, the book is called Code Complete by Steve McConnell).

  8. CSS naming conventions
    Funny that articles on Meyerweb and StuffAndNonsense around CSS naming conventions are making a round at the moment, as I reallised the other day that I seemed to have developed my own weird naming standards (or at least that’s what…

  9. Eric, I think that it should be noted that I am *not* proposing a standard style-sheet or document structure, just that if a designer includes a certain element on a page, to call it a specific name. How this can be perceived as ‘creativity stifling’ is beyond me.

    You have prompted me to rethink my logic and add a new column at http://www.stuffandnonsense.co.uk/archives/whats_in_a_name_pt2.html

  10. CSS signature
    Like the whore I am, I”ve decided to obey my herd instinct and emulate Eric”s CSS signature.

  11. Hi,
    I found that I use several of the common ids listed in andy’s table, such as #container, #header, #footer, and I used to use #maincontent, but have recently changed to #body. My personal site doesn’t yet use these convetions, since it’s still very much under construction, it will do one day.

    As for the CSS Signature, I’ll be changing my from #lachy to #www-lachy-id-au. Thanks for the tip about the convetions. However, I’ve also been thinking about applying classes to the body or root element as well. Then, different types of pages in my site could be styled differently. For example, for my blogs, I’m thinking about using:
    <body id=”www-lachy-id-au” class=”blog”>
    and for my pages on technical stuff like XHTML, CSS, etc… I’ll be using something like:
    <body id=”www-lachy-id-au” class=”technical”&*gt;

    I haven’t yet thought of all the classes I’m going to use, nor implemented them yet; and those two may change, but I think the concept is quite good. What do you think?

  12. Designers should be left to really focus on the look of things and programmers should be left to code.

    This would also help to keep html semantically clean and force css spec’s to continue to evolve…

  13. The only advantage of consistant naming is user stylesheets. As long as webmasters don’t name divs “leftsidebar” or something like that (which would defeat the seperation of style and content), it doesn’t matter too too much.

  14. Per Site User Stylesheets
    Making User Stylesheets (CSS) useful.

  15. […] key // Naming conventions table 1. And all that Malarkey // Naming conventions table 2. http://meyerweb.com/eric/thoughts/2004/06/18/elemental-nomenclature/ So what should we name our elements? Here are my suggestions for main structura […]

  16. […] hat use the same nomenclature. This is, it seems to me, the least I can do. » meyerweb : Archived Thoughts: Elemental Nomenclature OK, let me try…. please bea […]

  17. […] I’m working on a new project, and after reading What’s in a Name, What’s in a Name Part Two and Elemental Nomenclature, I want to try to set up some semantically-relevant ids for the page elements. […]

  18. @heath

    ‘Designers should be left to really focus on the look of things and programmers should be left to code. This would also help to keep html semantically clean and force css spec”s to continue to evolve. I think the more html and css hold hands the more they hold each other back. It”s always hard, but the couple needs to divorce for both to really grow.’

    i disagree with this, but i can see where you’re coming from. i took this attitude a few years ago. i feel it’s so often the case for designers to ‘bottle it’ (for what of a better term) with design foresight because they can’t implement it in code – so they don’t do it. what are we left with; many run of the mill designs, boxed blogs, and ripped off aesthetics – often built by developers.

    it’s a real shame, but wouldn’t the web be a wonderful place if designers and coders were one in the same. we would have amazingly gorgeous websites everywhere! designers/developers that have a rapport with one another are very lucky.

  19. […] Elemental Nomenclature […]

Leave a Comment

Management reserves the right to edit or remove any comment, especially when abusive or irrelevant to the topic at hand. HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <em> <i> <q cite=""> <s> <strong> <pre class=""> <kbd>

Comment Preview

If you're satisfied with what you've written, then go ahead...