Structural Naming

Published 20 years, 5 months past

After I threw out my two cents on ID naming conventions, Andy Clarke revisited the subject and made some more detailed proposals.  As I said before, I think this is a good conversation to be having.  However, the reactions of some people make me think that I wasn’t entirely clear about why.

A standard nomenclature offers the ability to restyle sites, sure.  That’s kind of cool in an übergeek kind of way, like making jokes involving TCP/IP terminology or wearing a T-shirt that says SELECT * FROM users WHERE clue > 0.  That isn’t really the primary reason why I support the exploration of ID naming conventions.  I’d like to see those conventions emerge because they will serve as a useful starting point for beginners in the standards-oriented design field.  It would help reinforce the idea of structural naming, as opposed to presentational naming.

We’re all familiar with presentational naming.  It’s things like id="leftbar" and id="pagetop".  In terms of layout, it’s the equivalent of <b> and <font>.  Structural naming, on the other hand, encourages the author to ask “what role does this piece of the document play?”  Rather than obsess over the visual placement of the navigation links, structural naming gets authors to consider the document structure.  This can’t be anything but good, at least for those of us who want to promote improved structures.  To pick one set of examples from Andy’s recent post:

#branding
Used for a header or banner to brand the site.
#branding-logo
Used for a site logo
#branding-tagline
Used for a strapline or tagline to define the site’s purpose

While #branding is described as “Used for a header or banner…” you may note that the actual ID name has nothing to do with visual placement.  It’s all about identifying the (dare we say it?) semantic role of that bit of the document.  By encouraging that thinking, a structural-naming convention keeps the author in that frame of mind when he has to go outside the common set of names.

I see this as being much like the often-promoted ‘rule’ that link-state styles should go in the order link-visited-hover-active.  I even wrote an article explaining why that order is important.  Here’s the thing: once you understand why the order is important, you can break the ‘rule’ in creative ways.  For example, suppose you want your hover effect to apply only to unvisited links, whereas visited links should get no hover.  No problem!  Just put them in the order link-hover-visited-active, or even link-hover-active-visited if you want visited links to get no active styles, either.

(Side note: if you chain pseudo-classes, such as with a:visited:hover, then the ordering problem goes away.  If Explorer supported that syntax, we could all move on from the LVHA rule.  Too bad it doesn’t.)

Conventions and ground rules exist for a reason: to provide a lower barrier to entry, and to help guide those new to the field.  Once you become experienced, you can break the rules in creative ways.  It’s been said that the key to good jazz improvisation is a thorough understanding of the rules of music.  In other words, once you really know those rules, then you know how to break them.  In order to know the rules, though, there have to be rules.

That’s why I’m glad to see them starting to emerge in blog postings and the public thinking of people in the field.  The development of these rules is not a barrier to creativity, but an enabler of it.

Comments (38)

  1. Pingback ::

    Heimidal.net

    […] ML/CSS Naming Conventions Posted at 7:38pm on June 26, 2004 Eric Meyer has once again commented on structural naming conventio […]

  2. Pingback ::

    css voyeur at collisionbend.com » Structural Naming

    […] l, CSS Stuff, Web Notes, @ 11:53 pm.

    Eric Meyer just posted his thoughts about standardized structural naming of web page elements. I have read the […]

  3. This is the front end connection to object orientation?? We are moving this way with the seperation of the presentation layer from the structure and logic too. I’m new to the whole thing so I’m not sure.

  4. Trackback ::

    Photo Matt

    Structural Naming
    Eric on structural class names again, but my question is whether or not semantics belong in class in the first place? No matter how you cut it, divs and spans are still the semantic duct tape of the web, and it seems like a better solution would be a r…

  5. but my question is whether or not semantics belong in class in the first place?

    i’d argue that yes, they do…otherwise we might as well go back to class=”redlink” or something (and then later on we decide that it should be blue, change the css only, and are left with a wonderfully contradictory class)

  6. If you’re working with finicky clients, semantically named id and class attributes are almost essential; all you need is one phone call where the client decides that actually, he really doesn’t like blue anymore, and orange is his thing and oh, by the way can we have all the links on the left hand side now be on the right instead? And so the scenario painted by Patrick above could come around rather quickly.

    In an ideal world, semantic CSS allows for rapid production of multiple prototypes with one XHTML codebase and several variants of CSS files (in actual fact, very much like the CSS Zen Garden).

  7. i disagree with that naming. that header might be used for something else than branding (the whole site style is part of the branding imo), and logo is also a visual naming – if you’re using image replacement techniques its more a title. sure, it’s all better than id=”blueskywithfluffywhiteclouds” but it’s not the most flexible and reusable solution available.

    you got me thinking on a proper footer/header naming though. i guess i’ll post again soon with a link to the naming standards of an application my company is currently building. of course, just if you’re interested ;)

    regards

  8. Trackback ::

    just to let you know

    CSS naming conventions mkII
    Eric Meyer elaborates a bit more why he thinks a discussion regarding naming convenions is important. I do agree with him in general – it does make life easier for beginners. But I think the discussion is now being diverted…

  9. The first cardinal rule would be: don’t name an object (id or class) for what it does, or where it goes in the layout. Second, a good naming strategy (and I hesitate to use convention here) can then add semantic value to the document – practically for the designer/coder/maintainer by easily defining the object for what it is (a div that groups all site navigation elements), and for the end user (that div with id of navigation can be used as part of an url, ie enhancing accessibility).

  10. Personally, I think these sorts of conventions are good, but for a different reason than you outlined. I don’t particularly buy into the ‘training wheels’ argument.

    I agree with Mr. Mullenweg that HTML is lacking, and I see these conventions as addressing a need–at least until some standards-body takes the issue up. How does one markup navigation, a blog index, a product page, poetry/lyrics, comments/a forum, or even the concept of a Web site, etc.? People seem to break HTML most often because HTML doesn’t do what they are doing.

    Anyway, I have a few suggestions I’m not really qualified to make:
    + “enable” a system with a profile namespace
    + avoid conflicts with unique names, maybe by using a prefix
    + use classse

    My logic on that last point says ids are “structurally significant” (meaning there’s only one and I want it for myself), rel isn’t too clearly defined (meaning what you use it for now could break it in the future), and I just might want more flexibility than an id could give.

    I hope this doesn’t seem too complex, but really most of the burden is on whoever comes up with a system. People could then expect more predictability and fewer conflicts, which should encourage use. Plus, we certainly don’t want authors to avoid logical names because they’re afraid of unintended conflicts. The biggest thing authors have to be mindful of is the cascade (if they’re using more than one class on an element), nothing new.

    It’d be easy for a browser to ship with–or people could pass around–something like head[profile~="http://www.example.com/profile"] + body .-pfx-class-name { /* ... */ } for their browser’s default stylesheet without fear of inadvertently screwing up the wrong pages. Page authors could probably forego the formalities (e.g. simply use the class).

    P.S. I know XFN uses rel, but no one seems to have decided how different profiles interact there (e.g. rel="muse crush" is both, whereas rel="alternate stylesheet" is something new, not simply an alternate and a stylesheet). I could see problems popping up later, but I might simply be being pedantic.

    P.P.S. Redux, you’re everywhere, recently. Tryin’ to grow wings, eh?

    P.P.P.S. Gee, don’t I have it all figured out? :-p

  11. Functional, not structural.

    I think you’ve got the terms backwards. You are looking for functional naming, not structural naming.

    id="leftbar" describes the structure, whereas id="menu" or id="news" describes the function of the tag.

    I agree that a framework to follow could be good. If the benefits accrue to the author, then it is definitely a Good Thing. I’m not sure anybody else would necessarily benefit, nor even care.

  12. I agree and W3C posted Use class with semantics in mind.

  13. why stop here.. What about the actual file name of the stylesheet itself and its location in the directory structure?…

  14. I tend to use capitalized words for IDs and lowercase for classes. I do not know why though. :-)

  15. As nice an idea as it is, doesn’t it also make it that much more easy for people to rip off designs? Easier for everyone to understand, not just the people learning or the people using, also the people abusing.

  16. you got me thinking on a proper footer/header naming though. i guess i’ll post again soon with a link to the naming standards of an application my company is currently building. of course, just if you’re interested ;)

    obviously depends on the footer, but how about “copyrightnotice” for those cases where that’s all the footer contains. or “generalcontactdetails”.

    why stop here.. What about the actual file name of the stylesheet itself and its location in the directory structure?

    because URI’s are not meant to carry semantic meaning. users don’t interact with them directly. it’s up to the user agent to interpret them, act on them in a transparent way, and shield the user from even having to know what they are.

  17. Interesting comments and an interesting reaction from certain quarters both here and on And All That Malarkey. Funny, I didn’t realise that the choice of an element name was part of the creative process. Maybe I should put down my crayons and get out my dictionary… ;)

    I think that some commenters are being a little over-protective of their ‘art’. Does adopting conventions make design theft easier? Hell no, does <table> or <font>? Does it have other advantages? Hell yes. But if the idea doesn’t sit well with you, don’t use it.

    Still reading? …

    OK, as I’ve said about a billion times, I hate the idea of standardised ‘templates’ or xhtml layouts (unless as conversation pieces like ZenGarden). Content should dictate layout, not the other way around. I’ll tell you why we adopted conventions at Stuff and Nonsense.

    Firstly it speeds up development time by eliminating some of those mental ‘conversations’ that sometimes get in the way of creativity. Things like, “Ummm, now what should I call this?” … coffee… ciggie… “Ah, I know!” It means that we can get on with designing rather than having brain-numbing code naming thoughts.

    Secondly, it allows us to work from a common denominator with makes editing easier. Particularly when coming back to a site after a period or (more usually) when several members of the team work on the same project.

    Lastly, it just ‘feels’ more organised. Just like cleaning the KFC wrappers from your car, or organising you bookcase.

    Now if in doing this, we make our documents more logical, more like XML, easier for users to customise, easier for newcomers to CSS to understand when they delve into our code, that is great too.

    Whatever floats your particular boat. :)

  18. Whatever floats your particular boat

    mine doesn’t float, it’s positioned absolutely on top of the water…

  19. I have to second Andy Clarke’s thoughts, with respect to my earlier trackback: if I always use #wrapper for a wrapper div, #header and #footer for those respective divs (or #masthead or #mast for the header), #content for the main content div, and #rail for the navigation as bases for my design nomenclature, then I can stop worrying about naming other divs in a purely semantic manner, which releases me to create whatever my little heart desires. Any further nomenclature can be taken care of in the nauseatngly detailed “Care & Feeding” packet left with the client. It makes my support easier, it makes their eventual redesigns easier — everything.

    This is also why I wrote at CSS Voyeur that I will use this particular nomenclature convention because I know that even if the client should later hire a former publisher (rather than a programmer, and there are wuite a few of them!) as a web designer to update and recode my page, that he/she will understand — and immediately recognize — the nomenclature system.

    Programmers (and I am one, as well) have this tendency to call things whatever they want, regardless of the clients’ standards; this is what I think Eric is driving at, and what, as developers, programmer and designers, we all should be driving toward: it makes no sense to leave others out of the loop to secure our own… well… security.

    What I admire and respect so much about Eric — and this is especially evident when I have been with him in groups — is that he is almost overwhelmingly concerned with including everybody in the group process, even at the risk of losing the empahasis of topic of the meeting. It’s downright inspirirational.

    Long story short: we need to consider everyone, not just ouorselves…

  20. My God, I *hate* this replacement keyboard!! ;-)

  21. [I]f the idea doesn’t sit well with you, don’t use it.

    That’s the problem. It’s one thing to adopt a naming convention–and even invite others to use it–but, by suggesting that people make assumptions on these conventions, you’ve essentially reserved those names.

    Some names might be applicable in other situations, or by people who don’t wish to have their pages re-styled. :-)

  22. Trackback ::

    bufferoverflow.com

    semantic identifiers
    Eric has brought up a good point for establishing naming conventions. I have always used a (self) standardized set of naming conventions, but they are descriptive in a presentational sense, not structural.

    I’m not sure where I stand on the issue. …

  23. i understand the basic idea that eric is trying to convey here, and i think he’s right to a point, but it risks being too rigid, if you ask me. the idea is good that things should match up, but maybe we need to think of a naming convention that makes sense to the project and the layout.

  24. I know I’m a bit late on this thread, but got here from links in Thorsten Scherlers OSCOM04 proposal (http://www.oscom.org/events/oscom4/proposals/skins). I’m suprised no-one’s mentioned here, or on malarkey, that there’s at least one limited css naming convention, the one in the portlets specification: http://www.jcp.org/aboutJava/communityprocess/final/jsr168/

    eg “portlet-section-header Table or section header”. Portlets have a need for some conventions as you’re embedding content from one webapp into another. This isn’t just a java thing – it originated in the WSRP TC:
    http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrp
    … I’m not sure how set in stone that all is, the WSRP lot appear to have dropped CSS from their spec in favour of contextual selectors.

  25. Trackback ::

    My mental mirror

    Is a developer an end user?
    I recently found a discussion on structured naming conventions (continued on meyerweb.com.) The whole discussion was about how structure the names of elements should be put on a web page. One comment made by Johan Sand on And all that…

  26. I thought the idea was to create clean html that is structurally sound to convey the content without depending on CSS (or javascript) and to keep the markup as free of extraneous clutter as possible. It seems wrong to denounce old-school ‘tag soup’ at the same time we’re creating attribute soup. (is it justifyable because we’re following a convention)?
    If browser support would improve enough to allow CSS developers to fully utilize (existing & new) selectors, there really is no argument for dozens of reserved design/layout keywords. Of course creating clean markup is harder than it sounds, but the up-front effort is usually worthwhile when the content is later re-purposed through different media or to new consumers.

  27. Pingback ::

    Max Design - standards based web design, development and training » Blog Archive » Some links for light reading (28/6/04)

    […] ome links for light reading (28/6/04)

    June 28th, 2004
    Fluid Shadows Structural Naming Integrated Web Design: Strategies for Long-Term CSS Hack M […]

  28. Pingback ::

    Lorelle on WordPress » More Website Design Mistakes

    […] f and Nonsense’s “What’s in a Name? Part 1″ and Part 2, along with Eric Meyer’s Structural Naming, […]

  29. Looking around the web, the question of naming conventions was kicked around for a while a couple of years back, but appears to have gone quiet. Maybe css frameworks are the new hot topic.

    However, as a keen user of Ruby on ~Rails, it seems to me that there is a strong case for revisiting css naming wrt RoR structure. I have been giving it a bit of thought recently and there is good scope to fairly tightly couple css names wtih for example the use of RoR elements such as partials and layouts. eg if my view contains a partial for customer, then it seems to make sense for it to be in a div with an id of customer.

    Taking this further, I have played around with targetting elements using nested ids, so that my partial might have an id of customer, but it could appear in different views. So if I have a view, say sales which includes customer, should my sale be a div with an id of sales so that I can specifically target div#sales div#customer. This seems to fit with having a generic customer presentation, but allowing it to be easily adjusted depending in which view it is included.

    I think it there is a great opportunity for some conventions to be developed for CSS with RoR.

  30. I (now) use standards-based (semantic) naming conventions for a variety of reasons, not the least of which is to save time (for automation) when creating a new site.

    Also, nobody seems to have noticed/mentioned that “header” (and “footer” as well, although with less potential problem) implies a position on the page rather than content and is therefore not technically semantic. I can see where it might be advantageous to use the “header” along the left (or heck, even right) side or who knows where on a more artistic site.

    I like to use “nameplate” instead of “header” since it semantically includes all the important ingredients name/logo/graphic/subtitle (see publishing naming conventions). I use “masthead” for supporting pages, such as those in a login screen or a form where you don’t want or need all of the parts of the nameplate. “Header” is absolutely no good in my opinion because it is presentational as well as too similar to the “head” tag. The use of “header” by a majority of websites tells me that there is still too little deep understanding/application of the web standards.

  31. Looking around the web, the question of naming conventions was kicked around for a while a couple of years back, but appears to have gone quiet.

    Tony, I have spent the last few days researching for a large UI revamp project and you are right, there seemed to be a lively discussion around these issues that stopped around mid 2005.
    I too am going to investigate some of the new CSS frameworks, but wrt your “customer” naming idea, I think you are on to something. Combined with a body id tag that kind of convention could be quite powerful.

  32. Pingback ::

    deshock.com » Blog Archive » A WordPress Theme Structure with Meaning and Possibility

    […] thinking about the whole topic of naming and structure check out What’s in a name (pt2) and Structural Naming. These two posts are 4 years old but still […]

  33. Pingback ::

    Structural Naming Convention in CSS - Six Revisions

    […] Structural Naming […]

  34. Pingback ::

    Theodicius » CSS and the meaning in presentation

    […] was a time when I was fully in agreement with Eric Meyer on the naming of classes. It made sense to me to create CSS class names based on the structure of […]

  35. Pingback ::

    OpenOn website - davidgswain.com

    […] am again standing on the shoulders of giant’s regarding the markup, and in particular and keen to adopt […]

  36. Pingback ::

    CSS: Estructura Vs Semántica . Como nombrar las diferentes partes de mi web | Timersys

    […] and HTML5 2. Standardizing CSS class and id names 3. User interfaces and CSS Naming convention 4. Structural naming 5. Smart CSS Ain”t Always Sexy CSS 6. Semantic coding 7. Semantic naming conventions for HTML and […]

  37. Pingback ::

    OpenOn website

    […] am again standing on the shoulders of giant’s regarding the markup, and in particular and keen to adopt […]

  38. Pingback ::

    CSS coding: semantic approach in naming conventionWeb Host Colorado | Web Host Colorado

    […] and HTML52. Standardizing CSS class and id names3. User interfaces and CSS Naming convention4. Structural naming5. Smart CSS Ain’t Always Sexy CSS6. Semantic coding7. Semantic naming conventions for HTML and […]

Add Your Thoughts

Meyerweb dot com 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>

if you’re satisfied with it.

Comment Preview