Знал БЭМ поверхостно - сейчас выделил время чтобы понять полностью. В целом все выглядит логично, кроме миксов. Возьмем пример с описания
<div class="header">
<!-- К блоку `search-form` примиксован элемент `search-form` блока `header`-->
<div class="search-form header__search-form"></div>
</div>
Микс header__search-form добавляет некие стили форме поиска. Форма поиска у нас подключается программно модулем. Теперь решили, что форма поиска необходима и в футере. Описываем подключение модуля и там с тем же шаблоном. И у нас (если ни чего не менять) этот микс применится и в футере. Соответственно нам необходимо либо иметь два разных шаблона блока поиска, либо микс выводить по выполнению условия (скажем PHP формирует этот HTML). Что является по сути лишним. Гораздо более логично, понятно и чище будет обойтись без "миксов". Или, точнее, реализовывать их "обычным" способом каскадных стилей.
.header .search-form { color:red; }
Таким образом код блока (включая шаблон) будет абсолютно самостоятелен, в нем не будет необходимости учитывать/проверять контекст, в котором он подключается. Т.е. фраза из статьи
В данном примере мы совместили поведение и стили блока search-form и элемента search-form блока header. Такой подход позволяет нам задать внешнюю геометрию и позиционирование в элементе header__search-form, а сам блок search-form оставить универсальным. Таким образом, блок можно использовать в любом другом окружении, потому что он не специфицирует никакие отступы. Это позволяет нам говорить о его независимости
В реальности действует если только это блок встречается один раз на странице. В противном случае код должен отличаться как раз таки заставляя вписывать эти миксы.
Т.е. по логике, если читать получается header__search-form привязывает этот блок к конкретному родительскому блоку. Соответственно по сути он не может существовать вне блока header. Может тут пример не удачный выбран еще и он сбивает. Ведь маловероятно, что в header будут два блока поиска. А значит это уже элемент.... Со всеми вытекающими :)
Для обеспечения полной независимости блоков друг от друга, на мой взгляд, не должно быть ни какой жесткой привязки в одном блоке к другому. В этом случае не будет необходимости править верстку. Достаточно будет определить только зависимость в стилях
Вообще ни один блок не должен ни диктовать условия дочернему (ведь не известно сколько их будет и какие они будут), так же и привязок к родительским или соседям. Тут правильнее ввести понятие Фабрика. Фабрика - будет описывать взаимосвязь между блоками. И выражаться по сути в простом каскаде стилей.
В прочем. Думаю я осознал: БЭМ это история исключительно про верстку, а не в целом проект. БЭМ, когда берем готовый сверстанный блок и вставляем в верстку, подразумевает возможность его модификации. Модификаторами и миксами.....
Отнюдь. Скорее так: БЭМ — это про архитектуру, а инкапсуляцию стилей вы получаете «на сдачу». Плох не пример, а то, как вы пытаетесь понять суть миксов через опыт недекларативных шаблонов. Попробую объяснить: итак, мы имеем самостоятельную сущность — форму поиска. Мы описываем её шаблон, который, по запросу этого комонента возвращает нам некий html:
и его стили:
Всё, компонент (блок) готов (там ещё какой-то JS ему добавили, валидацию — не суть). Дальше, по мере разработки вы доходите до
header
'а — у него есть какие-то свои элементы, свои стили, логика и… внутри него есть наша поисковая форма. Естественно, она обладает какими-то размерами и расположением, что диктуется именно её «родителем», т. е. блокомheader
. И у нас есть два пути: первый — положить эту форму в элемент, «зарезервированный» элементом блокаheader
:или мы можем захотеть «сэкономить» на DOM-узлах и объединить
.header__search-form
и.search-form
— тогда получается микс. Причём за него отвечает сущность, которая знает, что внутри неё (или «на ней») будет другая, т. е. в шаблонеheader__search-form
:Не совсем понял что это за код в конце? P.S. новичкок
Шаблоны bemhtml (bemtree/bemxjst):