Structural Naming
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.
