Я не использую Angular, к сожалению.
На минском БЭМ-митапе был доклад про это, вот страничка мероприятия, и в тексте есть ссылки на докладчика и описание темы, наверняка можно связаться или раздобыть дополнительные сведения:
В мире, где не используется полный BEM-стек (про который и написана статья), эти проблемы правильнее решать либо миксинами на уровне CSS-препроцессора, обобщая в них всё визуальное, либо выносом общих свойств и поведения в основной блок и созданием специальных модификаторов под отдельные случаи (когда обычная кнопка должа вдруг начать вести себя как радиокнопка).
История с тем, как вынести вовне общий код у компонент, которые похожи друг на друга, но не сильно — стара, как мир. В определённый момент (я в этом твёрдо уверен) надо рвать «наследственную связь» и копипастить, потому что поддержание зависимостей со множественным переопределением себя не оправдывает с практической точки зрения — будут сплошные баги и регрессии, которые съедят всё время, которое сэкономит shared code base.
очень хорошая идея про группу и роль, спасибо! беру на вооружение!
всё же блок и элемент как основные термины мне нравятся больше. во-первых, это устоявшиеся термины, это даже важнее локальных преимуществ переименования. во-вторых, группа подразумевает наличие нескольких вложенных сущностей (иначе кого мы группируем?), а в БЭМ блоки могут не иметь элементов вообще.
БЭМ — не канон, а методология. Я.Почта использует свой подход, у них есть элементы элементов, наверное, им зачем-то надо. В «классическом» БЭМ по умолчанию не описывается иерархия элементов, т.к. считается важным:
— иметь возможность свободно переставлять элементы внутри блока;
— оперировать только тремя сущностями (блок, элемент, модификатор) без усложнений;
— отделять семантически разные сущности друг от друга.
Если пойти на крайности, всю страницу можно описать как один блок с элементами неограниченной вложенности, но пользы от этого немного.
В реальной жизни идеалов не бывает. Есть у вас есть иерархия, которую надо отразить в БЭМ, можно вводить элементы элементов, можно делать b-folders__folder-name и b-folders__folder-info, можно вводить отдельный блок b-folder и у него делать элементы b-folder__info и b-folder__name.
Я сам работал на проектах, где был вариант БЭМ с элементами элементов, и лично для себя пришёл к выводу, что «плоская» структура блоков — гибче.
для моего случая и для начинающих — не помогают совсем, увы :( эти туториалы — и вообще весь bem.info — о том, как начать использовать «полный стек» БЭМ, а у меня была задача понять, как его можно НЕ использовать и при этом получить плюсы от внедрения методологии как таковой. это очень важная разница, критичная.
плюс, по ссылке нет материала для «совсем новичков», считается, что азы можно выучить самому, но для англоязычной аудитории это неверно.
мои ребята в Берлине просили материала на порядок более простого — про смысл всего подхода, про примеры выделения блоков в существующем коде, про подробности naming convention и зачем она нужна.
Вопрос про английскую версию и детальность: дело в разнице языков, или в русском переводе формулировки другие? Я переводил более-менее один-в-один, но опыт перевода самого себя с английского на русский для меня нов; плюс, я не думал и не писал по-русски, когда делался оригинал статьи для Smashing. Интересно сравнить оба варианта со стороны :)
Оригинальная статья (на английском) была мною начата (как и написано в предисловии) как набор рекомендаций и пояснений про BEM для ребят из группы фронтенд-разработки, которой я руковожу тут, в компании Deltamethod в Берлине. Про основы BEM мало туториалов на английском, а какие есть — сделаны людьми, которые понимают BEM только как правила CSS-нейминга (а не как методологию). Уже потом я подумал, что можно сделать из этого полноценную статью :-)
Вложенный div (одна и та же нода) семантически является элементом container блока block и элементом item блока widget. Если не использовать BEM-именование, было бы <div class="container item"></div>, и неясно, кто чей (а ещё оба элемента могли называться item, тогда вообще весело)
2. В разметке бывает удобно переносить куски layout'а в другие места и знать, что JS не сломается. Чем меньше в JS зависимостей от структуры блока, тем лучше (это мой личный опыт, подтверждённый). Если б меня заставили перейти на схему с явно описанной структурой в стиле "A > B", я б лично повесился в тот же день, but your mileage may vary :)
3. Не очень понял про спор насчёт специфичности. Дело вовсе не в длине строки, а в весе правил, меняется CSS Specificity, об этом есть абзац в статье. Плюс, в BEM всегда понятно, на каком блоке или элементе срабатывает модификатор, потому что модификатор всегда привязан к блоку или элементу, «абстрактных» модификаторов нет вообще.
Про структуру — вообще, структура должна быть описана шаблоном, это не уровень CSS, и тем более не JS. Жизнь не идеальна, но меньше связности == меньше регрессий при правках.
Понятно. Есть несколько причин (о некоторых из них я написал в этой статье, кстати):
1. Миксы. Очень часто надо «смешать» несколько БЭМ-элементов на одной ноде, и если нет префиксов и имя элемента не содержит имени блока, совершенно неясно, какой элемент к какому блоку относится.
2. Работа с BEM из JavaScript. Удобно получать готовую ссылку на элемент по имени класса, а не делать вложенный поиск по селекторам.
3. Вес (специфичность) селекторов и возможности переопределения и доопределения стилей. У селектора .block > .elem1 > .elem2 иной вес, чем у .block__elem2, переопределить его можно только через селектор такого же веса.
4. Гибкость HTML. В БЭМ вообще не очень приветствуется, если элементы и их отображение сильно зависят от структуры. Обойтись без этого сложно, но специально фиксировать, что элемент — прямой потомок (селектор >) — неудобно, завтра ваш коллега добавит div-обёртку и все стили сломаются. В БЭМ, когда он ещё был АНБ, иногда писали селекторы вида .block-name .elem, без селектора >, но отказались (см. пункт [1]).
Кстати, БЭМ не должен отображать структуру HTML :) Его задача — перевести DOM-дерево в BEM-дерево, наложив сверху CSS-классы как overlay, и структура при этом возникает новая.
Я не использую Angular, к сожалению.
На минском БЭМ-митапе был доклад про это, вот страничка мероприятия, и в тексте есть ссылки на докладчика и описание темы, наверняка можно связаться или раздобыть дополнительные сведения:
tech.yandex.ru/events/bemup/18-april-2014/
История с тем, как вынести вовне общий код у компонент, которые похожи друг на друга, но не сильно — стара, как мир. В определённый момент (я в этом твёрдо уверен) надо рвать «наследственную связь» и копипастить, потому что поддержание зависимостей со множественным переопределением себя не оправдывает с практической точки зрения — будут сплошные баги и регрессии, которые съедят всё время, которое сэкономит shared code base.
всё же блок и элемент как основные термины мне нравятся больше. во-первых, это устоявшиеся термины, это даже важнее локальных преимуществ переименования. во-вторых, группа подразумевает наличие нескольких вложенных сущностей (иначе кого мы группируем?), а в БЭМ блоки могут не иметь элементов вообще.
— иметь возможность свободно переставлять элементы внутри блока;
— оперировать только тремя сущностями (блок, элемент, модификатор) без усложнений;
— отделять семантически разные сущности друг от друга.
Если пойти на крайности, всю страницу можно описать как один блок с элементами неограниченной вложенности, но пользы от этого немного.
В реальной жизни идеалов не бывает. Есть у вас есть иерархия, которую надо отразить в БЭМ, можно вводить элементы элементов, можно делать
b-folders__folder-nameиb-folders__folder-info, можно вводить отдельный блокb-folderи у него делать элементыb-folder__infoиb-folder__name.Я сам работал на проектах, где был вариант БЭМ с элементами элементов, и лично для себя пришёл к выводу, что «плоская» структура блоков — гибче.
плюс, по ссылке нет материала для «совсем новичков», считается, что азы можно выучить самому, но для англоязычной аудитории это неверно.
мои ребята в Берлине просили материала на порядок более простого — про смысл всего подхода, про примеры выделения блоков в существующем коде, про подробности naming convention и зачем она нужна.
Оригинальная статья (на английском) была мною начата (как и написано в предисловии) как набор рекомендаций и пояснений про BEM для ребят из группы фронтенд-разработки, которой я руковожу тут, в компании Deltamethod в Берлине. Про основы BEM мало туториалов на английском, а какие есть — сделаны людьми, которые понимают BEM только как правила CSS-нейминга (а не как методологию). Уже потом я подумал, что можно сделать из этого полноценную статью :-)
<div class="b-block"> <!-- ... какая-то разметка --> <div class="b-widget"> <div class="b-block__container b-widget__item"> <!-- --> </div> </div> </div>Вложенный
div(одна и та же нода) семантически является элементомcontainerблокаblockи элементомitemблокаwidget. Если не использовать BEM-именование, было бы<div class="container item"></div>, и неясно, кто чей (а ещё оба элемента могли называтьсяitem, тогда вообще весело)2. В разметке бывает удобно переносить куски layout'а в другие места и знать, что JS не сломается. Чем меньше в JS зависимостей от структуры блока, тем лучше (это мой личный опыт, подтверждённый). Если б меня заставили перейти на схему с явно описанной структурой в стиле "
A > B", я б лично повесился в тот же день, but your mileage may vary :)3. Не очень понял про спор насчёт специфичности. Дело вовсе не в длине строки, а в весе правил, меняется CSS Specificity, об этом есть абзац в статье. Плюс, в BEM всегда понятно, на каком блоке или элементе срабатывает модификатор, потому что модификатор всегда привязан к блоку или элементу, «абстрактных» модификаторов нет вообще.
Про структуру — вообще, структура должна быть описана шаблоном, это не уровень CSS, и тем более не JS. Жизнь не идеальна, но меньше связности == меньше регрессий при правках.
1. Миксы. Очень часто надо «смешать» несколько БЭМ-элементов на одной ноде, и если нет префиксов и имя элемента не содержит имени блока, совершенно неясно, какой элемент к какому блоку относится.
2. Работа с BEM из JavaScript. Удобно получать готовую ссылку на элемент по имени класса, а не делать вложенный поиск по селекторам.
3. Вес (специфичность) селекторов и возможности переопределения и доопределения стилей. У селектора
.block > .elem1 > .elem2иной вес, чем у.block__elem2, переопределить его можно только через селектор такого же веса.4. Гибкость HTML. В БЭМ вообще не очень приветствуется, если элементы и их отображение сильно зависят от структуры. Обойтись без этого сложно, но специально фиксировать, что элемент — прямой потомок (селектор
>) — неудобно, завтра ваш коллега добавит div-обёртку и все стили сломаются. В БЭМ, когда он ещё был АНБ, иногда писали селекторы вида.block-name .elem, без селектора>, но отказались (см. пункт [1]).Кстати, БЭМ не должен отображать структуру HTML :) Его задача — перевести DOM-дерево в BEM-дерево, наложив сверху CSS-классы как overlay, и структура при этом возникает новая.