Удобный БЭМ

вообще чаще всего начинается такое не тогда, когда БЭМ плохо применим, а когда дизайн «кто в лес кто по дрова».

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

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

ИМХО, но все несколько проще чем кажется. Хотя тоже не идеально.
Пришел к следующей схеме:
Разделяем все наши поделки на две категории компоненты и представления.
— Компонент (кнопки, инпуты, тул/таб-бары и т.д.) — часто мигрирует из проекта в проект, часто меняются стили.
— Представление (реализации форм, сайдбаров и т.д.) — нужны только в конкретном проекте.
Для первых SMACSS или его подобие. Для вторых БЭМ. Полгода. Полет нормальный.
ЗЫ: Не знаю как это зайдет для сайтов ибо занимаюсь SPA.

1. «Одноразовый блок» вообще не стоит считать блоком. Это элемент вышестоящего блока. Если у вас форма действительно намертво связана со страницей и вы понимаете, что она не повторится нигде, то перед вами не столько .form, сколько .mypage__form. А вот блоки, ее составляющие (кнопки, инпуты, лейблы) свободно переиспользуются. Да, там может появиться каскад, но если ваш псевдоблок действительно одноразовый, то каскад в нем не может создать проблем.

.input {}
.my-page__form .input { /* margin, position, width, ... */ }
.my-another-page__form .input { /* margin, position, width, ... */ }

2. Само возникновение «одноразовых блоков» может быть следствием сырого дизайна, как выше справедливо заметили. То же самое, если часто возникает потребность в чисто декоративных модификаторах. На практике они по большей части функциональные, связанные с состояниями (_disabled, _collapsed, _invalid — такого плана). И как следствие, по большей части булевы. Если у вас много модификаторов вида «_ключ_значение», то есть смысл еще раз подумать над всей дизайн-системой, почти наверняка там не всё хорошо.

3. Глобальные модификации стилей (темы проектов и т.п.) вводятся через уровни переопределения на этапе сборки. Если вам нужно просто стилизовать несколько похожих проектов, не надо вводить модификаторы под каждую тему) Грубо говоря, у вас есть папка «чистых» комопонентов, где зашиты общие свойства для всех проектов, и есть папки с отдельной стилизацией для каждого проекта. При сборке конкретного проекта вы берете чистый компонент и приклеиваете к нему свойства из файлов именно этого проекта.

/* ../base/button.css */
.button {display: block; cursor: pointer; ...}
/* ../project-red/button.css */
.button {background: red; ...}
/* ../project-blue/button.css */
.button {background: blue; ...}

Никаких модификаторов тут не требуется. Индивидуальные стили проектов не надо хранить в общих компонентах. Иначе вам при 100 проектах пришлось бы в каждом блоке таскать с собой 100 модификаторов, из которых 99 не используются в текущем дизайне. Дело тут не БЭМ, а в архитектуре проектов и сборке.

Модификаторы хороши в том случае, если у вас внутри текущего проекта есть одновременно, например, несколько разновидностей кнопок. Скажем, иконические и без иконок. Или синие для безопасных действий и красные для опасных. Вот тогда у вас могут появляться модификаторы: button_iconic, button_safe,… и т.д. Это имеет смысл, потому что они нужны все сразу в текущем проекте.

P.S. Не то чтобы я был адвокатом или ярым фанатом БЭМ, но по факту 99% постов о «проблемах БЭМ» (в контексте именования и CSS) в итоге сводятся к тому, что автор упускает какой-то нюанс или не в полной мере понимает какую-то часть методологии. Поэтому, если возникает желание сделать свой особый БЭМ с преферансом и одалисками, то с очень большой долей вероятности что-то делаете не так.

Блин, не помню точно как называется подход, но смысл такой же как у Вас, но более логичен и менее монструозен:

1. Блоки состоят из 2 слов, называются как в БЭМ: block_name
2. Элементы называются всегда в 1 слово: element
3. Модификаторы выглядят как -modifer
4. Как было сказано "page блоки" называются как l-layout_element
5. утилитарные настройки вроде названия темы пишутся как u-utilitary

ps Если кто-то напомнит как назывался этот стандарт, то будет вообще круто)

<header class="section-header section-header_margin_select-sector">
        <h2 class="section-header__title font font_face_calibri-bold section-header__title_size_select-sectors">

Конечно, будет плохая читабельность, если так накручивать и переусложнять имена классов.
И что это за font_face_calibri-bold — это попытка скрестить БЭМ с атомарным CSS? Не надо так делать.
И последнее: настоятельно рекомендую использовать два дефиса для отделения модификатора — читаемость улучшается кардинально, потому что бОльшую ширину отступа глаз выхватывает легче, чем разницу между '-' и '_'.

И если переписать фрагмент примерно так:

<header class="section-header section-header--margin-large">
        <h2 class="section-header__title text-style--h2">

Всё выглядит гораздо приятнее.

Нормальный дизайн, переиспользуемые классы:

<form class="form">
    <h2 class="form__title text--left">Some title</h2>
    <textarea class="form__input" placeholder="Some placeholder"></textarea>
    <button type="submit" class="form__submit float--right">Some action</button>
</form>

Я не вижу проблем в вёрстке формы представленной выше, у вас разве на всех страницах кнопка разная? На одной маленькая зелёная, на другой синяя огромная, на третьей… Разве что модификаторы вроде float--right, без них не куда. Не понял а почему отступ от заголовка больше чем от поля ввода? Кто дизайн делал? Надо ещё с дизайнером пообщаться, дабы вёрстка была красивее.

Не туда.

Вопрос к автору. У вас на превью-картинке кусок кода с десятками тегов … вы это так серьёзно подключаете стили? Или сделали специально для статьи?

Первый пункт.
Как вам такой вариант:

<form class="form">
  <div class="form__title"
    <h2 class="subtitle">Some title</h2>
  </div>
  <div class="form__elem">
    <textarea class="textarea"></textarea>
  </div>
  <div class="form__elem">
    <button class="button"></button>
  </div>
</form>

Есть блок form со своими элементами, которым мы задаем отступы. Внутри каждого элемента можно расположить любые другие блоки, но можно и замиксовать, это допустимо документацией, просто я так стараюсь не делать.

Пункт второй.
Длинные имена классов !== большое количество классов. А большое количество классов зачастую получается при попытке использования атомарного CSS. Лично мне, как правило, достаточно трех классов: собственно сам класс, модификатор (если нужен), класс — селектор для JS (опять же, если нужен). Если необходимо несколько модификаторов, то следует изучить возможность объединения всех необходимых в один новый.

Третий пункт для меня не понятен.

> П.1 Слой модулей и слой страницы

Сделайте уровень переопределения (https://ru.bem.info/methodology/key-concepts/#Уровень-переопределения) «страница» и кладите туда блоки про эту страницу (about-title, about-layout, etc). Не нужно будет изобретать отдельные правила, как вы сделали в первом пункте манифеста.

Вот пример отдельных блоков для промо раздела сайта:

github.com/bem-site/bem.info/tree/master/blocks/promo

Они имеют отдельный префикс и не мешаются с остальными блоками сайта.

На конкретных страницах они доопределяются:

github.com/bem-site/bem.info/tree/master/blocks/methodology-index

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

> П.2 Длинные имена классов

ru.bem.info/methodology/naming-convention/#Стиль-no-namespace