Правильно ли я использую БЭМ, создавая самостоятельные блоки?

Ankhena, Тогда «сумма» будет элементом блока «корзина». Совпадёт ли этот элемент дизайном (размером, цветом, жирностью шрифта) с .namely__price — мы не знаем. Даже если совпадёт — выносить это «совпадение» в отдельный блок — мало толку («экономим» три строки в CSS, добавляем класс-микс .price в каждую HTML-сущность). Я без претензии — если в вашей практике было оправдано, значит, так и должно быть.

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

Да. Это «неявное наследование», БЭМ за то, чтобы всё было максимально явным — чтобы беглый взгляд на структуру классов в разметке дал всю картину «что тут думал автор».

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

Но без дизайна мои утверждения — лишь догадки.

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

Barring, если этот отступ будет использоваться на других сущностях (не только на services-about__title), то да. Если это специфично именно для services-about__title именно на этой странице, то логичнее модификатор:

на самом элементе:

.services
  .services__about
    .services-about__title.services-about__title_with-margins

или на блоке (тогда свойства описываются через «каскад»):

.services_view_with-title
  .services__about
    .services-about__title

/* CSS */
.services-about__title {
  margin: 1em;
}

.services_view_with-title .services-about__title {
  margin-top: 2em
}

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

Barring, абсолютно верно! Причём у класса categories в стилях вообще может быть пусто (пока) — он лишь отражает «семантику» — что есть что-то обособленное (как эти паддинги, хоть они даже не в самом блоке описан, а в элементе).

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

Сейчас может произойти «щелчок», после которого вся идея БЭМ становится ясна и логична (и оправдана с точки зрения многословности в длинных именах классов). Мы, БЭМ-разработчики, называем это «БЭМом головного мозга» — тебе всё понятно, а остальные считают за сумасшедшего )))

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

Barring, если этот отступ прослеживается в нескольких разных блоках, то всё равно что-то общее у них есть (или это просто совпадение и есть смысл прописать одинаковые значения в элемент about каждого из блоков). Это может быть не родительский блок, а микс на сам services (и industries):

.services.section-about
  …
    .services__about.section-about__paddings

В отличие от микса на сам элемент services__about ( .services__about.section-about ), мой пример позволяет «законно» использовать margin'ы в стилях section-about__paddings (потому что просто у блока не должно быть «внешней геометрии» типа margin'ов)

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

Barring, особенно оправдано, если и блок industries тоже лежит внутри main.

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

Ничего страшного, что есть «прослойки». Визуально будет читаться очень логично:

.main
  …
    .services
      .services__about.main__about-layout

Т. е. этот код «говорит»: Что бы не было вместо блока services — если нужно сделать слой с известными отступами внутри main — вот готовый класс.

Когда в БЭМ использовать миксы, а когда модификаторы?

Erl, маленькая, но очень важная оговорка: ширина и внешний отступ меняются у элементов, а не у блока — у блока не должно быть внешней геометрии. Т. е. если надо было изменить ширину .card или внешний отступ от .card, то это точно следовало делать не в .card и не в модификаторе .card_*, а именно в элементе родительского (т. е. на уровень выше) блока (если это список карточек, то, например в .list__item, если просто лэйаут страницы — в чём-то типа .page__layout.).

Как скрестить webpack и бэм?

Дмитрий Беляев, все интерпритации, выложенные не на bem.info практически всегда являются ошибочными адаптациями — кто-то не осилил дочитать первую страницу до конца, вдохновился, остальное додумал и пошёл строчить в свой бложик:

• css-tricks.com/abem-useful-adaptation-bem
  
• www.smashingmagazine.com/2016/06/battling-bem-extended-edition-common-problems-and-how-to-avoid-them/
  
• blog.kaelig.fr/post/48196348743/fifty-shades-of-bem
  

и т. д. — тысячи их! И в каждой написана чушь. Отсюда и проблемы с поддержкой.

Да, css-модули решают «проблему» с изоляцией, но не решают остальные проблемы: композицию, абстракции, реиспользование, которые в БЭМ получаются «на сдачу». БЭМ — это такая же «идея», как и паттерны проектирования. Можно их не знать и всем рассказывать, что прекрасно решаешь задачи и без «абстрактных фабрик», «декораторов» и «адаптеров» с «наблюдателями». Но качество поддержки таких продуктов скорее всего значительно ниже.

Но и официальная дока не без недостатков — там довольно сложный для понимания технический язык, так что есть телеграмм-чатик для возникающих вопросов: https://t.me/bem_ru

Как скрестить webpack и бэм?

Владислав Лысков, отчасти. БЭМ — это своего рода «паттерны проектирования», минимальная каскадность, реиспользуемость на уровне логики и оформления, инкапсуляция получаются «на сдачу» (можно со 100% уверенностью утверждать, что можно разрабатывать не используя ни одного паттерна проектирования, но зачем?). Так что это не тезис, а «следствие». Например, CSS-модули могут решать часть проблем, которые решает БЭМ, но заменой они не станут, т. к. не «закрывают» остальные вопросы.

Как скрестить webpack и бэм?

Дмитрий Беляев, Владислав Лысков, отвечает «познавший дзэн»: стили и шаблоны весят столько же, сколько и при самой удачной однобуквенной минификации (есть такая штука — gzip, он это делает на лету). пруфы: https://github.com/bem-site/bem-forum-content-ru/i...
Если «невозможно адекватно это все поддерживать и переиспользовать», то это не БЭМ, господа, вас обманули.
БЭМ — это не «классы через чёрточку», это про компонентный подход и правильную декомпозицию. Поэтому не используя БЭМ вы или по определению делаете х***ю, или используете какую-то урезанную версию методологии, просто не знаете об этом.

Какой вариант именования более правильный по БЭМу?

Barring, вот тут уже более «тонкий» нюанс — по идее имя файла (как и любой переменной) должно отражать функционал (чтобы не тратить время на чтение кода). Т. е. кажется, что, если сгруппировать компоненты, имеющие отношение к поиску, то проще будет этот файл найти или перенести в новый проект. Но тут ещё имеет значение договорённость в команде — если в проекте один или пару человек (и им легко договориться), то ButtonSearchClear — вполне приемлемый вариант. Но если с библиотекой может работать разработчик «со стороны», для него такое поведение может быть не очевидно с первого раза.

Какой вариант именования более правильный по БЭМу?

Aetae, т. е. у вас разметка состоит из «лапши» if-ов, определяющих, что именно рендерить по значению из пропсов? Модификаторы как раз и позволяют решить эту проблему, описывая шаблоны более декларативно. По сути, пропс и является модификатором, потому что модификатор не обязательно должен быть в списке CSS-классов.

Какой вариант именования более правильный по БЭМу?

Aetae, два минуса для отделения модификатора имеют проблемы у некоторых подсветок синтаксиса — принимают их за HTML-комментарий. Один минус итак используется для обозначения сложносоставных названий переменных. Какую бы схему именования вы не использовали, будет ошибкой, если эти имена пишутся руками, а не генерируются.
Если у вас нет модификаторов, то с большей вероятностью (минимум 100%) — вы не понимаете их предназначение.

Какой вариант именования более правильный по БЭМу?

Barring, нет. Потратьте несколько минут на вдумчивое прочтение статьи вместо новых вопросов — это сэкономит время нам обоим. Про расположение файлов там тоже есть.

Какой вариант именования более правильный по БЭМу?

Нет. Базовый компонент должен быть по определению. Если он круглый, но может быть квадратным, то один из признаков может быть описан в базовом компоненте, а другой компонент «модифицировал» бы базовое поведение.
Т. е. или

Card/
  _view/
    Card_view_circle.vue
    Card_view_square.vue
  Card.vue

или

CardCircle/
  _square/
    CardCircle_square.vue
  CardCircle.vue

Как по BEM правильно верстать вложенные списки?

Егор Астрейко, если этого требует вёрстка.

Как правильно использовать Symfony + Gulp + БЭМ?

Всё равно тут не будет правильного ответа. И Symfony, и Gulp являются лишь инструментами, любое их использование, дающее ожидаемый результат, будет правильным. БЭМ, если не используется БЭМ-стек, тоже достаточно просто валидируется.