It's been awhile, hasn't it? I've been hoarding links like a squirrel preparing for winter. Thankfully, winter is almost over. (We'll just ignore the 20cm of thick, wet snow that fell yesterday here in Ottawa.)
Modules in Context
A topic that has come up via Twitter and also the workshops is how to handle naming things in the context of something else. Let's take a look at an example:
First you need to define the module. If you have a box, then .box is the module. Your module may have HTML elements within it that are part of that container. In this case, your box may have a header. I would name it .box-header. If you wish to style the module based on a specific context—for example, when the box is in the header—then you should come up with a module name for this context-based variation.
Naturally, you might think .box-header (again, based on the SMACSS naming convention). Of course, that conflicts with the .box-header you already made. You could use a different naming convention that clarifies this. Maybe module variations (aka submodules) use a single hyphen and child elements (aka subcomponents) use double hyphens. That would be .box-header and .box--header.
But the more important point that I'd like to mention is that you should avoid using a naming convention that styles based on context. Otherwise, why not just use .header > .box? There'd be little difference. If the submodule was called .box-header and you decide to use it in the sidebar, the name you chose suddenly feels out of place. Try to define what the variation means. Are you trying to give this box added importance? Is that why it's in the header? If so, then maybe calling it .box-important is better.
I did say I was going to share some links, didn't I?
On the subject of naming convention, I came across an approach to naming convention as laid out in the Montagejs project. The module names (or components, as they call them) use camel case, allowing hyphens to be used to separate the library name from the module name from the subcomponent name. I like the use of camel case. I don't like too many hyphens and underscores and find the BEM approach harder to scan. To each their own, of course.
Another example of naming convention in Ben Smithett's style project which chooses to allow hyphens in module names, relying on double hyphens or underscores to separate chunks. Take .example-widget--is-somestate, for example. That's a lot of hyphens. Is examplewidget-is-somestate better? is exampleWidget-isSomeState better?
Lastly, I'll point you to Brett Jankord's Thoughts on semantic class names and maintainability.
Thanks as always for listening.
P.S. the SMACSS Workshop is coming to Breaking Development and CSS Dev Conf this year. I'll also be attending CSSConf if you'd like to chat and geek out on CSS!