Методология оставляет вам право выбирать, что назвать элементом, а что блоком.

Лично я предпочитаю примешивать самодостаточные внутренние блоки к элементам внешнего блока так:

<div class="header">
    <div class="header__logo b-logo b-logo_context_header">
        ...
    </div>
</div>

Т.е. я могу управлять данным DOM-узлом, обращаясь к нему как к элементу блока header (например, позиционируя его), а так же при помощи его контекстной моды b-logo_context_header управлять внешним видом и поведением.

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

@Nekto-github Любые сущности можно вкладывать (и не вкладывать) друг в друга без ограничений, лишь бы это отражало реальную структуру интерфейса.

В случае с шапкой, как верно заметил @gruzzilkin, есть смысл не только выделить логотип, выпадающий список с языками, меню навигации и прочие сущности в отдельные вложенные блоки, но и смиксовать их с элементами самой шапки. Это позволить реализовать сами блоки универсально, без знания о контексте шапки, а всю специфику про шапку описывать в элементах шапки. Тогда блоки можно будет смело реиспользовать в других частях макета, а при рефакторинге и замене каких-то блоков на другие, например, из внешней библиотеки, не потребуется думать о том, как они должны быть спозиционированы.

Помимо того, что можно вкладывать блоки в другие блоки или элементы и миксовать несколько блоков (или блок + элемент) на одной DOM-ноде, можно разместить один блок на нескольких DOM-нодах (при использовании i-bem.js это достигается за счет установки одикавого id в js-параметрах блока).

PS: БЭМ, а не Бем ;)

Вроде бы понятно, спасибо. Как я понял, вложенные блоки лучше НЕ называть таким образом, что имя блока содержит информацию об имени родительского блока. То есть, в моем примере вложенную в ячейку форму лучше назвать b-form, а не b-cell-form или b-table-cell-form.

Сейчас я расчленил блок b-head на следующие элементы:

b-head__logo

b-head__language

b-head__navigation

Внутрь каждого элемента вставил следующие блоки:

b-logo (b-logo__graphic, b-logo__text)

b-language (b-language__flag, b-language__droplist)

b-navigation (b-navigation__btn1[2,3..n], b-navigation__login-form, b-navigation__registration-form, b-navigation__search и т.п.)

Далее планирую в элементы этих блоков опять встраивать еще кое-какие блоки. Чукча правильно делает?

В оформлении постов используется markdown, для кода можно использовать выделение в backtick (`).

Деление вполне ок, только для кнопок внутри b-navigation наверняка найдется какой-то общий одинаковый код. Поэтому там следует использовать модификаторы: b-navigation__btn b-navigation__btn_pos_{1, 2, n}.

Ааа, вот оно как. Понятно теперь. Спасибо!

@Nekto-github Выделять элементы из блоков лучше в момент оживления дизайна или верстки. На этапе проектирования проще оперировать сущностями одного типа. В данном случае, это просто блоки или боксы. Ну и, конечно, никакой информации в них о родителе быть не должно. Часто у начинающих вижу названия типа header__mainMenu__item_selected — пришел к мысли, что это из-за непонимания смысла использования элементов, а коли можно и без них — то лучше по началу просто избегать их и оперировать только блоками.

Да, я тоже такой огород нагородил, когда начал переводить прототип на бэм. Советы из данного треда помогли причесать мои структуры. Тоже подумал, что блок от элемента уж очень мало отличается, вроде бы как. Но понимание этого отличия постепенно приходит. Оно, наверное, является очевидным для разработчиков, но в мозгу дизайнера кристаллизуется как вещь в себе, поначалу безотчетно и почти не обосновано - из-за специфики работы чаще приходится в башке жонглировать образами, а не структурами.

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

Вообще хотелось бы больше информации о БЭМ именно в разрезе дизайна и прототипирования (без html и кода)

У коллег тоже часто возникают трудности именно в прототипировании. Согласен, что мало информации. @tadatuta а у вас не было такого?

Можно попросить @kovchiy рассказать о своем опыте (с примерами кода), в дополнение к статье https://medium.com/@kovchiy/70bb2d0d58be. И наверняка он пользуется еще чем-нибудь, кроме https://github.com/kovchiy/jblock.

@gruzzilkin :+1:

Ну как-нибудь попробую.

Беда в том, что рано или поздно ты закапываешься в собственный инструмент с кучей удобных и понятных одному тебе ручек, и через пару месяцев на тебя смотрят, как на умалишенного, погрязшего в сотне абстракций.

@kovchiy уже :+1:

@zxqfox Есть доклад @vithar в Риге, который частично затрагивает эту тему.

Но про прототипирование на БЭМ действительно лучше Дани никто не расскажет.

@kovchiy расскажи на следующем внешнем бэмапе, пожалуйста.

@kovchiy @vithar во-первых, можно собрать команду про это в ноябре на хакатоне

во-вторых, есть https://tech.yandex.ru/events/bemup/2-september-2014/talks/2189/ и можно спрашивать Антона

робко А в Казани не будет чего-нибудь такого случайно?

Ближайший, наверное, в бывшем Свердловске. @mursya ?

@Nekto-github приезжайте на хакатон :palm_tree:

с пылу с жару видео про прототипирование с БЭМ от @verybigman https://tech.yandex.ru/events/bemup/6-september-2014/talks/2189/

ближайшее — едем на РИФ в Воронеж, будем с @tadatuta там со 2 по 5 октября

далее — Хакатон в Москве, приезжайте https://tech.yandex.ru/events/bemup/15-november-2014/

mursya Любопытно конечно, но жаль что опять сталкиваемся с кодом. В презентации нет ничего, чего нельзя было бы сделать с помощью базового функционала Axure (прототип из которого можно вьюить на любом устройстве), однако кода не то чтобы много, но он есть, и требует подключения библиотек и каких-то муторных настроек.

Почитал статью kovchiy о преодолении потолков средств прототипирования с помощью кода ( https://medium.com/@kovchiy/70bb2d0d58be ). Тезис неопровержимый, однако жизнь дизайнера и без кода нелегка. Да и с ходу не могу придумать пример интерфейса, прототип которого нельзя было бы просто нарисовать и заанимировать редакторами графики/видео.

@Nekto-github не бойся ты кода как огня! Представь что это просто метод для описания порядка блоков. Просто вот такой документ. Даже не обладая знаниями программирования разобраться в BEMJSON не составит труда. Лучше один раз это сделать и все будет хорошо.

Касательно Axure, да да как бы можно. Но рассказ не про это. А про то что это практически законченный протитип приложения. Это не картинки, это не видео и даже не гиф, упаси господи. Ты реально можешь пользоваться этим приложением и реалтайм вносить корректировки на всех устройствах подопытных:) Таки мощь!:)

verybigman Ну хорошо, уговорили. Когда-то давно я создал калькулятор на флеше и это была единственная вещь, которую я запрограммировал и она работала. Рожденный ползать летать не смог. Думаю, раз бэм вживается в мой дизайн, можно и покодить опять попробовать. Отчитаюсь, надеюсь (но не скоро, надеюсь к тому времени тут появится более гуманный форум))

Однако чтобы опять подкинуть ложку дегтя, припомню типичный случай из жизни дизайнера - заказчик/руководитель стоит за спиной и просит сдвинуть объект на пиксель туда-сюда в течение нескольких часов. К сожалению такой маразм был, есть и будет. Тут акшур и подобные проги, а также классические графические пакеты не заменимы.

Nekto-github вот тебе лопата мёда:) Ты в состоянии объяснить заказчику как проектировать интерфейсы правильно. Что ты не делаешь г и создаешь практичные универсальные блоки интерфейсов. Попиксельный сдвиг сродни игре шрифтами:) Блоки интерфейса располагаются не как душе угодно, а подчиняясь строгим правилам. И подвинув что-то одно скорее всего ты ломаешь общий алгоритм и картину.

Доклад Антона @adrior про прототипирование: https://www.youtube.com/watch?v=vB8dnq84RZ8&list=UU7CpoLtWAIn4SCs0dv1Y0Wg&index=4

@tadatuta @adrior есть ссылка на презентацию этого доклада?

Есть ли ещё материалы по организации дизайна/прототипирования с помощью БЭМ? Особенно интересна практика по созданию собственной библиотеки блоков для этих целей.

@Guria По большому счету библиотеки делаются по принципу берешь и делаешь. Чаще всего блоки отлаживаются в момент разработки, и далее выносятся сначала на отдельный уровень, а дальше уносятся все уровни, которые можно унести, в отдельную библиотеку. Если не в 100% случаев, то в 90% точно.

Посмотрите как это сделано в bem-components, bem-content — поселднее время все чаще вижу разделение разметки и рюшечек, и базовые библиотеки не исключение, рюшечки вынесены на уровни design/*.blocks