What Does It Mean To Be A CSS Class?
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.
Reader Comments
In Might this element have a contextual meaning? you say 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.
I would go one step further and say stick with generalized css classes like "note" "body" etc, and then allow css inheritance to do it's magic.
.post .note is one css definition.
.comment .note is another.
what about needing to add microformats? esp in div's?
different raison d'etre, same tag attribute.
Just wanted to chime in real quick in regards to javascript and css ...
As for using classes to provide javascript hooks, that should be done with ID's and the javascript function getElementById. Its easy to traverse nodes in the DOM once you have your root node which can be accessed via ID. Classes should be used for CSS purposes only, more specifically styling purposes, not behavior.
If you start to use css, the standard for styling, for behavioral purposes, your going to confuse your designers and developers at some point in time. Stick to the standards and appropriate conventions.
@Terrence,
I agree with this idea.
@Barry,
Can you explain more? I think maybe you are referring to a contextual formatting issue. Take a look at Terrence's comment.
@Britt,
While I see what you are saying as far as IDs vs. Classes, what happens when you need to apply the same Javascript behavior to multiple items on one page. For example, if you have a data grid and want to allow client-side sort of the columns, some of your TH elements might have have the class "sortable-table-column". Then, using jQuery, you could find all those and hook up the scripting.
This sort of behavior would be a pain when restricting to IDs.
@Ben I agree with you re: @Britt's statement.
It is more than likely a lot better performance to simply check the DOM for an 'id', but searching/traversing for 'class' can be invaluable.
what I'm getting at is the conflict between needing to add semantic context on one hand and styling and behaviors on the other.
out of the available "tools" there's only ID's (and like Highlander "there can be only one") or classes.
Some examples: http://microformats.org/wiki/hcard-authoring)
I'm just saying that, when naming classes there's semantic meaning AND formatting (or behavior) to consider, and they may just end up competing for a name (or it becomes a real pain to give semantic meaning and then style it)
personally, I'd like to see semantic context not use the class attribute at all (and have something it's own), but it's too late now.
@Barry,
I see what you're saying. I have become a big fan lately of using multiple class names. I find that this has helped to clean up some of the crazy naming conventions that I have had in the past.
But yes, semantic context is awesome. The only problem that I can see with it is that when you have styles that are based on anything more than two or three nested rules (ex. table tbody td), things become MUCH harder to override down the line because in order to be more specific, you need to include a lot of stuff. But, I think that is just part of the overhead of making things semantic.
Ah so showing you my CSS Framework has brought this? Well done! A lot of people don't give classes enough credit if you ask me. Libraries like jQuery simply make this type of development fun! Glad you are getting into this area as its something I've been dealing with since last year.
One of my fellow co-workers has a new book (or at least its new to me) called CSS Design Patterns. I just noticed it today and picked it up to see what its about. After seeing what you are touching up on in here you definitely want to check it out.
http://www.cssdesignpatterns.com/
http://www.apress.com/book/view/1590598040
@Javi,
That looks like a good book. I will check it out. Definitely, your CSS work has inspired me.
Don't forget you can reference multiple classes on the same element with the same css selector.
class="alert overdue"
.alert {display: block; border: 2px solid black;}
.alert.overdue {border-color: red}
Patrick
@Patrick,
I really like that, but I think that has some problems in IE6??
@Ben
I'm glad it has. Honestly, I've run out of ideas and I've gotten so much inspiration from Flex. Although now I'm doing Flex work I have to get back into the swing of things CSS wise. If you will be blogging more about this I'll have a lot of interest! So keep it up!
@Patrick/Ben
Yeah unfortunately IE6 does have issues with that. :( Until IE8 comes out this year (fingers crossed) we can honestly say goodbye IE6. For now wht I've done is keep things a lot simpler. I'll just have an .alert class defined and then a separate .overdue one. How you use it is up to you rather than restrict to just one class.
As an example what I do with a list of checkboxes that I want it to replace the non-user-friendly multi select is a collection of classes: selection, scroll, (small/medium/large), and then multiple if I want to sprinkle some JS behavior. Loving being able to add multiple classes. It's a powerful feature.
Yeah, adding multiple classes is definitely badass. I wish I had known about this feature a long time ago.