Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 56
Похоже на rscss.io, только там более продуманно :-)
Tag selectors are fine, but they may come at a small performance penalty…
Первая часть утверждения в комментариях не нуждается, но вот что это за проблемы с производительностью селекторов в 2016 году?
Посмотрел их доку, а там почти то же самое, что получилось у меня в ходе просеивания БЭМа. Плюс-минус мелкие детали.
Красивые у вас примеры, в реальной жизни все не так живописно.
Немного утрируя, я сделал BEM classname generator, который наглядно демонстрирует почему лично я недолюбливаю BEM.
Порой приходится такие макаронины видеть, глаза такой код не способны распознать на лету и тут необходимо вчитываться. Другими словами борьбе с коллизиями бесспорно выигрываем, но проигрываем в читаемости кода. Тут уж в зависимости от проекта и команды нужно решать что приоритетнее.
Немного утрируя, я сделал BEM classname generator, который наглядно демонстрирует почему лично я недолюбливаю BEM.
Порой приходится такие макаронины видеть, глаза такой код не способны распознать на лету и тут необходимо вчитываться. Другими словами борьбе с коллизиями бесспорно выигрываем, но проигрываем в читаемости кода. Тут уж в зависимости от проекта и команды нужно решать что приоритетнее.
.option-environment__competition-factory--increase-factory
[my_environment_competition="increase"]
Все зависит от фантазии разработчиков, но у нас на проектах по большей части хватает коротких, лаконичных названий блоков, изредка всплывают названия блоков/элементов (второе намного реже) из двух слов.
Спасибо за пример. Проблема действительно имеет место быть.
Тем не менее, не могу не отметить, что BEM classname generator местами избыточно утрирует ситуацию. К примеру, многие генерируемые ним элементы должны быть раздельными блоками, что не только сокращает название в два раза, но и делает их портативными.
В модификаторах также крайне редко встречаются такие длинные названия.
Тем не менее, не могу не отметить, что BEM classname generator местами избыточно утрирует ситуацию. К примеру, многие генерируемые ним элементы должны быть раздельными блоками, что не только сокращает название в два раза, но и делает их портативными.
В модификаторах также крайне редко встречаются такие длинные названия.
Уже год как пробую и тестирую различные варианты нейминга, и пришел к выводу, что мне не хватает еще одного уровня вложенности, я называю это «компонент». А для самих элементов часто хватает семантических имен (link,string,btn и т.д.). также сделал на этом принципе свой фреймворк. Кстати собираюсь статью написать как раз про него, там как раз будет две основных темы затронуто «Модификация БЕМ и Плейсхолдеры в SASS».
А выглядит это так «Компонент--модуль__элемент._модификатор». Кстати благодаря плейсхолдерамя избавился от необходимости писать несколько классов. И главное правило это то что тег имеет только один класс, и модификаторы.
А выглядит это так «Компонент--модуль__элемент._модификатор». Кстати благодаря плейсхолдерамя избавился от необходимости писать несколько классов. И главное правило это то что тег имеет только один класс, и модификаторы.
Возможно, Вам будет интересно: http://csswizardry.com/2015/03/more-transparent-ui-code-with-namespaces/
О как, Интересно было почитать. Особенно про автоподстановку. Кстати даже префиксы местами очень похожи же у меня например так.
obj-: Кастомизарованные элементы
Также есть сразу 3 зарезервированных компонента obj-header, obj-footer, obj-widget.
ui-: Стандартный набор элементов интерфейса.
layout-: Обвертки.
А вот тема cms-content тоже есть раньше этот блок называл wysiwig теперь typography.
А вот что не понравилось, и от чего как раз хотел избавиться я, так как на одном проекте вышел ад. "c-btn c-btn--positive qa-modal-accept"
obj-: Кастомизарованные элементы
Также есть сразу 3 зарезервированных компонента obj-header, obj-footer, obj-widget.
ui-: Стандартный набор элементов интерфейса.
layout-: Обвертки.
А вот тема cms-content тоже есть раньше этот блок называл wysiwig теперь typography.
А вот что не понравилось, и от чего как раз хотел избавиться я, так как на одном проекте вышел ад. "c-btn c-btn--positive qa-modal-accept"
Это еще и не полная версия — должно быть
Зато это позволяет очень гранулированно использовать классы и конфигурировать практически что угодно на лету.
Такой подход используется в нашем фреймворке, который используется в нашем генераторе статических веб-сайтов\стартер-ките. Это позволяет создавать большую часть уникальных страниц без написания единой новой строчки CSS.
o-btn c-btn c-btn--positive qa-modal-acceptЗато это позволяет очень гранулированно использовать классы и конфигурировать практически что угодно на лету.
Такой подход используется в нашем фреймворке, который используется в нашем генераторе статических веб-сайтов\стартер-ките. Это позволяет создавать большую часть уникальных страниц без написания единой новой строчки CSS.
Я это реализовал через плейсхолдеры, и миксин для их подключения, где все модификаторы передаем в качестве параметров.
К примеру:
%ui-btn {
&%base { display:block; color:blue; font-size:16px;padding:10px;}
&%red {color:red;}
&%small {font-size:10px; padding:4px;}
}
И подключение:
.obj--newsbtn { include extendUI('ui-btn',('btn'));}
.obj--newsbtn._readmore { include extendUI('ui-btn',('btn','red','small'));}
К примеру:
%ui-btn {
&%base { display:block; color:blue; font-size:16px;padding:10px;}
&%red {color:red;}
&%small {font-size:10px; padding:4px;}
}
И подключение:
.obj--newsbtn { include extendUI('ui-btn',('btn'));}
.obj--newsbtn._readmore { include extendUI('ui-btn',('btn','red','small'));}
Это позволяет создавать большую часть уникальных страниц без написания единой новой строчки CSS.
Вот она ключевая фраза, спасибо вам за неё. Еще раз ответил вам в конце статьи.
Мне тоже было интересно, спасибо. Ответил на идею поста в конце статьи, конечно, продолжая нахваливать BEM.
Мы понемногу становимся соавторами :)
Мы понемногу становимся соавторами :)
Применим ли БЕМ для организации JS кода в приложении? Я встречал только про верстку, html, css. Но есть люди, которые применяют это для структурирования основного кода SPA и переубедить их никак не получается… Подскажите плиз может где-то это описано. (я совсем не гуру БЕМ).
БЭМ для JS — это конечно перегиб. БЭМ нужен для организации модульности и избавления от коллизий, а в таких языках как JS для этого есть свои средства. Сейчас даже классы появились.
По моему опыту, БЭМ в JS применим только как наследие от CSS, когда нужно работать с классами, имеющимися в верстке.
БЭМ в первую очередь борется с глобальными колизиями, проблемами specifity, отсутсвием нативной модульности. Мне кажется, избыточно пытаться применить эту методологию в языке, который не имеет таких проблем (при правильной организации кода).
БЭМ в первую очередь борется с глобальными колизиями, проблемами specifity, отсутсвием нативной модульности. Мне кажется, избыточно пытаться применить эту методологию в языке, который не имеет таких проблем (при правильной организации кода).
конечно БЭМ применим для JS кода! главная суть БЭМ-а это «многоязычность» https://ru.bem.info/method/key-concepts/#Технология-реализации
вот документация про основную реализацию https://ru.bem.info/articles/bem-js-main-terms/ https://ru.bem.info/technology/i-bem/v2/i-bem-js/
если появятся дополнительные вопросы всегда можно получить ответ на форуме https://bem.info/forum/
вот документация про основную реализацию https://ru.bem.info/articles/bem-js-main-terms/ https://ru.bem.info/technology/i-bem/v2/i-bem-js/
если появятся дополнительные вопросы всегда можно получить ответ на форуме https://bem.info/forum/
вот ещё пара докладов по теме:
https://events.yandex.ru/lib/talks/689/
https://events.yandex.ru/lib/talks/302/
https://events.yandex.ru/lib/talks/689/
https://events.yandex.ru/lib/talks/302/
Спасибо, второй понравился больше, люблю ретроспективы ;)
Я сам из лагеря FLUX года эдак с 2008 и jQuery никогда не касался, поэтому не могу полноценно оценить все преимущества, но такие фундаментальные вещи, как автоматический вызов деструкторов, отсылающий нас к модному ныне React.js с его
WTF? :)
Я сам из лагеря FLUX года эдак с 2008 и jQuery никогда не касался, поэтому не могу полноценно оценить все преимущества, но такие фундаментальные вещи, как автоматический вызов деструкторов, отсылающий нас к модному ныне React.js с его
componentWillUnmount(), а также onclick="{json}" почти в точности повторяющий горячо любимые мной реактовские же this.props вызывают глубокое уважение.Нельзя голосовать (положительно!) за пользователей, у которых нет размещенных публикаций
WTF? :)
БЭМ — был полезен, но морально устарел. При современной компонентной разработке фронтенда, с возможностью инкапсуляции и байндинга стилей — вообще не нужен. Народ по иннерции пихает его куда можно и куда нельзя, но пора уже посмотреть на него свежим взглядом. Главная польза БЭМа в том, что в свое время он показал, что в стилях — должен быть порядок и за это ему спасибо.
Это вы про Shadow DOM и Web Components? Да, прийдет их время, и в начале статьи появится «не читайте этот устаревший бред, а используйте X». Но пока CSS решае.
CamelCase нотация для блоков радует глаз заядлых си-плюс-плюсщиков/яваскриптистов/рубистов«радует глаз» — так себе аргумент. Иногда привычки надо менять. Классы в css не чувствительны к регистру, а значит рано или поздно вы столкнётесь с проблемой конфликта идентификаторов отличающихся лишь регистром. Но не это самое страшное, а привычка к нечитаемой верблюжьей нотации: `ACMESubmitButton`, вместо более читаемой `acme-button-submit`.
Главное, что у блоков Box и Article не будет конфликтов даже если захотеть, и не придется ловить баги от того, что иногда модуль Article загружается раньше модуля Box и его стили получают другой приоритет.Конфликты будут на уровне элементов: `.Order .Button.is-submit` и `.ButtonGroup .Button.is-submit`. Проблема порядка подключения в случае bem легко решается сборщиком, отслеживающим зависимости в CSS.
.Article.is-new .Article-title { color: red }Банальный контрпример — дерево. Куча вложенных друг в друга одинаковых блоков и каждый пытается задать цвет для всех вложенных заголовков.
Большую часть наследуемых стилей возможно экранировать только с помощью жесткого переопределения всех этих стилей для каждого контейнера.Не надо экранировать то, что должно наследоваться. Например, блок не должен лезть со своим уставом (шрифтом) в чужой монастырь (страницу), а должен использовать те шрифты, что есть на странице. Но он может попросить шрифт «чуть-чуть по меньше» или подходящего его фону цвета.
Метод изложения на 5+
Особенно порадовало:
>и не благоухает своим CSS на всю страницу
Немного не понял по поводу «Всунуть Bootstrap».
Разве если его подключить, когда половина уже сверстана, он не поломает хоть что-нибудь тем, что напрямую стилизует элементы h1,p и т.д.?
Как можно его использовать изолировано в каком то блоке?
Особенно порадовало:
>и не благоухает своим CSS на всю страницу
Немного не понял по поводу «Всунуть Bootstrap».
Разве если его подключить, когда половина уже сверстана, он не поломает хоть что-нибудь тем, что напрямую стилизует элементы h1,p и т.д.?
Как можно его использовать изолировано в каком то блоке?
Поломает и сильно.
Бутстрап вообще ужасная кака, но на него много всяких штук завязано и приходится его терпеть.
У меня в проекте отдельная папка с файлами переопределения бутстраповских стилей поверх БЭМ.
Тут два стула — или ты делаешь подобный грязный хак (фу-фу-фу так делать, но приходится), или выкидываешь бутстрап и всё что он за собой тянет (много чего) и пишешь всё это с нуля (весьма накладно по времени).
Бутстрап вообще ужасная кака, но на него много всяких штук завязано и приходится его терпеть.
У меня в проекте отдельная папка с файлами переопределения бутстраповских стилей поверх БЭМ.
Тут два стула — или ты делаешь подобный грязный хак (фу-фу-фу так делать, но приходится), или выкидываешь бутстрап и всё что он за собой тянет (много чего) и пишешь всё это с нуля (весьма накладно по времени).
Спасибо! Стараюсь оживить скучные темы драмой :)
Отвечу на «всунуть Bootstrap». Если подключить Bootstrap, обернув его в класс-как-бы-блок с помощью SASS, то он будет ломать что-либо только внутри элементов с этим классом-блоком.
Отвечу на «всунуть Bootstrap». Если подключить Bootstrap, обернув его в класс-как-бы-блок с помощью SASS, то он будет ломать что-либо только внутри элементов с этим классом-блоком.
Из статьи может показаться, что БЭМ появился в 2015 году, как следствие несовершенства всех остальных подходов, а не 10 лет назад, как попытка взять под контроль табличный говнокод в Яндексе. В целом, очередная раздача костылей под красивое описание годных практик, которым БЭМ противоречит.
Из статьи может показаться, что БЭМ появился в 2015 году
А может и не показаться. Яваскрипт тоже запилили 20 лет назад, а когда он выстрелил.
Хотите сказать, что БЭМ в 2015 году выстрелил? Сомневаюсь, что БЭМ вообще когда-либо выстреливал, если вы не про выстреливание себе в ногу.
Мсье, вот вам краткий список говнокодящих стрелков в ноги для размышлений:
Google:
https://github.com/google/material-design-lite/wiki/Understanding-BEM
https://developers.google.com/web/fundamentals/performance/rendering/reduce-the-scope-and-complexity-of-style-calculations
Adobe:
http://topcoat.io/
Гайды от правительства США:
https://playbook.cio.gov/designstandards/getting-started/
Еще гайды:
http://www.joelambert.co.uk/article/bem-guidelines/
Снова гайды:
http://cssguidelin.es/
https://github.com/search?utf8=✓&q=bem — более 2k репозиториев по запросу bem
https://www.npmjs.com/search?q=bem — 600 пакетов по запросу bem
Статьи:
http://www.integralist.co.uk/posts/bem.html
http://blog.kaelig.fr/post/48196348743/fifty-shades-of-bem
https://css-tricks.com/bem-101/
http://montagestudio.com/blog/2013/10/24/BEM-syntax-with-ux-in-mind/
http://webdesign.tutsplus.com/articles/an-introduction-to-the-bem-methodology--cms-19403
https://medium.com/@andersonorui_/bem-sass-and-bootstrap-9f89dc07d20f#.rxjgrtbmt
http://www.creativebloq.com/css3/create-modular-and-scalable-css-9134351
http://code.tutsplus.com/articles/how-were-using-modules-to-organize-our-front-end-code--cms-22702
https://davidwalsh.name/starting-css
https://www.viget.com/articles/bem-multiple-modifiers-and-experimenting-with-attribute-selectors
http://www.juliecameron.com/blog/2013/11/06/bem-naming-for-sass-color-variables-what1/
https://www.bensmithett.com/bem-modifiers-multiple-classes-vs-extend/
http://blog.8thlight.com/nelsol-batalla/2014/08/01/bem-basics.html
http://www.sitepoint.com/bem-smacss-advice-from-developers/
http://blog.14islands.com/post/70395374262/our-principles-for-bem-sass
http://vanseodesign.com/css/block-element-modifier/
http://blog.moove-it.com/mastering-css-bem-and-itcss/
И так далее. В среднем блогмониторинг приносит пару новых статей про БЭМ в день.
Ну а из местных костылятелей табличного говнокода, кроме Яндекса могу предложить к изучению опыт
* mail.ru (https://habrahabr.ru/company/mailru/blog/250783/ + https://habrahabr.ru/company/mailru/blog/142193/ + https://habrahabr.ru/company/mailru/blog/263221/)
* http://www.rambler.ru/
* Альфа-банка (https://github.com/alfa-bank-dev/ui)
* http://learn.javascript.ru/
Ну и так далее.
PS: вы в предыдущем комментарии упомянули годные практики, которым БЭМ противоречит. Поделитесь?
Google:
https://github.com/google/material-design-lite/wiki/Understanding-BEM
https://developers.google.com/web/fundamentals/performance/rendering/reduce-the-scope-and-complexity-of-style-calculations
Adobe:
http://topcoat.io/
Гайды от правительства США:
https://playbook.cio.gov/designstandards/getting-started/
Еще гайды:
http://www.joelambert.co.uk/article/bem-guidelines/
Снова гайды:
http://cssguidelin.es/
https://github.com/search?utf8=✓&q=bem — более 2k репозиториев по запросу bem
https://www.npmjs.com/search?q=bem — 600 пакетов по запросу bem
Статьи:
http://www.integralist.co.uk/posts/bem.html
http://blog.kaelig.fr/post/48196348743/fifty-shades-of-bem
https://css-tricks.com/bem-101/
http://montagestudio.com/blog/2013/10/24/BEM-syntax-with-ux-in-mind/
http://webdesign.tutsplus.com/articles/an-introduction-to-the-bem-methodology--cms-19403
https://medium.com/@andersonorui_/bem-sass-and-bootstrap-9f89dc07d20f#.rxjgrtbmt
http://www.creativebloq.com/css3/create-modular-and-scalable-css-9134351
http://code.tutsplus.com/articles/how-were-using-modules-to-organize-our-front-end-code--cms-22702
https://davidwalsh.name/starting-css
https://www.viget.com/articles/bem-multiple-modifiers-and-experimenting-with-attribute-selectors
http://www.juliecameron.com/blog/2013/11/06/bem-naming-for-sass-color-variables-what1/
https://www.bensmithett.com/bem-modifiers-multiple-classes-vs-extend/
http://blog.8thlight.com/nelsol-batalla/2014/08/01/bem-basics.html
http://www.sitepoint.com/bem-smacss-advice-from-developers/
http://blog.14islands.com/post/70395374262/our-principles-for-bem-sass
http://vanseodesign.com/css/block-element-modifier/
http://blog.moove-it.com/mastering-css-bem-and-itcss/
И так далее. В среднем блогмониторинг приносит пару новых статей про БЭМ в день.
Ну а из местных костылятелей табличного говнокода, кроме Яндекса могу предложить к изучению опыт
* mail.ru (https://habrahabr.ru/company/mailru/blog/250783/ + https://habrahabr.ru/company/mailru/blog/142193/ + https://habrahabr.ru/company/mailru/blog/263221/)
* http://www.rambler.ru/
* Альфа-банка (https://github.com/alfa-bank-dev/ui)
* http://learn.javascript.ru/
Ну и так далее.
PS: вы в предыдущем комментарии упомянули годные практики, которым БЭМ противоречит. Поделитесь?
Я бы еще посоветовал использовать двубуквенный префикс, это позволит избежать конфликтов при подключении компонентов от разных вендоров.
Как писать БЭМ адекватно без тупых модификаторов и замороченного синтаксиса я писал в статье на блоге
Спасибо за статью
Здесь не все так гладко:
Это как раз в рамках методологии БЭМ. Если не ошибаюсь, называется уровнями переопределения, как раз для таких случаев — когда состояние блока контролирует вид его элементов. Реализуется оно либо именно так, как было сделанно в примере, либо так:
Однако стоит помнить, что такое переопределение в дальнейшем может принести множество проблем со specifity. Потому применять следует только в строго предписанных врачем количествах.
Я бы сказал, для классов используется kebab-case не потому, что он легче читается (это ведь субъективно), а просто как наследие самого html и css, которые как языки по умолчанию являются kebab-case (
.Article.is-new { … }
Здесь не все так гладко:
- Из такого чейнинга при изучении html-кода совершенно непонятно, на что влияет класс `.is-new` — на `Article`? Или может быть на какой-то иной блок в данной html-ноде? Ведь на одной ноде может быть несколько блоков или элементов.
- В случае наличия на одной html-ноде нескольких блоков это может привести к неприятным коллизиям.
- БЭМ не только пытается решить проблему коллизий, но еще и проблему specifity. И вот такой вот чейнинг как раз возвращает эту проблему. И во многих местах она серьезней, чем кажется
Можно вернуть в ваш BEM немного CSS:.Article.is-new .Article-title { color: red }
Это как раз в рамках методологии БЭМ. Если не ошибаюсь, называется уровнями переопределения, как раз для таких случаев — когда состояние блока контролирует вид его элементов. Реализуется оно либо именно так, как было сделанно в примере, либо так:
.article--is-new .article-title { color: red }Однако стоит помнить, что такое переопределение в дальнейшем может принести множество проблем со specifity. Потому применять следует только в строго предписанных врачем количествах.
CamelCase нотация для блоков радует глаз заядлых си-плюс-плюсщиков/яваскриптистов/рубистов, а еще помогает никогда не путать блоки и элементы.
Я бы сказал, для классов используется kebab-case не потому, что он легче читается (это ведь субъективно), а просто как наследие самого html и css, которые как языки по умолчанию являются kebab-case (
http-equiv, data-attribute в HTML, text-shadow, background-color в CSS). Консистентность.Ведь на одной ноде может быть несколько блоков или элементов.
Да, как раз в статье это условие специально уточнено прямо рядом с обсуждаемым примером:
Если следовать правилу «никогда не нарушать границы пространств имён» и каждому блоку выделять по отдельному элементу…
Однако стоит помнить, что такое переопределение в дальнейшем может принести множество проблем со specifity. Потому применять следует только в строго предписанных врачем количествах.
Да, вы совершенно правы. Выше vintage привел в контр-пример дерево. Добавлю это исключение в статью. Вообще, рекурсия средствами CSS решается не очень красиво.
Про kebab-case тоже всё верно, тут я посолил по вкусу. С другой стороны, либо CamelCase либо подчеркивания, которые отправляют меня назад в Perl. А на смесь двойных и одинарных тире я не согласен совсем.
Вот еще вспомнил хорошую статью по теме контекстуального стилизирования http://csswizardry.com/2015/06/contextual-styling-ui-components-nesting-and-implementation-detail/
Вот еще доклад со схожей темой: https://www.youtube.com/watch?v=nwS7M2L07uU. Идеи коррелируют и синтаксис интересный.
Однако, я бы все таки воздержался от таких решений. Слишком много узких мест.
Однако, я бы все таки воздержался от таких решений. Слишком много узких мест.
Вот ведь что странно: я согласен с основным тезисом автора, что БЭМ — это хорошо, а практически с каждой отдельной фразой — нет. Как так получилось-то? :)
Попробую аргументировать.
> BEM требует соблюдения строгих правил при разработке, не редко вступающих в конфликт со здравым смыслом небольших проектов, не сравнимых по ресурсам с Яндексом
Можно, пожалуйста, ссылки и цитаты с bem.info или какой-либо статьи/выступления от Яндекса, где рекомендации как-то противоречат здравому смыслу или как-то мешают на небольших проектах?
Мы тут некоторое время назад попросили у наших коллег из Поиска поискать в дампе всего интернета сайты, которые используют верстку по БЭМ и чиселка получилась о-о-очень нехилая.
Ну и я лично знаю немало студий и даже фрилансеров-одиночек, которые используют БЭМ и довольны.
> И да, то самое чувство, когда читаешь официальные доки по BEM.
Буду очень благодарен, если ткнете носом в непонятные моменты документации.
Если они и правда до сих пор имеют место быть (мы постоянно работаем над улучшением документации), то с вашей помощью сможем улучшить и новичкам станет легче жить.
> 2015: BEM
Например, вот Я.Субботник 2011 — https://events.yandex.ru/lib/talks/217/
А вот пост в клуб БЭМ за 2009: https://ru.bem.info/forum/-46/
Так что все началось сильно раньше Бутстрапа и примерно в тот момент, когда в интернетах стало модно верстать семантично и валидно ;)
> к другим методологиям в глазки не заглядывать, свой HTML руками не трогать, чужой CSS домой не приводить.
Покажите, где вы про это узнали? Я примерно на каждом докладе рассказываю о том, как БЭМ уживается с любыми другими библиотеками (тем же Бутстрапом при желании и делюсь ссылками на решения, где БЭМ объединяют с Реактом, Ангуляром, you-name-it).
И даже HTML, грешным делом, бывает руками пишу, хотя и в самом деле есть способы поэффективнее ;)
> Развидеть двойное подчеркивание
Тут, пожалуй, сложно не согласиться, тем более что ровно про эту возможность подробно написано на bem.info в разде про нейминг: https://ru.bem.info/method/naming-convention/#Альтернативные-схемы-именования
Там же приводится ссылка на инструмент, позволяющий писать вообще как угодно.
> Лаконичные модификаторы
На первый взгляд звучит неплохо, но есть проблема: https://ru.bem.info/faq/#Почему-в-БЭМ-не-рекомендуется-использовать-комбинированные-селекторы-для-создания-css-правил-к-модификатору
Если для вас экономия времени на набор нескольких символов перевешивает возникающие в результате проблемы — дело ваше. БЭМ не запрещает, но «не рекомендует». И плюс-минус ваши же примеры приводятся на bem.info ;)
> Каскадность
Строгие читатели отругали нас за использование слова «каскад» не по спеке. На самом деле это про вложенные селекторы.
Так вот, тут снова БЭМ не запрещает, а говорит, что использование «нежелательно», объясняет почему и тут же приводит примеры, когда это оправдано: https://ru.bem.info/faq/#Почему-нежелательно-использовать-вложенные-селекторы
Впрочем, мы регулярно пытаемся в комментариях к статьям на Хабре рассказать, как все на самом деле (например, вот тут про это же пишет Харисов https://habrahabr.ru/post/151931/#comment_5165248), но люди упорно пишут новые статьи, где говорят то же самое, что и мы, но как будто это они только что придумали, а в Яндексе зачем-то едят кактус :)
Еще немного мифов я попытался развенчать в этом посте: https://ru.bem.info/forum/158/
Настоятельно рекомендую.
PS: в комментариях одновременно говорят о том, что смешивать БЭМ и JS — плохо, но что будущее за Web Components, где, как ни странно, компонент объединяет в себе стили, поведение и шаблоны. То самое чувство, когда https://lurkmore.co/взаимоисключающие%20параграфы
Попробую аргументировать.
> BEM требует соблюдения строгих правил при разработке, не редко вступающих в конфликт со здравым смыслом небольших проектов, не сравнимых по ресурсам с Яндексом
Можно, пожалуйста, ссылки и цитаты с bem.info или какой-либо статьи/выступления от Яндекса, где рекомендации как-то противоречат здравому смыслу или как-то мешают на небольших проектах?
Мы тут некоторое время назад попросили у наших коллег из Поиска поискать в дампе всего интернета сайты, которые используют верстку по БЭМ и чиселка получилась о-о-очень нехилая.
Ну и я лично знаю немало студий и даже фрилансеров-одиночек, которые используют БЭМ и довольны.
> И да, то самое чувство, когда читаешь официальные доки по BEM.
Буду очень благодарен, если ткнете носом в непонятные моменты документации.
Если они и правда до сих пор имеют место быть (мы постоянно работаем над улучшением документации), то с вашей помощью сможем улучшить и новичкам станет легче жить.
> 2015: BEM
Например, вот Я.Субботник 2011 — https://events.yandex.ru/lib/talks/217/
А вот пост в клуб БЭМ за 2009: https://ru.bem.info/forum/-46/
Так что все началось сильно раньше Бутстрапа и примерно в тот момент, когда в интернетах стало модно верстать семантично и валидно ;)
> к другим методологиям в глазки не заглядывать, свой HTML руками не трогать, чужой CSS домой не приводить.
Покажите, где вы про это узнали? Я примерно на каждом докладе рассказываю о том, как БЭМ уживается с любыми другими библиотеками (тем же Бутстрапом при желании и делюсь ссылками на решения, где БЭМ объединяют с Реактом, Ангуляром, you-name-it).
И даже HTML, грешным делом, бывает руками пишу, хотя и в самом деле есть способы поэффективнее ;)
> Развидеть двойное подчеркивание
Тут, пожалуй, сложно не согласиться, тем более что ровно про эту возможность подробно написано на bem.info в разде про нейминг: https://ru.bem.info/method/naming-convention/#Альтернативные-схемы-именования
Там же приводится ссылка на инструмент, позволяющий писать вообще как угодно.
> Лаконичные модификаторы
На первый взгляд звучит неплохо, но есть проблема: https://ru.bem.info/faq/#Почему-в-БЭМ-не-рекомендуется-использовать-комбинированные-селекторы-для-создания-css-правил-к-модификатору
Если для вас экономия времени на набор нескольких символов перевешивает возникающие в результате проблемы — дело ваше. БЭМ не запрещает, но «не рекомендует». И плюс-минус ваши же примеры приводятся на bem.info ;)
> Каскадность
Строгие читатели отругали нас за использование слова «каскад» не по спеке. На самом деле это про вложенные селекторы.
Так вот, тут снова БЭМ не запрещает, а говорит, что использование «нежелательно», объясняет почему и тут же приводит примеры, когда это оправдано: https://ru.bem.info/faq/#Почему-нежелательно-использовать-вложенные-селекторы
Впрочем, мы регулярно пытаемся в комментариях к статьям на Хабре рассказать, как все на самом деле (например, вот тут про это же пишет Харисов https://habrahabr.ru/post/151931/#comment_5165248), но люди упорно пишут новые статьи, где говорят то же самое, что и мы, но как будто это они только что придумали, а в Яндексе зачем-то едят кактус :)
Еще немного мифов я попытался развенчать в этом посте: https://ru.bem.info/forum/158/
Настоятельно рекомендую.
PS: в комментариях одновременно говорят о том, что смешивать БЭМ и JS — плохо, но что будущее за Web Components, где, как ни странно, компонент объединяет в себе стили, поведение и шаблоны. То самое чувство, когда https://lurkmore.co/взаимоисключающие%20параграфы
Со всеми пунктами согласен
Люди спрашивали, применим ли БЭМ для организации JS кода и насколько это эффективно. Это несколько иное. Или я что-то упускаю?
PS: в комментариях одновременно говорят о том, что смешивать БЭМ и JS — плохо, но что будущее за Web Components, где, как ни странно, компонент объединяет в себе стили, поведение и шаблоны. То самое чувство, когда https://lurkmore.co/взаимоисключающие%20параграфы
Люди спрашивали, применим ли БЭМ для организации JS кода и насколько это эффективно. Это несколько иное. Или я что-то упускаю?
Это несколько иное.
Мне вот очень интересно мнение тех кто в теме применим ли БЭМ для организации JS кода. Web Components это круто, но вопрос не об этом. Смешивание js и css, html в один компонент это очень крутая штука. Сейчас, например, почти тоже можно сделать используя webpack и это очень и очень удобно и классно (моё скромное мнение). Но JS код структурированный по БЭМ? Может кто-то так использует? может кто-то имеет пример такого кода? Интересно на сколько это удобно для разработки, поддержки, больших проектов, какие фреймворки и т.д.
Буду очень благодарен если кто-то поделится опытом такого совокупления. Спасибо.
Работал с bemjs — так себе удовольствие.
Сам по себе бэм — число для css. Но в основе у него более фундаментальные идеи, которые можно применять много где:
Сам по себе бэм — число для css. Но в основе у него более фундаментальные идеи, которые можно применять много где:
- разбиение на независимые компоненты (блоки, классы)
- плоская структура компонент (элементы, модификаторы, свойства)
- переопределение реализаций вложенных компонент объемлющей (миксование классов на элементе, переопределение свойств при создании)
Я боюсь, что мы по-разному понимаем термины. Что вы вкладываете в «структурированный по БЭМ»?
Если речь про структурирование на файловой системе, то очевидно, что класть JS можно по признаку того, что это JS в одну папку (либо делать в ней подпапки при желании). А можно, как рекомендует БЭМ-методология, класть JS, описывающий поведение блока, в папку с этим блоком.
Было
styles/
button.css
input.css
js/
button.js
input.js
Так делает, например, Бутстрап.
А по БЭМ станет
button/
button.css
button.js
input/
input.css
input.js
При необходимости переиспользовать эти блоки в новом проекте не придется искать их ошметки в разных папках — все рядом.
Ну и рано или поздно вам понадобится написать юнит-тесты для этих блоков, какую-то документацию, картинки сложить — они тоже естественным образом попадут в эти папки и все останется стройно и логично.
Подробно про все это опять-таки есть на bem.info, со всеми возможными вариантами (пишу на случай, если кто-то опять захочет сказать, что в БЭМ строго и ни шагу в стороны — вариантов предостаточно): https://ru.bem.info/method/filesystem/
А если речь про написание собственно кода, то могу предложить вот такой пост на тему для начала https://ru.bem.info/forum/163/
Дальше можно смотреть в сторону https://github.com/hoho/jquery-bem
А если хочется по-настоящему серьезно подойти к вопросу, то https://ru.bem.info/technology/i-bem/
Если речь про структурирование на файловой системе, то очевидно, что класть JS можно по признаку того, что это JS в одну папку (либо делать в ней подпапки при желании). А можно, как рекомендует БЭМ-методология, класть JS, описывающий поведение блока, в папку с этим блоком.
Было
styles/
button.css
input.css
js/
button.js
input.js
Так делает, например, Бутстрап.
А по БЭМ станет
button/
button.css
button.js
input/
input.css
input.js
При необходимости переиспользовать эти блоки в новом проекте не придется искать их ошметки в разных папках — все рядом.
Ну и рано или поздно вам понадобится написать юнит-тесты для этих блоков, какую-то документацию, картинки сложить — они тоже естественным образом попадут в эти папки и все останется стройно и логично.
Подробно про все это опять-таки есть на bem.info, со всеми возможными вариантами (пишу на случай, если кто-то опять захочет сказать, что в БЭМ строго и ни шагу в стороны — вариантов предостаточно): https://ru.bem.info/method/filesystem/
А если речь про написание собственно кода, то могу предложить вот такой пост на тему для начала https://ru.bem.info/forum/163/
Дальше можно смотреть в сторону https://github.com/hoho/jquery-bem
А если хочется по-настоящему серьезно подойти к вопросу, то https://ru.bem.info/technology/i-bem/
Идея БЭМ в плане организации JS кода в своей основе совпадает с идеей Web Components — разделение интерфейсы на компоненты/блоки так, чтобы все технологии этого компонента (CSS, JS, шаблоны, тесты, etc) были рядом и могли быть с легкостью переиспользованы на других проектах.
Если смотреть на частности, то Web Components достигает этого специальными требованиями к браузерному API, а текущие реализации БЭМ — тем фактом, что JS использует те же селекторы, что и CSS. Плюс, в зависимости от реализации, добавляются еще всякие хелперы про установку/снятие модификаторов, чтобы было удобно выражать состояние компонента (как state в Реакте, только используется с 2008 года), плюшки про подписку на событие изменения модфикаторов и прочие полезности. Но еще раз повторюсь, что это уже вопрос конкретного решения, которое вы будете использовать, методология же говорит лишь про расположение на файловой системе и то, что следует использовать общие селекторы на блоки/элементы, а состояние выражать через модификаторы.
Если смотреть на частности, то Web Components достигает этого специальными требованиями к браузерному API, а текущие реализации БЭМ — тем фактом, что JS использует те же селекторы, что и CSS. Плюс, в зависимости от реализации, добавляются еще всякие хелперы про установку/снятие модификаторов, чтобы было удобно выражать состояние компонента (как state в Реакте, только используется с 2008 года), плюшки про подписку на событие изменения модфикаторов и прочие полезности. Но еще раз повторюсь, что это уже вопрос конкретного решения, которое вы будете использовать, методология же говорит лишь про расположение на файловой системе и то, что следует использовать общие селекторы на блоки/элементы, а состояние выражать через модификаторы.
Непросто отвечать человеку живущему технологией, о которой знаешь со стороны, чтобы и в лужу не пёрнуть, и таки себя показать.
Читайте внимательно: здравому смыслу небольших проектов. Предположим, что за освоение всего БЭМ тулсета мне оному еще зарплату заплатят. А вот навязать это всей команде я точно не смогу. Даже учитывая потенциальную пользу. Послушайте, даже пресловутый React, который решает главную фундаментальную проблему stateful интерфейсов и тот поди внедри среди не Ph.D.
Товарищи из Яндекса настоятельно просили меня не путать БЭМ с вёрсткой по БЭМ. Для этого и такое дерзкое вступление, имеющее целью откреститься перед лицом читателя от Велико-Яндексовского БЭМа, спуститься на землю и начать хреначить.
Тут без обид. Когда знаешь технологию, то и доки по ней читаются как букварь. Сужу по себе и докам по современному докеру. Когда-то доки по докеру состояли страничек из пяти. Потом из 10. Сейчас это портал с кучей примеров. Я там как дома, а для новичка поезд с легким освоением деталей уже ушел. Потому там и появился простой и наглядный туториал. И вообще, хорошие доки часто важнее качества самого продукта.
И это говорит, что не зря я всем твердил с 2007 года: «хотите настоящей работы, друзья, идите на собеседование в Яндекс». Двое из них у вас работают. Но пост в клубе БЭМ за 2009 год не отменяет того факта, что только пару недель назад один американский немец сказал мне «пишем только на БЭМ, без вопросов, RTFM». То есть вот оно всемирное признание. Было ли оно в 2009? А в 2011?
Теперь и я вам помогаю. Но в доках есть строгие ноты по поводу других стилей написания CSS. Уверен, вы легко найдете примеры.
Далее согласен со всем тем, что БЭМ может позволять. Об этом и статья. Вам это очевидно, а, например, англоязычным авторам не очень. И в целом, реакция на строгость БЭМа строго негативная. Вот допилю статью, переведу и пойду показывать своим паникёрам.
P.S. В комментах часто бывает много противоречивых параграфов, затем я и пишу на Хабр, за точками зрения, за ошибками восприятия, за хорошими контр-примерами (дерево ломается на вложенных селекторах, например). Этот опыт помогает лучше объяснять новым людям то, во что веришь и что любишь. Спасибо Яндексу и вам за БЭМ!
рекомендации как-то противоречат здравому смыслу
Читайте внимательно: здравому смыслу небольших проектов. Предположим, что за освоение всего БЭМ тулсета мне оному еще зарплату заплатят. А вот навязать это всей команде я точно не смогу. Даже учитывая потенциальную пользу. Послушайте, даже пресловутый React, который решает главную фундаментальную проблему stateful интерфейсов и тот поди внедри среди не Ph.D.
которые используют верстку по БЭМ
Товарищи из Яндекса настоятельно просили меня не путать БЭМ с вёрсткой по БЭМ. Для этого и такое дерзкое вступление, имеющее целью откреститься перед лицом читателя от Велико-Яндексовского БЭМа, спуститься на землю и начать хреначить.
Буду очень благодарен, если ткнете носом в непонятные моменты документации.
Тут без обид. Когда знаешь технологию, то и доки по ней читаются как букварь. Сужу по себе и докам по современному докеру. Когда-то доки по докеру состояли страничек из пяти. Потом из 10. Сейчас это портал с кучей примеров. Я там как дома, а для новичка поезд с легким освоением деталей уже ушел. Потому там и появился простой и наглядный туториал. И вообще, хорошие доки часто важнее качества самого продукта.
А вот пост в клуб БЭМ за 2009
И это говорит, что не зря я всем твердил с 2007 года: «хотите настоящей работы, друзья, идите на собеседование в Яндекс». Двое из них у вас работают. Но пост в клубе БЭМ за 2009 год не отменяет того факта, что только пару недель назад один американский немец сказал мне «пишем только на БЭМ, без вопросов, RTFM». То есть вот оно всемирное признание. Было ли оно в 2009? А в 2011?
Я примерно на каждом докладе рассказываю о том, как БЭМ уживается с любыми другими библиотеками
Теперь и я вам помогаю. Но в доках есть строгие ноты по поводу других стилей написания CSS. Уверен, вы легко найдете примеры.
Далее согласен со всем тем, что БЭМ может позволять. Об этом и статья. Вам это очевидно, а, например, англоязычным авторам не очень. И в целом, реакция на строгость БЭМа строго негативная. Вот допилю статью, переведу и пойду показывать своим паникёрам.
P.S. В комментах часто бывает много противоречивых параграфов, затем я и пишу на Хабр, за точками зрения, за ошибками восприятия, за хорошими контр-примерами (дерево ломается на вложенных селекторах, например). Этот опыт помогает лучше объяснять новым людям то, во что веришь и что любишь. Спасибо Яндексу и вам за БЭМ!
> Читайте внимательно: здравому смыслу небольших проектов.
Так ведь это… я и для небольших проектов никакого вреда от применения БЭМа не вижу. Он есть? :)
Что до тулсета, то опять же, мы все время твердим, что БЭМ — штука модульная, можно брать по частям.
> не путать БЭМ с вёрсткой по БЭМ
Звучит примерно как не путать чаепитие с чайной церемонией ;)
Предполагается, что есть такие тонкие ценители, которые могут определить ту грань, когда вот только что была верстка по БЭМ и тут опа-па и стал БЭМ?
Я, конечно, догадываюсь, что под этим разделением понимают использование JS фреймворка, оперирующего блоками, декларативного шаблонизатора, опять же работающего с блоками, и сборки, понимающей, как собрать нужные блоки с файловой системы в общий бандл. Но вот, скажем, стали мы собирать БЭМ-проекты на gulp (https://ru.bem.info/forum/782/) или, допустим, Webpack (https://ru.bem.info/forum/774/) — это теперь не БЭМ, а верстка по БЭМ? :)
> для новичка поезд с легким освоением деталей уже ушел
На самом деле у нас движение в противоположную сторону. Мы планомерно упрощаем документацию (да и инструментарий), выпиливаем сложное, добавляем простые примеры и пытаемся учитывать конструктивную критику и повторяющиеся вопросы на форуме.
Сейчас методологический раздел https://ru.bem.info/method/ содержит те самые 5 страниц + историю появления, так что поводов для паники быть не должно. Но мое предложение в силе — если есть конкретные моменты, которые звучат непонятно — буду рад про них узнать и улучшить.
> Но пост в клубе БЭМ за 2009 год не отменяет того факта, что только пару недель назад один американский немец сказал мне «пишем только на БЭМ, без вопросов, RTFM»
Вот, скажем, http://csswizardry.com/2013/01/mindbemding-getting-your-head-round-bem-syntax/ англоязычный пост за январь 2013, где Гарри Робертс ссылается на Николаса Галлахера и делится своими соображениями про БЭМ.
> Но в доках есть строгие ноты по поводу других стилей написания CSS. Уверен, вы легко найдете примеры.
Смотря что вы подразумеваете под «стилем написания CSS». В документации на bem.info приводятся примеры разных вариантов нейминга, разных схем организации файловой структуры, примеры с вложенными селекторами, в общем, все то, про что вы в статье пишите. Однозначно мы, разве что, утверждаем, что селекторы на id не нужны никогда ;)
Так ведь это… я и для небольших проектов никакого вреда от применения БЭМа не вижу. Он есть? :)
Что до тулсета, то опять же, мы все время твердим, что БЭМ — штука модульная, можно брать по частям.
> не путать БЭМ с вёрсткой по БЭМ
Звучит примерно как не путать чаепитие с чайной церемонией ;)
Предполагается, что есть такие тонкие ценители, которые могут определить ту грань, когда вот только что была верстка по БЭМ и тут опа-па и стал БЭМ?
Я, конечно, догадываюсь, что под этим разделением понимают использование JS фреймворка, оперирующего блоками, декларативного шаблонизатора, опять же работающего с блоками, и сборки, понимающей, как собрать нужные блоки с файловой системы в общий бандл. Но вот, скажем, стали мы собирать БЭМ-проекты на gulp (https://ru.bem.info/forum/782/) или, допустим, Webpack (https://ru.bem.info/forum/774/) — это теперь не БЭМ, а верстка по БЭМ? :)
> для новичка поезд с легким освоением деталей уже ушел
На самом деле у нас движение в противоположную сторону. Мы планомерно упрощаем документацию (да и инструментарий), выпиливаем сложное, добавляем простые примеры и пытаемся учитывать конструктивную критику и повторяющиеся вопросы на форуме.
Сейчас методологический раздел https://ru.bem.info/method/ содержит те самые 5 страниц + историю появления, так что поводов для паники быть не должно. Но мое предложение в силе — если есть конкретные моменты, которые звучат непонятно — буду рад про них узнать и улучшить.
> Но пост в клубе БЭМ за 2009 год не отменяет того факта, что только пару недель назад один американский немец сказал мне «пишем только на БЭМ, без вопросов, RTFM»
Вот, скажем, http://csswizardry.com/2013/01/mindbemding-getting-your-head-round-bem-syntax/ англоязычный пост за январь 2013, где Гарри Робертс ссылается на Николаса Галлахера и делится своими соображениями про БЭМ.
> Но в доках есть строгие ноты по поводу других стилей написания CSS. Уверен, вы легко найдете примеры.
Смотря что вы подразумеваете под «стилем написания CSS». В документации на bem.info приводятся примеры разных вариантов нейминга, разных схем организации файловой структуры, примеры с вложенными селекторами, в общем, все то, про что вы в статье пишите. Однозначно мы, разве что, утверждаем, что селекторы на id не нужны никогда ;)
У вас волчанка, сэр :)
Вы настолько привыкли защищать и пропагандировать БЭМ, что делаете это уже по инерции даже в статье, которая служит ровно той же цели. Тон статьи нарочно таков, будто я вовсе не фанат БЭМа, а наоборот, напуган и растерян, что я вижу те же странности, что и неподготовленный читатель, а дальше нежно и плавно вкладываю стержень новых знаний по самые уши. А ушлые БЭМеры, котрые сидит на нем уже пятый год и статью-то не откроют — гляньте какие хилые просмотры по меркам хабра.
И большое спасибо за ваши комменты — следующую статью буду писать только перечитав их все.
Вы настолько привыкли защищать и пропагандировать БЭМ, что делаете это уже по инерции даже в статье, которая служит ровно той же цели. Тон статьи нарочно таков, будто я вовсе не фанат БЭМа, а наоборот, напуган и растерян, что я вижу те же странности, что и неподготовленный читатель, а дальше нежно и плавно вкладываю стержень новых знаний по самые уши. А ушлые БЭМеры, котрые сидит на нем уже пятый год и статью-то не откроют — гляньте какие хилые просмотры по меркам хабра.
И большое спасибо за ваши комменты — следующую статью буду писать только перечитав их все.
Проще говоря, это завуалированный пиар. Надо было тщательней маскировать свой фанатизм. Демонстрация недостатков не имеет отношения к реальной жизни. При этом захваливание носит откровенно религиозный характер. Может тогда и просмотров было бы больше. Следующую статью писать не надо.
Вы бы лучше к своей статье комментарии оставляли. Вам там много хороших вопросов задали.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
BEM с человеческим лицом