A Workhorse with No Name
Naming a ubiquitous design pattern in CSS
There are only two hard things in Computer Science: cache invalidation and naming things.
— Phil Karlton
Naming things. It’s such a complicated matter. A name is never as simple as it seems at face value. From our children and pets to our folders and files, there are always deeper implications behind the name itself. What does the name mean? Where does it come from? What does it convey?
In HTML, the flexibility of naming classes and IDs is one of the features of the language. As selectors in CSS, it allows us to architect our styles and, more importantly, our design patterns in a way that works best for our project and team.
In Modular CSS, the class name is especially important. It needs to be generic enough that it is reusable, yet descriptive enough that its purpose is understood. It also needs to lend itself easily to extension while still being maintainable. This often feels like pushing while pulling.
Over the last few years, I’ve struggled with the class name for one of the most basic design patterns: The header-body-footer pattern. It is repeatable and ubiquitous. You see it in the core of an HTML document in the form of the <head> and <body> tags, as well as within the content itself as <header> and <footer> elements . In a web project, a majority of components are comprised of this one simple pattern.
In CSS, it looks something like this:
.module {…}
.module-header {…}
.module-body {…}
.module-footer {…}Dave Rupert created a more in-depth example of this pattern on Codepen.io
So, why not just stick with “module” and call it good? The problem, I’ve found, is that if you’re working with a team that thinks in terms of SMACSS, then everything is a module. Calling a module “module” is like naming your son “Boy” or your daughter “Girl”. It makes communication across the team difficult, lowering the shared understanding of the codebase.
In the OOCSS Framework, for similar reasons the name has been changed from “module” to “box”. There was even a discussion about it beforehand in the respective Google Group. Same design pattern, same intentions, different name.
My struggle with “box” is that it implies a bit more presentation than I would like, leaving itself open to subjectivity. Maybe the thing I’m building isn’t exactly box-like, but more column-like or row-like. Maybe the idea of things being in boxes doesn’t quite fit the design principles of the project.
Then what do we call it? Well that is the question. When authoring class names, I find it extremely beneficial to consider the module’s function or purpose. That allows the styles—the presentation—to change over time without needing to change the name in the markup—the structure.
However, a big part of what Modular CSS advocates is abstracting styles into classes based on visual patterns. This may seem like we’re violating the Separation of Concerns, but if you approach it in terms of Visual Semantics, then you understand that the way something looks is based on what it does. In other words, Form Follows Function.
In essence, header-body-footer is primarily a structural pattern for content. Think essays, articles, technical documents, etc. So, we could go with…
.content {…}
.content-header {…}
.content-body {…}
.content-footer {…}That separates structure from skin, but is a little too generic. Technically, it’s all content. Plus, we may not always use it for items intended as content (like utility items in the sidebar).
We might also consider…
.block {…}
.block-header {…}
.block-body {…}
.block-footer {…}…but that could easily get confused with the “block” value of the “display” property in CSS. Worse if “display” is set to “inline” or “inline-block”.
My proposed solution? I don’t have one. I’ve gone down the rabbit hole of philosophy and principles numerous times only to come up filled with doubt and frustration.
And that’s why I’m writing this—for input from the community on a name for this workhorse pattern. Have you abstracted it into a base class? If so, what name did you use to describe it? Or is it just a metapattern within our abstractions?
Leave a note with your insights or Suggest a link to your example.
Cheers!
