This last week, I started converting a prototype application into some really clean XHTML and CSS. As I was doing this, I kept finding it hard to choose the most appropriate CSS class names. As I started to get more frustrated, I was reminded of OOP guru, Hal Helms. In the past, both in presentations and in face-to-face conversation, Hal Helms was always talking about, "What does it mean to be an object?" This thought exercise helps one to build better objects by really digging deep into what objects should know about themselves and what other objects they should be extending.
As I was coming up with these CSS class names, I couldn't help but draw parallels between OOP classes (or ColdFusion components) and CSS classes; both of them represent general and specific "definitions", HTML elements can use multiple classes just as objects can inherit from multiple super classes, and the more poorly thought out either is, the harder it is to scale and extend your current code base.
And so, just as Hal Helms is always asking, "What does it mean to be an object," I started asking myself, "What does it mean to be a CSS class?" I found that this mentality forced me to move past the problem right at hand, and successfully focus on solving systemic problems and aiding in future-proofing the code. To give you an idea of what I am talking about, here are some questions that I started asking myself:
- Is this HTML element going to be used elsewhere? If so, can I come up with a general name for it's functions? For example, a table with the class name, "book-list", is very specific. A table with the class name, "data-grid", still describes what kind of layout it is and is much more general and more easily repurposed.
- Does this element have the behavior of more than one type of element? For example, a link that has a plus-icon background image might get the background image from a class of links labeled, "add-item", and also get the layout from a class of links labeled, "intra-page-form-trigger".
- Might this element have a contextual meaning? For example, could a Div with class, "Note", have a different meaning depending on where it is (ex. at the top of a page, in an email, in a data grid, in a data intake form)? If so, it's possible that this item should not have a global class name, but rather should only be defined as a contextual class name.
- Might this class name need to be overridden? If so, then we have to start thinking about specificity and how to build general, base CSS rules that can easily be overridden with more specific rules.
- Could this element benefit from a CSS class name that has no layout implications, but would provide nice programmatic hooks for something like jQuery? If so, then perhaps it should use two classes: one class for layout issues and one class for the programmatic hook.
This is not the exhaustive list of useful questions, but when you really start to dig deep into the existential meaning of CSS classes, I think you will find that you start to come up with better CSS class names. You also realize that highly specific names like, "event-overdue-alert", probably are just not well thought out and can be replaced with more universal names like, "alert", that might have a contextual meaning (ex. "alert" classes found within tables of type, "event-list", have a special alert color).
In addition to helping define better CSS classes, I felt that this mentality also helped create a more consistent interface. If you have what you believe is a really solid set of well thought out classes and then you find an interface element that doesn't seem to fit in anywhere, this might be a big red flag; is this new element an inconsistent element in your application? Could this new element be tweaked to fit into an existing CSS class? Coming up with a really good set of classes is almost like providing a set of OOP interfaces; you're saying, This is what the application should look like, and then you have the responsibility to code to that interface.