SMACSS, which stands for Scalable Modular Architecture for CSS, is detailed fully in Jonathan Snook's book on the subject (https://smacss.com/). I'm not going into detail about SMACSS here as I think you should go and check that book out for yourself. Reading SMACSS gave me plenty to chew over as I faced my own challenges and I certainly took things, such as how to think about state changes, from it. However, I will detail why SMACSS didn't work for me.
Again, like my caveat regarding my opinions on OOCSS, this isn't a critique of SMACSS. It's simply highlighting the parts that didn't work for me and why I felt it failed to solve my own problems. SMACSS has clearly defined terminology and concepts for the visual aspects of a website. It therefore prescribes base, layout, modules and optional theme rules/files to support these definitions. For example, consider this suggested file structure:
+-layout/ | +-grid.scss | +-alternate.scss +-module/ | +-callout.scss | +-bookmarks.scss | +-btn.scss | +-btn-compose.scss +-base.scss +-states.scss +-site-settings.scss +-mixins.scss”
Excerpt From: Jonathan Snook. Scalable and Modular Architecture for CSS.
While these definitions make perfect sense in many scenarios, they didn't for mine. I wanted an approach that was looser, an approach that didn't make me need to consider fitting what I needed to build into those visual definitions; the applications I was building and maintaining often defied adherence to those definitions.