SMACSS vs BEM and the cascade

[pdaoust]

I'm very curious about your comments on SMACSS and BEM, especially as concerns the cascade. I've been trying to avoid descendant selectors for a while, because I've been bitten enough times by their specificity. I agree that .slider__figure--is-active is ugly, but you won't ever get into specificity battles... What sort of specific problems have you bumped up against with BEM? You mention it messing up the cascade; curious to hear more about that.

I'd also like to hear your thoughts about SMACSS and things like .pod .pod-body.is-active, which (while it might create specificity hell) looks quite pleasant to me.

[timkelty]

SUIT has gained a lot of traction recently as well, which uses a slightly altered, BEM-inspired naming scheme.

Initially I had reservations about these methodologies simply because they were "ugly", but after using them for some time, it has become a non-issue for me.

They're ugly because they're injecting rules and meaning into strings any way they can. You could argue SMACSS is less ugly, but that's because it much less meaning to convey by the convention.

For me, its far more important to follow a meaningful convention that it is to keep things lowercased and hyphenated "cuz that's how i like it". If you're not that way and really don't like these types of naming schemes, something looser like SMACSS might be appropriate, but just know, you may be giving up levels of meaning for code style preference.

After using SUIT for some time now, I've decided what the actual naming schemes are or look like doesn't really matter to me, just that they exist.

[scottkellum]

@pdaoust BEM doesn’t mess up the cascade as much as it side-steps it. It avoids a lot of issues on larger sites and I use it at work. SMACSS style where the modifier is its own class allows that modifier to be used in more places. This allows for slightly DRYer code while increasing maintainability risk. Personally, I love the more fluid and re-useable nature of the SMACSS style and experiment with new ways of approaching the cascade to write clean and small CSS files.

To make an analogy, BEM is like slow and careful driving that will get you there with no problems. Sometimes I like to push the limits and on big projects you’re likely to find yourself upside down in a ditch. The cascade and specificity are really powerful tools that we all have been burned by, but there are some really elegant and interesting things you can write with them.

[Snugug]

The goal when I wrote North's Styling Guidelines was to be able to combine the precision of BEM with the reusability of SMACSS. That's what I use. That being said, this is an interesting discussion, but not sure if this is the correct place for it as I believe this project is dead in favor of other projects (North being my go)

[pdaoust]

@Snugug awwww, but 'SUCKS' is such a better name than 'North' ;-) Anyhow, thanks for the tips, and @scottkellum thanks for clarifying the 'BEM and cascade' thing. Very eloquent words on specificity too.

I'm already familiar with Nicolas Gallagher's SUIT and really like it. It takes the best of BEM -- avoiding specificity battles, introducing a consistent naming convention -- but (in my opinion) makes it prettier and simpler.

I rebuilt our stylesheets in a (slightly modified) SUIT style, but when a new front-end dev came on board I realised that, for us, it was adding cognitive friction without a lot of benefit. Now we still stick to the SUIT rules on separation of responsibility and low specificity, but we use words-and-hyphens. Well-crafted names can, 90% of the time, convey just as much meaning as stricter rules; e.g.:

.inventory-item { background: #EEE; }
.inventory-item-on-sale { background: #FFC; }
.inventory-item-price { color: red; }

conveys just as much info about the hierarchy of components as does:

.InventoryItem { background: #EEE; }
.InventoryItem--onSale { background: #FFC; }
.InventoryItem-price { color: red; }

The remaining 10% wasn't enough for us to worry about.

Anyhow, @Snugug I'll read the North documentation and continue the conversation there if I have any more thoughts and questions.

[danielsokolowski]

"...it was adding cognitive friction without a lot of benefit..." this is a nugget of wisdom I agree with based on my own experiences, mental friction I call it. This and 'keeping thing simple' should always be kept in mind. Starting developers have a tendency to overbuild and end up introduction unneeded layers of complexity - sorry a bit of topic but a Google search has led me to this page.