Designer News
Where the design community meets.
↵
CSS Guidelines—High-level advice and guidelines for writing sane, manageable, scalable CSS(cssguidelin.es)
over 5 years ago from Matt Achariam, Intent Renderer
Jim Silverman, over 5 years ago
again, problems arise when you start nesting willy-nilly. not a good idea to go more than a second level deep.
what i'm saying is ".block element.modifier" instead of ".block__element--modifier" this results in much cleaner code in both CSS and HTML, is easy to maintain, completely modular and is barely tied to structure.
it seems the only tangible advantage of BEM is, as you've stated, the freedom to change html elements used. though i've rarely had a need for that.
Hamish Taplin, over 5 years ago
I wouldn't describe that as 'cleaner' at all as it's unnecessarily specific and inherently less re-usable. What problem does it solve?
With regards the first issue, the point is that you're tying your CSS to the elements you've used and, even worse, their structure. This isn't re-usable without changing the CSS every time you want to use those styles elsewhere and doesn't follow the principle of separation of concerns.
For example, you may wish to use divs instead of a ul — you then have to add an additional rule to your CSS which add complexity. What happens if you, further down the line, want to style some spans in the same way? Again, another rule. If you just use classes your separating the style from your markup where
.menuand.menu__itemcan be used with any markup.I can understand why the syntax of BEM puts people off—I was the same at first. However, I tried it on a few projects and I would never go back. It solves so many problems with specificity and increases modularity so much that it become really obvious once you start using it. You don't even have to use BEM syntax—just the principle of OOCSS is enough (eg. the way Bootstrap is written).