It's an idea, it's a way of working, it's full of stars. No really, it's about Sass'd Up Consistently Killer Styles. OOCSS, SMACSS and BEM only take you so far. Let's turn it up to 11 and change the world forever!
Switch branches/tags
Nothing to show
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
.gitignore
LICENSE
README.md

README.md

#S.U.C.K.S.

####Sass'd Up Consistently Killer Styles

CSS Strategy is an important part of your front-end architecture. The first part of our CSS Strategy is the use of Sass for CSS Preprocessing. Sass adds so much for large scale maintainability that this is really a no-brainer. That’s the how, but what about the what? What are we going to be writing with our CSS Preprocessor? What’s our class naming strategy? This has been bugging us a lot. Right now, there are three prevailing thoughts on CSS strategy: SMACSS, OOCSS, and BEM. We dislike all of them. We find that SMACSS is too loose of a convention (that at times contradicts its own advice) to work at scale with a large distributed team. OOCSS stores all of its styling knowledge in the HTML instead of the CSS where it belongs, and is also pretty loose in its naming conventions. BEM’s conventions work against how CSS natively parses and frankly destroys the cascade, the one thing that CSS is excellent at. While we may not like SMACSS’s .pod .pod-body.is-active, we absolutely despise BEM’s .slider__figure--is-active. None of the current strategies really seem to cover architecture (the core pieces that make up your styling, think framework) and implementation (the details of a single site).

It’s not all fire and brimstone, though. We like that both SMACSS and OOCSS emphasize thinking in reusable patterns and that BEM has a visual way of easily distinguishing between different conceptual pieces that go into styling. We're also a fan of SMACSS’s recommendation to use a style guide, although it really doesn’t go into that much which disappoints me. That being said, pretty much all of these CSS strategies are built for writing vanilla CSS, none really utilize the power that CSS Preprocessors have to offer.

We’ve decided to work together to try and create a new CSS strategy that hopefully will solve the issues we have with those that currently exist. While it’s in the very early stages (we started working on this Friday, it will be a long journey), we firmly believe that we will get the best results if we can get some feedback on it while we work on it. We're especially interested in where people have pain points with the existing strategies and, where possible, what their solutions are.

So stay tuned, give us some advice, and together we can create a CSS Strategy built for modern front-end development.