A
A
Alibek Kulseitov2017-10-09 00:02:52
css
Alibek Kulseitov, 2017-10-09 00:02:52

Relevance of BEM prefixes l- b- h- g- js-?

I’m typing on bam without prefixes, but I came to the conclusion that it would be more convenient with prefixes.
Googling came across this Question about prefixes in BEM?
The answers are controversial. No one gave such an answer.
One young man wrote there that the Bamers moved away from prefixes. Where does such infa come from?
How are things going with prefixes now?

Answer the question

In order to leave comments, you need to log in

2 answer(s)
I
i, 2017-10-09
@AlibekKulseitov

From the history of BEM development https://ru.bem.info/methodology/history/
real
If prefixes solve your problem, then you should use them.
Additionally, I will quote the note "Why CSS modules cannot replace BEM" :

I often hear developers say “BEM is not needed, because there are CSS modules”. This is not true.
The root of this misconception lies in the fact that people perceive BEM as a CSS methodology. In fact, BEM is a set of universal principles that can be applied regardless of the technologies used, be it CSS, Sass, HTML, JavaScript or React. BEM solves many problems, including CSS class naming, the approach to separating the interface into independent parts, and isolating styles for these independent parts.
CSS Modules is a tool that only solves the problem of style isolation. All other problems remain unresolved: you still need some rules to separate the interface into independent parts, and you still need to come up with class names. Therefore, CSS modules can and should be used together with BEM.
The evolution looks like this:
/* Классический БЭМ с длинными именами классов для обеспечения изоляции */

.shop-cart-button {}
.shop-cart-button_size_small {}
.shop-cart-button_size_large {}


/* CSS-модули с неограниченной свободой творчества в именах классов */

.button {}
.small {}
.large {}
/* или */
.button {}
.is-small {}
.is-large {}
/* или */
.button {}
.size-small {}
.size-large {}


/* БЭМ и CSS-модули */

.button {}
.button_size_small {}
.button_size_large {}

I will immediately answer the question “why is the example with the .button, .small and .large classes bad?”. It's bad in that the .small and .large classes themselves don't carry information about what they refer to. It is not clear whether they are styling a single element or describing the state of an existing element. Also, such class names will sooner or later again lead you to the problem of uniqueness of names. For example, you are writing styles for a modal window. You need to style the translucent overlay on top of the page and the modal itself. Both of these elements can be in two states: visible or hidden. The .visible class seems to work great, but the problem is that for the overlay and for the window, this class must contain different styles. You can think of a hack in the form of the .overlay.visible and .window.visible selectors, but that's just a hack because you're increasing specificity.

P
Pavel Gogolinsky, 2017-10-09
@gogolinsky

Prefixes are relevant
https://ru.bem.info/methodology/naming-convention/...

Sometimes different prefixes can be added to block names.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question