BEM is Block, Element, Modifier.
A class naming convention. In this CSS methodology, a block is the top-level abstraction of a component, such as a button: .btn { }. The block here should be regarded as a parent, child items or elements, which can be placed inside the block and then indicated by adding two underscores after the block name, for example: .btn__price { }
Finally, modifiers can be used to operate blocks, so that we can style specific components without affecting completely unrelated modules. Modifier is represented by two hyphens (hyphens) added to the end of the block name, for example: btn--orange.
If another developer writes this markup, and we are not very familiar with CSS either , we still have a good way to distinguish which classes are responsible for what and how they depend on each other. Developers can then build their own components or modify existing blocks to build what they want. Without writing too much CSS, using these classes in markup, developers can easily create many different combinations.
Why should we consider BEM?
Designers and developers can name components consistently, because communication among team members becomes easier. In other words, BEM gives each project member a syntax description, so that everyone can understand it more easily and share it with each other.
So, if a developer can work more confidently on a project, then they will be more confident in making smarter decisions about how these visual components are used of. For these small ailments (diseases), this methodology may not be a perfect solution, but it must give developers a standard for how to write better and more operable code in the future.
Another smart part about BEM is that everything is a class and nothing is nested. This makes the CSS features very flat and single , this is a good idea. This means you don’t end up fighting against yourself over this difference.
Let’s take a look at some issues related to BEM.
Problems with BEM CSS
Of course, no one will twist you if you break the rules of BEM arm. You can still want to write a CSS selector like this:
This code looks like only part of BEM is going on, but it's not BEM. It has nested selectors, and the modifier doesn't even describe exactly what's going on. If we do this, we destroy the flatness feature that is so useful in BEM.
A block (eg: .nav) should never override the styles of other blocks or modifiers (eg: .btn?orange). Otherwise this would make it possible to read almost the entire HTML and make it unclear what the component does. In the process, we will inevitably shake other developers' confidence in the code base.
If you see the markup below, what do you think?
The problem here is that an element in a complete block has the code that the developer needs, but the child elements are not like Like its parent, it requires a .nav class, which results in an extremely confusing and inconsistent code base. This should be avoided at all costs. We can summarize it into the following two issues:
More examples of BEM in action
Accordion demo
In this example, there is a block, two elements and a modifier. Here we can already create an .accordion__copy?open modifier to let us know that we cannot use it in other blocks or elements.
Navigation demo
This navigation demo has one block, 6 elements and 0 modifiers, and it is completely It is possible to create blocks without modifiers. At some point in the future, the developer can always connect to new modifiers because the block will remain unchanged.
Dislikes of BEM
Maybe you don’t like dobule-underscores or double-dashes. No problem, use any other special characters you'll stick with.
Sass and BEM
You can continue to enjoy nested Sass writing, but you can use @at-root to get non-nested CSS.
Summary
To wrap things up, I think it’s fair to say that although BEM doesn’t solve all of our problem, but it's still very useful for creating scalable constructs that maintain interfaces where everyone on the team should have a clear idea of how to improve code quality. This is because a huge front-end development isn't just about solving a small problem with nice tricks in the short term, we need protocols, pormises and binding social contracts between developers so that our codebase can adapt to changes over time.
Original text: https://css-tricks.com/bem-101/
https://css-tricks.com/strategies-keeping -css-specificity-low/
example:
Copyright Statement: This article is an original article by the blogger and may not be reproduced without the blogger's permission.