Comments 14
Множественные элементы блока, например, элементы списка могут быть названы как
-item:
Здесь может сложиться неправильное впечатление, что необходимо использовать все дерево имен блока. Запись .cards__container-item в принципе допустима, если рассматривать часть "container-item" как единое целое, а не "-item" как продолжение "cards__container". В данном конкретном примере было бы лучше дать элементам списка класс .cards__item, а для иллюстрации двух-, трехсложных имен придумать что-то другое.
класс-модификатор "cards__container-item_blue"
В классическом БЭМ различают булевы модификаторы и модификаторы со значением. Здесь опять же следует применить модификатор со значением (цветов может быть много) – .cards__container-item_color_blue. В качестве примера булева модификатора можно например привести .button_disabled
БЭМ был актуален лет 10 назад, когда верстальщики ещё не умели в компонентную декомпозицию, а верстали всю страницу целиком с нуля, а потому имели возможность просунуть элемент-класс на любую глубину. Но сейчас даже войтивайти собирают интерфейс из компонент, из-за чего нет возможности просунуть элемент-класс на более чем 1 уровень глубины, что делает БЭМ нежизнеспособным. Чтобы его починить, надо вводить "фрактальные блоки", классы которых собираются в рантайме на основе последовательности имён от корня, как это сделано, например, в $mol.
Для начинающих разработчиков это далеко не первая тема. Данная статья была написана с целью познакомить новичков с классами, для чего они нужны и как к ним обращаться. Не могу не согласиться с Вашим примером, но для новичков это сложновато.
Компоненты? Вы предлагаете все сайты на JS верстать? Мне кажеться, это перебор.
И получают на выходе такую кашу... То, что вы лепите интерфейсы через компонентный подход - это отрадно. CSS тут при чём? И "уровень глубины"? БЭМ как раз специально отходит от концепций каскада и специфичности - нужен просто уникальный класс для каждой сущности. Ну и компоненты компонентами, но как вы их в итоге на странице размещать собрались? Глобальные стили тоже отдельным компонентом прописываете?))
cards__container-item некрасиво выглядит, лучше cards__item для элемента списка, а список как отдельный блок cards
Дим, вы молодец! Так держать!
Я сейчас такую тупую вещь спрошу. А зачем может понадобиться так сложно работать с классами?
Например, есть у вас много UL в них много LI. Поставил на <UL class="card"> и выбирай все первые LI: ul.card > li
Ну собственно, как и пример с синим элементом. Вам нужен синий третьим или последним? Потому как, если дать третьему элементу модификатор синей подложки, и потом добавить четвертый, то подложка будет у третьего. Потому как привязка свойства идет к конкретному блоку, а не к макету.
Кстати, по примерам видно, что речь скорее идет про ABEM, потому как в настоящем BEM модификаторы идут через "--". Пруф.
Спасибо, за статью, за четыре года знакомства и попыток пользоваться этой методологией, я все еще не прочувствовал, какое удобство добавляет БЭМ? Сeйчас у меня в проекте около 230 компонентов, в них применены bootstrap и, позже, tailwind и я так и не осознал, что бы мне дал переезд на BEM или ABEM.
Не вижу ничего сложного в данном подходе)
В своих работах я крайне редко обращаюсь по тэгам. Я предпочитаю, чтобы элементы были классифицированы для более удобной работы с ними. С глубокой вложенностью, например, с использованием препроцессоров данная штука очень удобна.
В ABEM используется конструкция class="card -primary -large", что также отличается от продемонстрированных примеров.
Я использовал примеры, какими пользуюсь ежедневно. Действительно, в БЭМ модификаторы обозначаются через "--", но некоторые сокращают данную запись до "_", что по мне так является более удобным вариантом.
Объясняю на пальцах на вашем примере. На самом деле работа с классами обычно гораздо сложнее того, что вы тут представили))
И так у нас есть UL в котором много LI. И правило, описывающее стили этих элементов списка ul.card > li (кстати, а зачем вы селктор тэга перед классом воткнули? специально специфичность повысить - чтобы потом баги изо всех щелей лезли?)
Рассмотрим это правило:
Если в LI есть вложенные списки, которые визуально выглядят точно так же (типичный пример - навигация с подменю), вы будете прописывать ещё одно правило? ul.card > li li? Вы представляете какая у вас в итоге дичь в коде получится? Вам одни и те же стили придётся прописывать по несколько раз - привет css-каскад!))
Если мне нужен синий элемент, то разумеется я не буду считать порядок элементов. Я просто необходимому элементу навешу модификатор .el_blue
Кстати, по примерам видно, что речь скорее идет про ABEM, потому как в настоящем BEM модификаторы идут через "--"
Нет! Во-первых, в БЭМ на самом деле нет никакой преопределенной системы именования. Всё зависит от того как лично вы привыкли именовать или как заранее условились. Браузеру наплевать сколько там дефисов в именовании классов - это только для человека.
Ну а во-вторых, вы именно что дезу вкидываете: https://ru.bem.info/methodology/naming-convention/#правила-формирования-имен
Ну и судя по тому, что вы используете бутстрап - вам ещё рановато рассуждать о преимуществах той или иной методики представления. Ну серьёзно - я не понимаю как можно собирать какие-то хоть сколько-нибудь сложные макеты из вот этих .container .row{ margin: 0 -10px; padding: 0 10px;}
Классификация и идентификация элементов в HTML и CSS и немного о БЭМ для самых маленьких