SMACSS/BEM edge case naming convention
What do you do in cases where BEM methodology fails?
At Synapse Studios we use Facebook’s React javascript library for building our user interfaces. If you are not familiar with React, it allows you to break up your websites into small reusable components to create an atomic system. The point being that React, with help of the shadow DOM will only re-render the specific components of the system that have changed. It is a really powerful and fun to use library which we are enjoying immensely.
To compliment React, we use a slightly modified combination of SMACSS & BEM methodologies. This system has proven to work out quite well for us and we continue to refine it as new situations arise. Sometimes there are nagging issues in our SASS architecture that require some attention but so far have been unable to come to a consensus on. This particular issue we were hoping to get a little discussion on as it is a particularly hard one for us to figure out.
You probably already know that BEM stands for Block Element Modifier. And that the overlying structure of BEM follows this syntax:
.block__element—modifier
There are times, however, that this syntax seems to fail. Most notably is the when the block needs to have an element wrapping it like so:
You may be thinking, “no, dummy. The wrapper is the block.” Well typically I’d agree with you but we have run into a case where that argument doesn’t stand up. When your block element is also a defined html element, you would not want to follow the typical BEM syntax. Here is an example:
That example follows BEM architecture correctly. But what if we needed to wrap this block in a wrapper? The syntax might look something like this:
That solution breaks the BEM methodology but it makes sense in practice. It would be much less desirable to name ‘.input__wrapper’ ‘.input’ and the actual input ‘.input__input’ or something else equally ludicrous.
So we’ve decided that the wrapper should be follow BEM but should have it’s own naming convention to denote that it is essentially the parent of the actual block. After scrapping a few lesser ideas, we’ve decided that this warrants its own separator characters just like ‘__’ & ‘—’. But what could these characters be that are still within CSS3 spec and don’t conflict with currently available selectors (‘&’, ‘^’, ‘~’, ‘+’, etc.)?
Right now we are using a single hyphen in these edge cases but are convinced that there is a better solution. If you have a good (or even mediocre) solution to this share in responses. We would really like to hear some other opinions.
Ryan Canfield
User Interface Designer & Frontend Developer
Synapse Studios
