Актуальность префиксов БЭМ l- b- h- g- js-?

Question

[Alibek Kulseitov]

Верстаю по бэм без префиксов но пришел к тому что, с префиксами будет удобнее.
Погуглил наткнулся на это Вопрос про префиксы в БЭМ?

Ответы там спорные. Никто как такового ответа не дал.
Один молодой человек там написал то, что бэмеры отошли от префиксов. Откуда такая инфа?
Как сейчас обстоят дела с префиксами?

Comments

[i]

Вот еще вопрос про префиксы Что насчет JS в БЭМ (BEM)?

[i]

и бонус andrew-r.ru/notes/?go=all/bem-vs-css-modules

Answer 1

[i]

Из истории развития БЭМ https://ru.bem.info/methodology/history/

2005 год... Классам блоков мы добавили префиксы (b-, c-, g-), чтобы отличать их от внутренних классов...

Настоящие

Исторически они появились в переходный период для того, чтобы отличать новый код, написаный по БЭМ, от старого. Со временем мы от них отказались.

https://ru.bem.info/forum/158/ и https://ru.bem.info/forum/806/

Соглашение по именованию/Имя блока:

Иногда к именам блоков могут добавляться различные префиксы.

Если префиксы решают вашу проблему, значит использовать их надо.

Дополнительно процитирую заметку "Почему CSS-модули не могут заменить БЭМ":

Часто слышу, как разработчики говорят «БЭМ не нужен, ведь есть CSS-модули». Это не так.

Корень этого заблуждения кроется в том, что люди воспринимают БЭМ как CSS-методологию. На самом деле БЭМ это набор универсальных принципов, которые можно применять независимо от используемых технологий, будь то CSS, Sass, HTML, JavaScript или React. БЭМ решает множество задач, в число которых входят именование CSS-классов, подход к разделению интерфейса на независимые части и изоляция стилей для этих независимых частей.

CSS-модули это инструмент, который решает только проблему изоляции стилей. Все остальные проблемы остаются нерешёнными: вам всё ещё нужны какие-то правила для разделения интерфейса на независимые части и всё ещё нужно придумывать названия классов. Поэтому CSS-модули можно и нужно применять вместе с БЭМом.

Эволюция выглядит так:

/* Классический БЭМ с длинными именами классов для обеспечения изоляции */

.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 {}

Сразу отвечу на вопрос «а чем плох пример с классами .button, .small и .large?». Он плох тем, что классы .small и .large сами по себе не несут информации о том, к чему они относятся. Нельзя понять, стилизуют ли они отдельный элемент или описывают состояние существующего элемента. Также такие названия классов рано или поздно снова приведут вас к проблеме уникальности имён. Например, вы пишете стили для модального окна. Вам нужно стилизовать полупрозрачный оверлей поверх страницы и само модальное окно. Оба этих элемента могут быть в двух состояниях: виден или скрыт. Кажется, что класс .visible отлично подходит, но проблема в том, что для оверлея и для окна этот класс должен содержать разные стили. Можно придумать костыль в виде селекторов .overlay.visible и .window.visible, но это именно костыль, потому что вы увеличиваете специфичность. С БЭМом всё просто и без ненужного роста специфичности: .overlay_visible и .window_visible.

Answer 2

[Павел Гоголинский]

Префиксы актуальны
https://ru.bem.info/methodology/naming-convention/...

Иногда к именам блоков могут добавляться различные префиксы.