Snook.ca
An interesting question was asked of me in regards to the SMACSS methodology:
Karl Tynan asked, “What do you do if you want to use the CSS from one module in another module?”
Not being able to see the design Karl was referring to, it’s hard to say exactly what I would do. However, I’m guessing one of two possible scenarios.
- Two modules—like a menu and a modal dialog—share some common traits; or
- We’re really talking about a single module with minor differences.
Two Modules with Commonalities
One would think that the purpose of modular CSS is to avoid the repetition of a batch of properties across multiple rules. After all, repetition is just another word for bloat. At least, that’s how we tend to equate the two.
When thinking about modular CSS, it’s not about the CSS that is modular, it’s about the design that is modular. Most designs are built from design elements that are repeated throughout the interface.
Just because your menus and your buttons share the same border radius and font size doesn’t mean those styles should be abstracted away into some third class that gets applied to both elements.
Taken too far, you’d be left with a single class for each CSS property and, clearly, that’s not practical.
Modular design is about separating the components of your design such that they can be re-used elsewhere with ease or that they can be altered with ease. (There are other reasons, too, which I talk about in the SMACSS book.)
In this case, I would code the CSS for each module in isolation. They may have some similarities and that is okay.
One Module with Differences
When do you know when you’re dealing with one module that just has some differences? Sometimes it feels like a case of “you’ll know it when you see it”. In actuality, I believe that the Great Semantic Debate obscures how we should name things.
What do I mean by the Great Semantic Debate? We’ve been convinced as an industry that we should avoid naming things “red-background”. It’s not very descriptive and creates a brittle system for maintaining your website. Not naming something “red-background” is a good thing!
Yet, we use naming conventions like nav and menu which don’t describe the content; they describe the container. They describe the design element.
What about a table of products? We’d probably use a class name of products, right? And then for the events table, we’d use a class name of events. What if they look mostly the same? We’d just bundle up our selectors.
.products, .events { }If these elements are mostly the same then we should use a naming convention that describes the commonality.
Unfortunately, this is where naming can be difficult. Do we use a class of table? That might be appropriate, although it feels a little redundant. Maybe matrix. Whatever you choose to use, the point is to use a single class to define the consistent pattern. Then the differences are codified in a sub-module.
.matrix { }
.matrix-minor { }In this case, if I had originally coded this as two separate modules, I’d bring them together under a single module.
Hard and fast
There are no hard and fast rules for recognizing when you’re dealing with one situation over the other. It may require discussion within your team to come up with something that works.
Article published by jonathan@snook.ca (Jonathan Snook) (This blog article was re-posted via RSS and all Rights Are Reserved to the original owners).
