We all follow naming conventions in programming languages, don't we? Now, what about CSS? Is there any need of naming convention in that? Of course! Maybe not in a small project, but when you start working on large projects you should organize your code properly so that anyone can easily get the gist of the functionality by just looking into the code.
Great codebases don't need comments.
What is BEM?
BEM stands for Block Element Modifier. It is a Methodology that every web developer should follow. This makes development easy and enforces re-usability.
Enough of the theory Let's understand this by an example 😉
Here We can say,
- Form = Block(An Independent meaningful entity)
- Input, Link, Button = Element(Part of Black, Which has no standalone meaning)
- Button types (primary/secondary) = Modifier(Represent state of Block or Element.)
BEM Methodology
Let's continue with the above example. This is how you will name your CCS classes.
For Block:
.form {
// Your CSS
}
For Element:
.form__input {
// Your CSS
}
.form__button {
// Your CSS
}
.form__link {
// Your CSS
}
For Modifier:
.form__button--primary {
background: "blue";
}
.form__button--secondary {
background: "green";
}
NOTE: When using modifiers you will put all the common styles in form__button so that you don't repeat them again
And here is how your HTML will look like:
<form class="form">
<input type="email" class="form__input" placeholder="Email">
<input type="email" class="form__input" placeholder="Email">
<button class="form__button form__button--primary">Login</button>
<button class="form__button form__button--secondary">Signup</button>
</form>
That's it! I know it looks like an overhead but trusts me it will help you a lot in many different ways.
Top comments (15)
Agree. This methodology becomes more interesting and simple when using SCSS tho.
Agree!
Is an incredible SCSS superpower.
BEM is the worst of all.
No Offence Victor, But can you explain why?
BEM claims to fix a lot of organisational problems of CSS codebases, which is true, but it also creates tons of new problems which at the end are for the worse. I would be able to go deeper in this topic, but let me just highlight a few points.
BEM has a lot of rules which are not trivial to understand correctly at first sight. It's definitions of blocks/elements are debatable, and that's the reason every person understands BEMs rules a little differently, using it in their own flavor. This creates problems in teams, especially on a bigger scale. I've participated in and seen a lot of reviews the past decade on codebases using BEM arguing about the correct naming, structure, and selectors.
BEM requires deep knowledge of the codebase, otherwise people start reinventing already existing parts. This is true in general to well agrd code, but in BEM's rule-system individual pieces can hide well let's say. I don't know how to express this more clearly :)
BEM needs extra brainload which makes the process of site-building inefficient. It simply blocks the flow.
BEM is kinda immutable. By that I mean that it's hard to refactor. The structure and rules force a "non-flexible frame" around your codebase.
The mess and unreadability of the classes, and the 32 character long selectors at the end it's just the tip of this iceberg.
BEM simply has significant negative impact on productivity, and at the end it's not as maintainable as it claims to be.
Most people usually like the Modifier part of BEM, but that's not new or unique to BEM, only the double dash maybe...
To add something constructive to the table. I believe in those modern CSS-in-JS solutions that completely remove the overload caused by naming selectors, can do static-extraction for critical CSS, and uses a utility-class (1 rule per class) based approach to enable significant size savings on large codebases.
Hey, thanks for the reply..
I have worked in multiple enterprise level projects and My colleagues and I never faced any such issues..
But yeah! Thanks for sharing your insights :)
I prefer BEM a thousand times over CSS-in-JS, it's like going back to the past, messing up all the code. Each one in its place.
Besides, you have to use some methodology, either you create it yourself or use a ready-made one, such as BEM, going crazy is not good, not to mention diving into the past with CSS-in-JS. Anything *-in-JS is no good, so you can use the same CSS in any other non-React application.
I don't like methodology that much. The worst part of methodology is it counts on the reliability of human. And i believe that human will make mistakes. I mean we are good at creativity, not following conventions.
Just let machine take care of that boring part.
BEM is understandable but sometimes names of css classes become too long. Imagine naming an element which is 5 levels deep in your markup and even worse, having modifiers. How will you name a class for that element?
You only need BEM if you don’t understand CSS specificity. If you namespace your components correctly you don’t need that convoluted naming, especially when using SCSS as it will write the long selectors for you. There was an argument at some point saying single classes were faster to read and render but right to left CSS selector optimisation is pointless with modern browsers.
would definitely try this , though it looks to add more complexity to an already complex css
I've tried BEM and I must say I prefer something like CSS/SCSS modules.
The scoping is built-in at a component level and the classes are much more readable.
BEM fixes some problems but it is really tedious to write, that's why I try to avoid it if I can, CSS modules/styled-components are much easier to work with.
nice cover photo btw
BEM is bad, it doesn't fix any problems, but at the end, the class names of the element are longer that the content inside it. You didn't say what are the advantages of using it.