Как назвать класс в BEM?

Для отступов. Можно, конечно, смиксовать:

<header class="header">
    <img class="logo logo_size_m header__logo" />
</header>
…
<footer class="footer">
    <img class="logo logo_size_l footer__logo" />
</footer>

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

Как правильно по БЭМу?

Лев Александров, да, точно: .page__content.product.product_view_detail. Спасибо.

Я всегда использую heading для заголовков, чтобы не было путаницы с тегом <title>. Но уверен, что это не идеальное решение и с непривычки выглядит «странненько».

Может ли блок наследовать свойства или он должен быть полностью самодостаточным?

Muvka, правильного варианта нет (как и ошибочного) — всё зависит от ситуации. Поэтому я и привёл оба примера — у вас в каждом конкретном случае какой-то из них. Если хватает модификатора title_align_* — используйте его. Если нужно бо́льшей «динамики» (дополнительные правила на брейкпоинтах, переопределение и добавление CSS-свойств) — используйте сочетание CSS-каскада и миксов (последний пример). Это и есть правильное решение.

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

Потому что невозможно оценить корректность, глядя только на разметку. У вас классы через чёрточку, в БЭМе тоже так пишут, но только этого признака недостаточно — БЭМ про компонентый подход, про выделение общих компонентов, а как тут выделить общие компоненты, когда не представлен дизайн? Можно лишь оценить, что классы с «имя-неймспейса-два-нижних-подёчеркивания-второе-имя» лежат „внутри“ «имя-неймспейса» — это ещё не БЭМ.

Опишите правильно структуру FormInput по БЭМ?

hamster141095, да, вполне. Нейминг соблюдается.

Через какой класс мне позиционировать Бэм элемент?

Не любая. Главное — чтобы позиционирование не было в блоке — это сделает его более «независимым».
Есть ли исключения? Да. Например, модальное окно по определению позиционируется относительно вьюпорта, а не разметки. Но поэтому это и исключение.
Микс же просто позволяет «сэкономить» на вложенности — вместо создания двух div'ов (например, один про оформление, второй — про «геометрию») — обобщить стили на одном:

.header {
  padding: 10px; /* это «внутренняя» геометрия, тут всё ок */
}

.header__menu {
  margin-left: 10px; /* «отодвигаем» внешние элементы на 10px слева. Это «внешняя геометрия»  */
}

.menu {
  padding: 5px;
}

<header class="header">
  <div class="header__menu">
    <ul class="menu"><!-- … --></ul>
  </div>
</header>

станет

<header class="header">
  <ul class="menu header__menu"><!-- … --></ul>
</header>

Верны ли эти правила БЭМ?

Norum, спасибо за наводку. БЭМ-десант уже выехал бить его по рукам.

На самом деле про «БЭМ — всего лишь методология, никто не запрещает нарушать правила» — это не совсем так. Причин «нарушить БЭМ» довольно мало (и они поэтому даже описаны в самой документации: https://ru.bem.info/methodology/block-modification...). Т. е. если вы столкнулись с желанием «сделать по-своему» — остановитесь, подумайте — возможно, вы неправильно декомпозировали структуру, отчего усложнили реализацию. Может, стоить разбить сущность на два блока. Или наоборот — увидеть в различии две модификации одного блока. И т. д.

Где убрать БЭМ-примеси?

lucky__lucky__1990, если хотите понять и изучит БЭМ, советую сменить наставника и курсы — кажется, у них «стандарты» основаны на том, что они «не асилили» https://ru.bem.info/methodology/quick-start/

P. S. Ну и «на десерт» — про обёртки https://ru.bem.info/forum/656/

Правильно ли в БЭМ применять миксы для задания одинаковых свойств для нескольких элементов?

strelok011, у вас какое-то извращённое понимание идеи методологии БЭМ. Если вам по неграмотности показали какую-то нерабочую «адаптацию БЭМ» (коих десятки, причём от достаточно авторитетных источников), то это не повод игнорировать официальный — https://bem.info, где подробно и с примерами описаны и про преимущества миксов (аналог заимствования методов и свойств у другой сущности) и про мнимую выгоду от минимизации этого кода.

Нужны ли здесь модификаторы?

Да, popup — универсальный блок с абсолютным (position: absolute / fixed) позиционированием — для селекта, модалки, попапов, всплывающих алертов и т. д. Можно и объединить, но тогда у каждого блока с абсолютным позиционированием будет своя логика этого самого позиционирования. Тут вопрос вкуса.

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

Можете указать на ошибки в hml БЄМ?

А в идеале, скорее всего, вот такой вариант:

<div class="portfolio__item portfolio-item mix slug paint">
  <!--  дальше всё идентично, как написал @n1ksON -->
</div>

Пояснение — мы делаем микс самостоятельной и независимой (скорее всего повторяющейся) сущности-блока portfolio-item с верхнеуровневой сущностью — элементом item блока portfolio. В стилях portfolio__item будут описаны внешняя геометрия (отступы, размеры)б характерные для этого элемента, а в стилях portfolio-item — оформление этого блока как самостоятельной сущности (внутренние отступы, размеры шрифта, цвета и т д).

Как правильно по бэм?

Сергей delphinpro, пардон. Видимо, я перегрелся…

Как правильно по бэм?

vvanyazz, но если у меню всего 2 состояния размера — просто menu и menu_big — то использование булевого модификатора вполне оправдано. Но если появляются menu_big и menu_small, то тут уже лучше их группировать в menu_size_big и menu_size_small. А если вынести в menu_size_normal информацию о размерах, то это красиво разгруппирует стили — в стилях класса .menu {} (display, border-radius, background и т. д.) будут только стили самого меню, а в .menu_size_* — только информация о размерах (отступы, размер шрифта и т. д.).

Как правильно по бэм?

vvanyazz, нет, не только. Вы привели пример «булевого» модификатора, у который весьма ограниченная область применения: button → button_disabled, menu__item — menu__item_active, card → card_hovered и т. д. Когда модификаторы можно сгруппировать по признаку, например, внешнему виду, они записываются в виде «ключ-значение» (блок_общий-признак_значение), например: button_view_primary, button_view_secondary, button_view_error, button_view_info — это позволяет точно определить, что именно (view, т. е. внешний вид,) модифицируется и в каком значение (primary / secondary / info и т. д.). А просто menu_big — непонятно, к чему относится — увеличился размер кнопки (вместо menu_size_big / menu_size_small) ? Или она расположена в большом блоке (menu_position_big-card / menu_position_promo) ?

Вот краткая статья про виды модификаторов: https://ru.bem.info/methodology/quick-start/#модиф...

Как правильно по бэм?

Сергей delphinpro, увеличивается связанность — блок header «влияет» на чужой элемент. Если вынести menu в другое место за пределы header, придётся переписывать стили (и, возможно, переносить их в другой файл). Ваш пример решает проблему, но плох с точки зрения методологии.

Как лучше писать отступы для BEM блоков?

Сергей delphinpro, но вопрос-то был про БЭМ. В БЭМе атомарные хелперы — антипаттерн, т. к. сами по себе противоречат принципу Абсолютно независимого блока. Про отсутсвие «внешней геометрии» (а margin-свойство влияет на внешнюю геометрию, как и position или явное задание width / height) — вы абсолютно правы, но пример вводит в заблуждения с точки зрения соответствия методологии.

Как избежать вложенности в БЭМ?

TedMarsh, тогда каскад (вложенность) тут оправдан.

Как избежать вложенности в БЭМ?

TedMarsh, можно. Но пример сильно выдуманный — непонятно, почему одни ссылки одного цвета, другие — другого. Тут с успехом мог бы быть модификатор, но из разметки такие выводы не сделать без дизайна.

Как избежать вложенности в БЭМ?

Привет. Что именно смущает во вложенности?

Можно ли вкладывать элементы одного блока в другой?

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