Comments 61
Так с чего же, все таки, начинается БЭМ?
Спасибо! Скажите, я правильно понимаю что вся идея (и соглашения об именовании) БЭМ исходит из того что в IE6 не поддерживается CSS-конструкция ">" (непосредственный потомок)?
Из-за этого в том числе, но не только. «Полные» имена для CSS-классов нужны, чтобы уменьшить контекстную зависимость. Тогда блоки можно будет, не боясь, вставить в другие блоки.
А что касается >, то элементы могут быть не только непосредственными потомками. Их можно как угодно вкладывать друг в друга.
А что касается >, то элементы могут быть не только непосредственными потомками. Их можно как угодно вкладывать друг в друга.
Прежде всего, идея основана на том, что IE6 не поддерживает множественные классы, поэтому появляются вот такие грабли:
Ну и селектор потомка, да.
class="menu__item menu__item_state_current" вместо нормальной цепочки: class="menu__item state_current", которую потом можно записать как: .menu__item.state_current { … } …для нормальных браузеров.Ну и селектор потомка, да.
Здесь опять же, не только IE6, но и контектсная зависимость.
Иногда всё-таки нужно использовать каскад и изменять элемент, если у блока (его родителя) есть определённый модификатор. В случае, когда модификатор не содержит имени блока, к которому относится, он может подействовать не только на элементы этого блока, но и на элементы вложенных блоков.
Иногда всё-таки нужно использовать каскад и изменять элемент, если у блока (его родителя) есть определённый модификатор. В случае, когда модификатор не содержит имени блока, к которому относится, он может подействовать не только на элементы этого блока, но и на элементы вложенных блоков.
Вопрос другой: зачем дублировать префикс родителя (тем самым, создавая потенциально менее гибкие элементы конструктора) вместо того, чтобы писать всё цепочками?
При условии отказа от IE6, конечно же.
При условии отказа от IE6, конечно же.
не совсем, дублирование родительского блока нужно и для того
— чтобы не пересеклись имена элементов, иначе все равно везде прийдется писать каскад от блока типа
— чтобы работая со сгенерированным кодом (в любом вебинспекторе) было сразу понятно к какому блоку относится элемент и модификатор
— в случае когда происходят миксы эелментов к блоку и наоборот, и элементов одного блока к элементам другого — без дублирования названия блока будет ад
основная мысль: БЭМ это не только css — он на всех уровнях технологий. Поэтому вариант при котором будут потенциальные пересечения именования нужно исключить на корню.
— чтобы не пересеклись имена элементов, иначе все равно везде прийдется писать каскад от блока типа
.block elem.elemmod что тоже не очень удобно— чтобы работая со сгенерированным кодом (в любом вебинспекторе) было сразу понятно к какому блоку относится элемент и модификатор
— в случае когда происходят миксы эелментов к блоку и наоборот, и элементов одного блока к элементам другого — без дублирования названия блока будет ад
основная мысль: БЭМ это не только css — он на всех уровнях технологий. Поэтому вариант при котором будут потенциальные пересечения именования нужно исключить на корню.
Например, вот за этим
Кроме того, из JS находить b-block1_mod_val быстрее, чем b-block1.mod_val
<div class="b-block1 b-block1_mod_val b-block2 b-block2_mod_val"
Кроме того, из JS находить b-block1_mod_val быстрее, чем b-block1.mod_val
А вот такой сложный вопрос: если бы с самого начала не было IE6, был ли БЭМ концептуально таким же?
Да, как минимум причина «в IDE не видно по названию файла, к какому блоку относится модификатор» была бы неизменна. С точки зрения технологи — как только дошли до модификации JS, уже возникли бы проблемы, решение которых подвело бы к тому, что мы имеем сейчас.
Или вот возможность выносить элемент за пределы блока в DOM-структуре тоже «концептулаьно» появилась не сразу. А она нужна, например чтобы для b-form-checkbox (как-нибудь зарелизим) размещать b-form-checkbox__label где угодно.
Или вот возможность выносить элемент за пределы блока в DOM-структуре тоже «концептулаьно» появилась не сразу. А она нужна, например чтобы для b-form-checkbox (как-нибудь зарелизим) размещать b-form-checkbox__label где угодно.
Да. Что интересно, практически каждое архитектурное решение обусловлено более чем одной причиной. Это позволяет надеяться, что мы нащупали некие «глубинные принципы» к которым сходятся задачи/проблемы из разных областей.
Пробовал как-то знакомиться с бемом, скажем если мы пишем яндекс то да, технология оправдывает себя, если мы пишем что-то где меньше 100 шаблонов т оя бы все же не стал использовать бем в чистом виде, ибо грамотные цепочки позволили бы ускорить процесс.
ну и про IE6 забыли давно уже ) пора юзерам с этим браузерам таки увидеть печальную картину с неработающем сайтом.
ну и про IE6 забыли давно уже ) пора юзерам с этим браузерам таки увидеть печальную картину с неработающем сайтом.
Мне тоже кажется что на небольших проектах БЭМ будет скорее тормозить процесс, нежели ускорять его. Так как нужно выполнять большое количество лишних действий, сборка, описание структуры страницы, создание всей этой мега-разветвленной системы папок и т. д.
UFO just landed and posted this here
Что-то вы не о том, чем мне помогут блоки наработанные? если для каждого сайта свой layout свой css которые не перекочевывают от сайта к сайту. Придется каждый раз с нуля писать эти блоки и тд и тп.
Давайте взглянем почему ребята из яндекса писают кипятком от слова БЭМ? ))
Все начиналось с того что был сайт яндекса, жил себе потихоньку, жил и разростался, компания начинала осваивать новые области, появились новости, маркет и ещё огромное количество подразделов, в свою очередь скажем поиском яндекса занимается одна команда (к примеру в Москве), а вот яндекс-маркетом другая где-нибудь в Питиере. А сайт один и стилистика сайта должна быть одна, а тут кто-то решил чуть поменять меню и все у дргих съехало ну или же пришлось бы каждый сайт верстать с нуля в общем стиле.
Пришел БЭМ и теперь каждая команда разработчиков имеет набор блоков которые уже реализую какую-то часть интерфейса в стиле сайта и которые НЕЗАВИСИМЫ!!! то есть теперь каждая команда берет нужный блок вставляте куда надо и вуаля все отрисовалось, а если надо чтобы список был горизонтальный скажем а не вертикальный, добавляем модификатор и опа мы ничего не сломали.
Я сам использовал бэм на одном из проектов, был крупный сайт — торговая площадка ) Тогда прада ещё БЭМ инструментов не было и писали для сборки. Но в общем подход оправдал себя! Но в итоге набралось огромное количество этих блоков так как сайт был очень бтольшой.
Теперь же стандартный сайт: новости, каталог, гостевая, галерея, статические страницы это не для БЭМ здесь хорошо бы использовать цепочки в css .sidebar-left .menu {} .sidebar-right .menu {} вот это тут реально время сэкономит и поможет поддерживать так как:
1) над сайтом работает одна комагда (пусть там и 4-5 человек не суть, но одна и вместе)
2) в сайте нет 100 шаблонов в которых можно запутаться и упустить скрытые зависимости
Давайте взглянем почему ребята из яндекса писают кипятком от слова БЭМ? ))
Все начиналось с того что был сайт яндекса, жил себе потихоньку, жил и разростался, компания начинала осваивать новые области, появились новости, маркет и ещё огромное количество подразделов, в свою очередь скажем поиском яндекса занимается одна команда (к примеру в Москве), а вот яндекс-маркетом другая где-нибудь в Питиере. А сайт один и стилистика сайта должна быть одна, а тут кто-то решил чуть поменять меню и все у дргих съехало ну или же пришлось бы каждый сайт верстать с нуля в общем стиле.
Пришел БЭМ и теперь каждая команда разработчиков имеет набор блоков которые уже реализую какую-то часть интерфейса в стиле сайта и которые НЕЗАВИСИМЫ!!! то есть теперь каждая команда берет нужный блок вставляте куда надо и вуаля все отрисовалось, а если надо чтобы список был горизонтальный скажем а не вертикальный, добавляем модификатор и опа мы ничего не сломали.
Я сам использовал бэм на одном из проектов, был крупный сайт — торговая площадка ) Тогда прада ещё БЭМ инструментов не было и писали для сборки. Но в общем подход оправдал себя! Но в итоге набралось огромное количество этих блоков так как сайт был очень бтольшой.
Теперь же стандартный сайт: новости, каталог, гостевая, галерея, статические страницы это не для БЭМ здесь хорошо бы использовать цепочки в css .sidebar-left .menu {} .sidebar-right .menu {} вот это тут реально время сэкономит и поможет поддерживать так как:
1) над сайтом работает одна комагда (пусть там и 4-5 человек не суть, но одна и вместе)
2) в сайте нет 100 шаблонов в которых можно запутаться и упустить скрытые зависимости
Для небольшого статического сайта в принципе все равно, каким подходом руководствоваться. Потому, что ключевое слово здесь — «небольшой». Небольшие нагрузки, небольшое количество страниц и, собственно, блоков.
UFO just landed and posted this here
мне кажется blueprint и html5-boilerplate — разные вещи, первый — это фреймворк для верстки, второй это голая основа.
И я с вами не соглашусь, у меня обычно блок новостей отличается и отличается довольно сильно и общая структура разная. Если делать однотипные сайты на вордпрессе то там можно и один шаблон переделывать там все одно и тоже. а так БЭМ это геморой в тех проектах над которыми я работаю в том числе и из-за их структуры.
Мое мнение: есть большие интернет порталы — для которых бем спасение, есть обычные сайты для который он вреден. И я это проверил на своем опыте реализуя и то и то разными способами.
И я с вами не соглашусь, у меня обычно блок новостей отличается и отличается довольно сильно и общая структура разная. Если делать однотипные сайты на вордпрессе то там можно и один шаблон переделывать там все одно и тоже. а так БЭМ это геморой в тех проектах над которыми я работаю в том числе и из-за их структуры.
Мое мнение: есть большие интернет порталы — для которых бем спасение, есть обычные сайты для который он вреден. И я это проверил на своем опыте реализуя и то и то разными способами.
Вы правы, это требует определённой воли, даже если подход оправдывает себя.
Мы в свою очередь постоянно боремся над упрощением и отказом от рутинных операций. В частности, файлы руками никто не создаёт, для этого есть БЭМ инструменты, заботящиеся о правильном нэйминге и даже предоставляющие дефолтный контент.
Сборка осуществляется не прямым набором команд, а при помощи GNUmakefile, реализованного с учётом нужд проекта. Это сводит сборку к запуску одной команды.
Что не набирать даже эту команду, мы пользуемся утилитой Monkey Joe. Она отслеживает изменения файлов по нотификациям файловой системы и запускает всё, что нужно, в фоне.
В данный момент разрабатывается штука с рабочим названием bem server, для того, чтобы с проектами по архитектуре БЭМ можно было работать «из коробки».
Мы в свою очередь постоянно боремся над упрощением и отказом от рутинных операций. В частности, файлы руками никто не создаёт, для этого есть БЭМ инструменты, заботящиеся о правильном нэйминге и даже предоставляющие дефолтный контент.
Сборка осуществляется не прямым набором команд, а при помощи GNUmakefile, реализованного с учётом нужд проекта. Это сводит сборку к запуску одной команды.
Что не набирать даже эту команду, мы пользуемся утилитой Monkey Joe. Она отслеживает изменения файлов по нотификациям файловой системы и запускает всё, что нужно, в фоне.
В данный момент разрабатывается штука с рабочим названием bem server, для того, чтобы с проектами по архитектуре БЭМ можно было работать «из коробки».
В бэм все должно(желательно) иметь свой класс, что бы не было контекстной зависимости. Что это значит на практике?
В бэм есть возможность распределения блока по не скольким блокам и дублирование элементов блока, и по этому, у каждого элемента блока должен быть класс, который отвечает за его внешний вид, вне зависимости от родителя. С одной стороны избыточно и непривычно, а с другой — удобно в использовании и легко читаемо и изменяемо.
В бэм есть возможность распределения блока по не скольким блокам и дублирование элементов блока, и по этому, у каждого элемента блока должен быть класс, который отвечает за его внешний вид, вне зависимости от родителя. С одной стороны избыточно и непривычно, а с другой — удобно в использовании и легко читаемо и изменяемо.
(возможно не заметил в ответах)
Ещё одна очень важная причина использования БЭМ — скорость рендеринга страницы.
Подробнее: уникальные одиночные селекторы (классы) отрабатывают быстрее чем множественные (.item_new быстрее .item.new или .items > .new). И чем больше вхождение уникальных селекторов, по сравнению с множественными, тем быстрее рендеринг.
Ещё одна очень важная причина использования БЭМ — скорость рендеринга страницы.
Подробнее: уникальные одиночные селекторы (классы) отрабатывают быстрее чем множественные (.item_new быстрее .item.new или .items > .new). И чем больше вхождение уникальных селекторов, по сравнению с множественными, тем быстрее рендеринг.
Отчасти, это сделано чтобы рендеринг был быстрее.
Раз так в 600 быстрее.
Чем более сложные классы вы используете — тем больше браузеру нужно произвести действий чтобы понять как отобразить тот или иной элемент.
Раз так в 600 быстрее.
Чем более сложные классы вы используете — тем больше браузеру нужно произвести действий чтобы понять как отобразить тот или иной элемент.
Домен 6-го уровня шикарный %)
bem-method.toivonen.veged.dev.yandex-team.ru/pages/beginning/beginning.ru.html
…ой, или это не та ссылка?
bem-method.toivonen.veged.dev.yandex-team.ru/pages/beginning/beginning.ru.html
…ой, или это не та ссылка?
UFO just landed and posted this here
а какие вам известны аналоги БЭМ, которые существовали в момент начала разработки БЭМ?
UFO just landed and posted this here
не понимаю, почему такой вывод
полных аналогов БЭМ (в том смысле в каком я его понимаю для себя) мне не известно — отсюда и вопрос (я с интересом бы их изучил)
полных аналогов БЭМ (в том смысле в каком я его понимаю для себя) мне не известно — отсюда и вопрос (я с интересом бы их изучил)
это в каком смысле?
это не важно, я готов почитать про аналоги в ± любых смыслах
ну, про мой велосипед ты в курсе? nin-jin.github.com/wc/wc/wc.doc.xml
ага, по моему опыту, верстка занимает несравнимо меньше времени, относительно остального. для большинства проектов это будет экономия на спичках, если вообще будет экономия. а если стили будут собираться для каждой конкретной страницы, если я правильно помню концепцию, то накладные расходы будут вообще огромны, потому что из десятков интернет-магазинов, которые я делал, файл со стилями редко превышает несколько сотен строк, там просто нет ничего сложного в разработке и отладке, особенно с накопленным опытом.
мне кажется тут ситуация такая же как и с большинством фреймворков. то есть из проекта на миллиард можно сделать проект на десять миллионов, но и из проекта на десять тысяч получается тот же миллион. хотя, системный подход — это правильно в любом случае.
мне кажется тут ситуация такая же как и с большинством фреймворков. то есть из проекта на миллиард можно сделать проект на десять миллионов, но и из проекта на десять тысяч получается тот же миллион. хотя, системный подход — это правильно в любом случае.
UFO just landed and posted this here
В статье речь идёт не только о CSS-вёрстке, но также и о шаблонах и JavaScript компонентах. JavaScript может весить довольно много, если речь идёт о богатых приложениях.
Статические файлы не обязательно собирать для каждой конкретной страницы. Можно объединить всё в один файл, или выделить какие-то общие (common) куски + постраничные файлы. Такие операции возможны благодаря командам bem decl merge и bem decl subtract (bem tools).
В статье описана модель при которой каждая страница имеет свои CSS и JS файл, потому что такая модель прижилась у нас: мы проанлизировали поведение пользователей и скорость загрузки при различных вариантах, и этот оказался оптимальным. Дальше мы будем развиваться в следующем направлении: автоматический анализ статистики о том, какие страницы пользователи загружат вместе может влиять на сборку, внося логику в выделение этих «общих» кусков между страницами.
Статические файлы не обязательно собирать для каждой конкретной страницы. Можно объединить всё в один файл, или выделить какие-то общие (common) куски + постраничные файлы. Такие операции возможны благодаря командам bem decl merge и bem decl subtract (bem tools).
В статье описана модель при которой каждая страница имеет свои CSS и JS файл, потому что такая модель прижилась у нас: мы проанлизировали поведение пользователей и скорость загрузки при различных вариантах, и этот оказался оптимальным. Дальше мы будем развиваться в следующем направлении: автоматический анализ статистики о том, какие страницы пользователи загружат вместе может влиять на сборку, внося логику в выделение этих «общих» кусков между страницами.
В статье ни слова о логике блока или необходимых ему… таблиц в БД например.
БЭМ применим только к организации шаблонов?
БЭМ применим только к организации шаблонов?
Да, БЭМ штука крутая, только я мануалил тут: bem.github.com/bem-method/html/all.ru.html
Заюзал require.js с виджетами от jqueryUI, все в разы проще «вендорной» яндексовой методологии, по подобию масштабируемой архитектуры от azproduction
Заюзал require.js с виджетами от jqueryUI, все в разы проще «вендорной» яндексовой методологии, по подобию масштабируемой архитектуры от azproduction
Не смог удержаться. Вы полагаете, что _хорошее_ объяснение должно быть большим и с картинками? :-)
Отчего такая проблема с формализацией мышления? Смотрите, вот я сейчас опишу вашу технологию.
В основе ее 2 принципа:
1. разбиение сложных сценариев на независимые от контекста мини-сценарии: специально организованные группы элементов (блоки);
2. компиляция веб-проектов: генерация конечных файлов по шаблонам;
Элементы DOM (как видимые, так и невидимые) могут логически быть объединены в единую группу — блок, которая реализует небольшой (законченный) сценарий, например, «меню» или «форма авторизации пользователя». В блок также включены стили и JavaScript-код, т.е. его поведение не зависит от окружения, поэтому
a) его разработку можно изолировать;
b) его можно использовать как «строительный кирпич» в сложных сценариях;
Изоляция блока в контексте веб-страницы достигается правильным именованием: класс стиля элемента блока строится иерархически от имени блока до имени элемента, id селекторы не используются. Такой блок может работать в любом окружении.
"Компиляция веб-проектов" означает, что конечный код веб-страницы всегда строится автоматически по шаблону. Для чего разработан ряд инструментов, позволяющих сосредоточится на конкретной работы: созданию блоков и разметке шаблонов, переложив сложности, связанные с интеграцией на автоматические средства.
Далее, пару примеров, ссылка на ваши замечательные утилиты и — вуаля — все понятно.
Человек прочтет и запомнит главное — принципы. Независимость от окружения и компиляция по шаблонам.
Остальное — детали. Кому-то нужны, а кому-то — нет.
А вашу простыню выбросить.
Отчего такая проблема с формализацией мышления? Смотрите, вот я сейчас опишу вашу технологию.
В основе ее 2 принципа:
1. разбиение сложных сценариев на независимые от контекста мини-сценарии: специально организованные группы элементов (блоки);
2. компиляция веб-проектов: генерация конечных файлов по шаблонам;
Элементы DOM (как видимые, так и невидимые) могут логически быть объединены в единую группу — блок, которая реализует небольшой (законченный) сценарий, например, «меню» или «форма авторизации пользователя». В блок также включены стили и JavaScript-код, т.е. его поведение не зависит от окружения, поэтому
a) его разработку можно изолировать;
b) его можно использовать как «строительный кирпич» в сложных сценариях;
Изоляция блока в контексте веб-страницы достигается правильным именованием: класс стиля элемента блока строится иерархически от имени блока до имени элемента, id селекторы не используются. Такой блок может работать в любом окружении.
"Компиляция веб-проектов" означает, что конечный код веб-страницы всегда строится автоматически по шаблону. Для чего разработан ряд инструментов, позволяющих сосредоточится на конкретной работы: созданию блоков и разметке шаблонов, переложив сложности, связанные с интеграцией на автоматические средства.
Далее, пару примеров, ссылка на ваши замечательные утилиты и — вуаля — все понятно.
Человек прочтет и запомнит главное — принципы. Независимость от окружения и компиляция по шаблонам.
Остальное — детали. Кому-то нужны, а кому-то — нет.
А вашу простыню выбросить.
У нас есть текст-конспект http://bem.github.com/bem-method/html/all.ru.html
Пользователи писали, что им ничего не понятно.
Блок — это не обязательно DOM-элементы. Могут быть абстрактные блоки, не представленные в DOM. Об этом в статье не написано, т.к. слишком сложно. Но и проводить параллель DOM-элемент — блок не нужно.
Компиляция web-проектов — это всё-таки не про шаблоны.
Под компиляцией подразумеваются какие-то действия, которые превращают «код для людей» в «код для роботов». Компиляция может быть применима и к шаблонам, и к статике. Сам факт наложения шаблонов на исходные данные компиляцией не является, тк это не пре-подготовка, на runtime.
Пользователи писали, что им ничего не понятно.
Блок — это не обязательно DOM-элементы. Могут быть абстрактные блоки, не представленные в DOM. Об этом в статье не написано, т.к. слишком сложно. Но и проводить параллель DOM-элемент — блок не нужно.
Компиляция web-проектов — это всё-таки не про шаблоны.
Под компиляцией подразумеваются какие-то действия, которые превращают «код для людей» в «код для роботов». Компиляция может быть применима и к шаблонам, и к статике. Сам факт наложения шаблонов на исходные данные компиляцией не является, тк это не пре-подготовка, на runtime.
В своих собственных разработках мы постепенно отказываемся от XSL в пользу собственного JavaScript-based шаблонного движка XJST. Этот шаблонизатор вобрал в себя всё то, что нам нравилось в XSL, но реализует это с производительностью JavaScript как на сервере, так и на клиенте.
Я правильно понимаю, производительность JS у вас получается выше чем скорость XSL трансформаций? Или о чем речь?
Злесь речь идёт о JavaScript-bаsed шаблонизаторе, который мы разрабатываем и используем. В качестве входных данных используется JSON. Преобразования могут происходить везде, где есть JavaScript-интерпретатор: то есть и на сервере, и на клиенте. По сравнению с XSL производительность выше в 10 раз, по сравнению с TT2 — в 3 раза.
Более подробную информацию можно получить из выступления Сергея Бережного (veged) на YAC2011. Так же есть питерское выступление с таким же контентом, но другими вопросами из зала.
В основе лежит шаблонизатор XJST, он разрабатывается Open Source, вот репозиторий на GitHub.
Для работы непосредственно с блоками, есть «обёртка», дополнительный синтаксис, который называется BEMHTML. Непосредственно о синтаксисе можно узнать из поста про синтаксис BEMHTML. Конкретные блоки, разрабатываемые с применением этого шаблонизатора в Open Soruce — это библиотека блоков bem-bl (репозиторий на GitHub, разрабатываемый сайт). Описания реализации блоков публикуются в клубе на Я.ру (поиск по тегу bemhtml), так можно познать особенности.
Более подробную информацию можно получить из выступления Сергея Бережного (veged) на YAC2011. Так же есть питерское выступление с таким же контентом, но другими вопросами из зала.
В основе лежит шаблонизатор XJST, он разрабатывается Open Source, вот репозиторий на GitHub.
Для работы непосредственно с блоками, есть «обёртка», дополнительный синтаксис, который называется BEMHTML. Непосредственно о синтаксисе можно узнать из поста про синтаксис BEMHTML. Конкретные блоки, разрабатываемые с применением этого шаблонизатора в Open Soruce — это библиотека блоков bem-bl (репозиторий на GitHub, разрабатываемый сайт). Описания реализации блоков публикуются в клубе на Я.ру (поиск по тегу bemhtml), так можно познать особенности.
Всегда считал добавление класса элементу или блоку избыточным, если в css отсутствует его описание
Sign up to leave a comment.
С чего начинается БЭМ?