Как правильно внедрять БЭМ?

Question

[Сергей]

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

1. Как корректно/адекватно совмещать именование с Bootstrap?
Используем что-то вроде block__element_mod col-md-6, но выглядит как-то не комильфо. Использовать "оБЭМленную" версию бутстрапа или есть какие-то соглашения на такой случай?
2. При использовании em пришел к выводу, что для действительно независимого использования блоков нужно каждый раз определять font-size в px на уровне блока и наследоваться уже от него. Нормальный ли такой подход, мб есть более адекватные варианты?
3. При верстке "мегайдизайнерских" лейндингов нередко сталкиваюсь с тем, что у одинаковых по сути блоков в разных местах используются разные шрифты. Переопределять шрифты как модификатор соотв. элемента?
И вытекающий момент - соотвественно все модификаторы (от разных блоков) в будущем добавляются к той же секции стилей блока?
4. При работе с существующими проектами, особенно на CMS используется уже полно готовых классов, в некоторых случаях, классы идут из ядра (напр. меню в WP, да и многое в нем же). Т.е. по хорошему для соблюдения одного стиля в этом случае придется писать доп. код. формирования шаблона с нужными мне классами? Или тот самый случай, когда "работает-не трожь" ?)
5. За основу использую классический вариант именования, но периодически встречаю two-dashes-style.
Популярен все-таки классический вариант?

Answer 1

[AlexS94]

Попытаюсь ответить вам по пунктам, так как сам в своё время задавался теми же вопросами.

1. Если говорить об удобстве - читаемость хромает, но на прямую в разрез с методологией это не идёт. Если существует "оБЭМленый" Bootstrap и он ничем не уступает - используйте. Это по-настоящему продуманная и современная библиотека компонентов, соответствующая стандартам доступности. Отдельных соглашений на такие случаи не знаю.

Для себя решил отказаться от Bootstrap, чтобы глаз нервно не дёргался, при взгляде на "винегрет" из разных именований. Компенсирую это разработкой библиотеки собственных компонентов, руководствуясь тем же Bootstrap и лучшими практиками.

2. Касательно использования em: рекомендую ознакомиться с этой статьёй
Пришло время попрощаться с единицей измерения px
Для блоков отдельно назначать font-size в px не нужно. Попробуйте правильно использовать rem, взяв за константу, что он должен быть по умолчанию 16px. Если нужно будет - отвечу подробнее.

Лично я использую em в медиа-выражениях и в случае крайней необходимости в блоках.

3. В случае чистого БЭМ - создайте блок с одним шрифтом и другим и используйте его как микс.

4. Если честно, стараться использовать готовые решения CMS можно, но я бы не рекомендовал. Когда работал с WP, всё время кастомизировал классы и вывод шаблона. На Битрикс с этим проще, можно даже собственный класс назначить для WISYWIG редактора.
Вопрос в том можете ли вы себе позволить такую кастомизацию или нет. Если это требует сверх ресурсов - оно того не стоит.

5. Я использую альтернативное именование, которое прижилось лучше всего в англоговорящих странах .block__element--modifier. На мой взгляд оно читаемее.

Вообще для расширения "БЭМ кругозора" рекомендую ознакомиться с этими статьями
More Transparent UI Code with Namespaces
Battling BEM CSS: 10 Common Problems And How To Av...

Я в своей работе на данный момент использую расширенный БЭМ, так называемый BEMIT (BEM + ITCSS). Для обычных сайтов - этого хватает с головой, в случае современного реактивного фронтенда требует обсуждения с командой и более глубоко понимания в проектировании АНБ (абсолютно независимый блок).

Надеюсь, что смог вам помочь, так как сам на решение этих вопрос вопросов потратил продолжительное время.

Comments

[AlexS94]

Alexander Lamdan, простите, а я где-то сказал, что мы стартап у которого нет на это времени?)
Так-то конечно, вы правы, для небольшой компании - это весомая задача, на которую не выделяются средства и время.
Это мой личный проект, который я планомерно интегрирую в рабочую среду организации.

[Сергей]

AlexS94, спасибо, ваш ответ немного прояснил ситуацию.
По поводу использования rem - в курсе, статью видел, пробовал, но, к сожалению в IE10 есть проблемы с использованием rem, а legacy никто не отменял)

[AlexS94]

Илья, сочувствую вам... Я об IE перестал думать в начале прошлого года, по умолчанию не обещаем его поддержку, и надеюсь не вспомню уже.
Если есть возможность - проталкивайте отказ от него, это реально убыточно как для компаний, так и для сотрудников не имеющих возможности использовать современные технологии.

[motezor]

Подскажите, если я использую модули CSS в реакт или некст, то как обойтись без черточек в именовании, которые недоступны в названиях jsx переменных? Как стоит записывать модификаторы, использовать одно нижнее подчеркивание не по БЭМу выходит.

[AlexS94]

motezor, Существует множество нотаций, какие конкретно комбинации символов не подходят?
Я с jsx редко связываюсь, работаю в основном на Vue.

Здесь есть React-style:
Соглашение по именованию

Answer 2

[profesor08]

Ну вот, желание использовать БЭМ, породило кучу проблем. Нет БЭМ - нет проблем!

Используй styled-components или модульные стили. Если нет возможности, то используй scss, там нет проблем, которые навязывает БЭМ и героически решает. Если используешь чистый CSS, то не используй, а используй scss.

Comments

[AlexS94]

Боюсь что в своём утверждении вы не правы.
Я долго обходил БЭМ стороной, но начав применять на реальных проектах осознал все его преимущества. БЭМ решает в первую очередь 2 проблемы: читаемость кода и контролируемость каскада стилей. За счёт решения этих проблем мы получаем высокую переиспользуемость стилей.
styled-components - прекрасная технология, и она частично решает эти проблемы. Но далеко не полностью, да и не всегда она применима, всё зависит от задачи, инструментов и команды.
А вот scss - совсем не про то.

[profesor08]

AlexS94, а какую проблему не решает автоматическая генерация уникальных имен классов, минимализация их количества и наследование? В БЭМ это все перекладывается на разработчика, тебе в любом придется помнить все названия компонентов, чтоб не возникало конфликтов. А раз надо все помнить, то и смысла в нем нет, так-же можно заучить и запомнить все классы просто используя css. И так-же придется героически решать возникающие конфликты стилей, бесконечное переопределение стилей при помощи модификаторов либо выдумывания новых названий.

[Виталий Першин]

Ну вот, желание использовать БЭМ, породило кучу проблем.

Желание использовать БЭМ породило задать правильные вопросы, чтобы разобраться и стать более квалифицированным.

Нет БЭМ - нет проблем!

Очень сомневаюсь, минимум проблемы другого характера, но тут уже от разработчика зависит, многие просто их игнорируют принимая как должное.

Жаль нет кнопки "Не нравиться", а то от таких рекомендаций и появляются куча сайтов выброшенных на помойку.

[profesor08]

Виталий,

Жаль нет кнопки "Не нравиться", а то от таких рекомендаций и появляются куча сайтов выброшенных на помойку.

Наличие или отсутствие БЕМ на это не влияет

[AlexS94]

profesor08, могу согласиться только с проблемой придумывания имён - да, это бывает больно) Но это боль любого мало мальски крупного проекта. Даже в случае styled-components вам придётся придумывать имена компонентов и переменных, как минимум. Такова наша работа. Ну и ключевой нюанс в том что styled-components использовать удобно лишь с реактивными приложениями на Angular, React, Vue и подобных. Как вы буде
К слову, при правильном семантическом именовании проблем особо не возникает с запоминанием имён, они семантичны и при должном знании английского легко понять что есть что.
Я работал с парой проектов использующих styled-components, на поддержке ,и честно говоря это сложнее для восприятия, имхо. Возможно вам комфортнее и удобнее.

[profesor08]

AlexS94, можно все компоненты назвать Tag и использовать их под разными именами, задавая их при импорте. У всех будут свои стили, и при этом не будет никаких конфликтов, так как компилятор тебя заставит поправить все конфликтные имена импортированных компонентов.

Для примера, если объявить 100 стилей .item, это все будет один класс, для одного элемента, и каждый последующий будет перетирать стили предыдущего, если они пересекутся. В случае компонентов, ты можешь создать 100 Item, и все они будут разными и их стили никогда не пересекутся.

Ну и ключевой нюанс в том что styled-components использовать удобно лишь с реактивными приложениями на Angular, React, Vue и подобных

Заблуждение, можно использовать и в обычной верстке. Все зависит от желания покопаться. Можно сгенерировать и html, и css, и даже читаемые названия классов.

[AlexS94]

profesor08, ну этим вы немного упростили себе жизнь, не спорю, но думать придётся при каждом импорте что и как назвать всё равно. По опыту - лучше прийти к некоему соглашению внутри команды и придерживаться его.

По поводу примера:
Ок, а в чём сложность писать вот так? Особенно используя препроцессор или PostCSS.

.product-list__item
.news-list__item

Таким образом вы гарантированно задаёте пространство имён, а потенциальные конфликты можно исключить используя scoped-styles в случае описанных выше фреймворков.

Заблуждение, можно использовать и в обычной верстке. Все зависит от желания покопаться. Можно сгенерировать и html, и css, и даже читаемые названия классов.

Я не сказал, что нельзя использовать, но удобство сомнительное, особенно если думать о поддерживаемости проекта.

[profesor08]

AlexS94,

ну этим вы немного упростили себе жизнь, не спорю, но думать придётся при каждом импорте что и как назвать всё равно.

Так пример то абсурдный, но демонстрирует то, что можно не париться над неймингом.

Ок, а в чём сложность писать вот так? Особенно используя препроцессор или PostCSS.

Именно в том, что так придется писать всегда, надо помнить все, и ни нейминг, ни память, не дают гарантии того, что все будет гладко. А если проектов несколько параллельно, то это ппц. Расширять еще сложнее, так как легко напортачить и это всплыть может не сразу, а через месяц.

А генерация разметки БЕМ с помощью препроцессора это равносильно подписанию смертного приговора всем написанным стилям. Так как без девтулзов и сурсмапов невозможно будет ориентироваться в проекте и в фалах. При этом постоянно придется гулять по файлу и смотреть откуда растут ноги у условного &__item

Таким образом вы гарантированно задаёте пространство имён, а потенциальные конфликты можно исключить используя scoped-styles в случае описанных выше фреймворков.

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

но удобство сомнительное, особенно если думать о поддерживаемости проекта.

Как раз с этим нет никаких проблем. Можно в любой момент удалить что угодно, добавить что угодно, и при этом быть на 100% уверенным что ничто не сломается. А так-же не возникнет проблемы мертвого кода, все что не используется в бандл не попадает.

[AlexS94]

profesor08, весомые аргументы. Предлагаю прекратить обсуждение, так как вопрос не по теме. Вы меня, если честно, не убедили, но возможно мне стоит лучше присмотреться к styled-components. В конце концов, я когда-то плевался в БЭМ.

[ijakparov]

Все дело в том что БЭМ это целый стек технологий, а не просто именование стилей. БЭМ для CSS исключительно удобен именно в стеке БЭМ.

Answer 3

[ijakparov]

1. Оставляйте как есть
2. На блок не должна влиять "внешняя среда"
3. Бить по голове дизайнеров чтобы так не делали. Да делать модификаторы под шрифты.
4. Не трогай
5. -- у буржуев, _ в СНГ. В целом используй что привычней.