Недавно я обнаружил, что многие существующие проекты уже внедрили БЭМ, а некоторые новые проекты требуют от верстальщика обязательной разработки по БЭМ. То есть профессиональные разработчики уже ставятся перед фактом и не имеют выбора. Раз ситуация складывается таким образом, давайте попробуем разложить все по полочкам без рекламы и приукрашивания.
Сопровождаемость и повторное использование кода
Очень важные показатели для любой разработки, известные нам в основном по языкам программирования. Вся суть и прелести БЭМ сводятся именно к этим показателям. Если программисту долго рассказывать про их важность, а потом предложить купить слона, сделка скорее всего состоится. Чтобы понять, улучшает ли БЭМ что-то в этом направлении, надо сначала определиться по отношению к чему будем проверять улучшения. Если сверстать страничку таблицами, как это было во времена IE6, то улучшения от перехода на БЭМ с такой верстки определенно будут. Но найти проекты, которые все еще страдают от табличной верстки, сейчас уже непросто. Посмотрим лучше на актуальные практики, которые идут из спецификации HTML/CSS.
Таких практик всего одна. Это семантическая верстка с разделением структуры данных и оформления. Много лет разработчики самого HTML развивали язык, подразумевая именно эту практику. В концепции разделения структуры данных и оформления заложена одна очень важная идея на тему сопровождаемости. HTML-разметка создается таким образом, чтобы любые последующие изменения можно было вносить, меняя только CSS-код. Эта концепция очень изящно решает все задачи сопровождаемости. В итоге, если БЭМ что-то и улучшает в плане сопровождаемости, то явно не по отношению к семантической верстке.
БЭМ существенно облегчил жизнь разработчиков в Яндекс
Много раз видел что-то вроде этой фразы в качестве убедительного аргумента в пользу БЭМ. Проверить качество жизни разработчиков в Яндекс после перехода на БЭМ будет непросто. Зато можно посмотреть код их проектов. Так вот, это очень похоже на правду. Ведь в верстке некоторых проектов Яндекса все еще используются некоторые практики табличной верстки. К примеру, чтобы расположить логотип и горизонтальное меню сбоку от него, кто-то из разработчиков Яндекса впендюривает одну общую таблицу. Неудивительно, что БЭМ улучшает жизнь в Яндекс, ведь хуже БЭМ только табличная верстка.
Проблема в том, что свою борьбу с таблицами эта компания разнесла по всему рунету под видом некой эффективной методологии. Сейчас даже новые проекты, разработчики которых даже не знают про табличную верстку, вынуждены использовать эту топорную практику борьбы с таблицами. Бороться с табличной версткой нужно, если проблема еще где-то имеет место. Вот только не надо менять одни костыли на другие. Есть хорошие готовые практики, которые давно решают все задачи сопровождаемости. И уж точно не стоит выгонять с Хабра всех, кто высказывается против использования методологии БЭМ. Если бы БЭМ был так прекрасен, как описывают авторы, не было бы срача.
Что в итоге
БЭМ — это жесткий и очень топорный свод правил, который не несет никакой практической пользы, если не брать в расчет проблемы устаревшей табличной верстки. БЭМ уродует код и разрушает все прекрасное, что есть в процессе верстки. Любое соприкосновение с БЭМ напоминает бессмысленное и утомительное развешивание костылей.
Перед тем как внедрять у себя БЭМ, стоит несколько раз подумать, почитать спецификацию HTML/CSS, изучить другие практики. Только после реального понимания практической полезности разных практик и различий между ними можно принимать решение в пользу использования БЭМ, но лучше в этот момент еще раз подумать. В ином случае можно стать жертвой агрессивного маркетинга и соучастником в распространении говнокода.
Комментарии (269)
shweew
03.11.2015 14:09+9Я вот не верстальщик, так и не понял что за БЭМ. Большая Электронная Машина? Обычно не применяемую в массах аббревиатуру расшифровывают в начале статьи.
nomn
03.11.2015 16:34+5Блок, элемент, модификатор
ru.bem.infoshweew
03.11.2015 16:36Да я то уже разобрался, спасибо.
А наминусили то за что? Какого хрена? В чём не прав?
ferasinka
03.11.2015 18:07+3Поговорка есть такая: не погуглив не спрашивай
shweew
03.11.2015 18:13+4А при чём здесь «не погуглив», зачем вообще на хабре что-то публиковать — ведь есть всезнающий гугл...?
Я сделал замечание по поводу оформления статьи и понеслось… Вместо «Спасибо, поправил» заминусили и в карму насрали… Ужас!!!
madkite
03.11.2015 20:44+12Так на Хабре чуть ли половина статей содержит термины/аббревиатуры без последующей расшифровки. Статьи ж пишутся для определённой аудитории. Смотрите на теги — если там «семантическая верстка, табличная верстка, бэм», статья в хабах Веб-разработка, HTML, CSS, а я не верстальщик, то логично что я нифига там не пойму, тем более в заголовке статьи не было фразы «для чайников».
shweew
03.11.2015 22:42-7Всё таки хабр это не закрытый форум для «верстальщиков», здесь более широкая аудитория, 9,7к просмотров на данный момент, и вряд ли все глубоко погружены в тему, по сему наверное надо оформлять статьи с расчётом, что её прочтут не только узкие специалисты.
EvilFox
03.11.2015 23:05+4Вообще, есть же теги
<abbr title="" ></abbr> <acronym title="" ></acronym>
Типа БЭМ. Можно вполне использовать для новичков.
nazarpc
03.11.2015 19:38Вообще-то как минимум стоит посмотреть на хабы, в которых размещена статья. Подавляющее большинство читающих эти хабы если не используют БЭМ везде и не разбираются в тонкостях, то с аббревиатурой у них точно проблем нет.
Jabher
03.11.2015 14:14+18Я повторю фразу, которую говорил уже года два назад, кажется.
Бэм это попытка влететь в светлое будущее (уже настоящее), размахивая костылями. Если приложить достаточно усилий — может и получиться, но без слез на это не взглянешь, я согласен тут.
banzalik
03.11.2015 17:39+2Что именно вы считаете костылями?
Jabher
03.11.2015 21:03+1пойдем от обратного — НЕ костылем является решение, которое оставляет довольно приличный workflow, не вносит избыточности и при этом дает необходимый функционал без существенных оговорок. В случае с БЭМ — всегда есть ощутимые оговорки (если вот сейчас спор зайдет об этом — то это явно троллинг, потому что БЭМ сам по себе оговорка, звучащая как «есть три типа сущностей»), и есть два решения — либо вся экосистема (то есть ломается workflow ко всем хренам собачьим), либо следование гайдам (то есть внесение адовой избыточности). По-моему это явный костыль, полагающийся на разработчика.
banzalik
03.11.2015 21:11+2Какие не костыли есть сейчас для решения проблем, которые пытается решить БЭМ?
Я так понимаю всякие методологии именования вроде SMACSS, BEM, OOCSS, Atomic CSS и прочего не подходят силу того, что заставляют нас писать с оговорками и вносят разные понятия типа, блоки, глобальные модификаторы, базовые стили, лаяут стили имеют свой гайды и прочее прочее…Jabher
03.11.2015 22:34+1Например, css modules — через уже существующие реализации в сборщиках. Это простое, эффективное и качественное решение, позволяющее разработчику почти бесплатно (дополнительный пункт в пайплайне сборки и определенные незначительные изменения в процессе разработки) получить изоляцию модулей стилей.
В моем случае, например, это обеспечивается webpack+css-loader+postcss-loader[postcss-local-by-default], и выглядит как
/*Widget.css*/ .widget {...} .button {...}
//Widget.js import styles from './Widget.css' export const template = ` <div class="${style.widget}"> <div class="${style.button}"/> </div>`
Думаю, это выглядит как довольно неплохой и вполне читаемый шаблон, легко интегрирующийся с почти любым фреймворком (местами, конечно, можно чуть подпилить, но мне в силу используемых библиотек это не нужно). В отличии от БЭМ.
Еще есть другие, альтернативные варианты, предусматривающие более глубокий пересмотр подхода к стилизации, но адепты БЭМ, мне кажется, не подумают даже хотя бы попробовать.banzalik
03.11.2015 23:08+2Подход интересный. Но область его применения очень узкая, как мне кажется.
Например, давайте попробуем этот подход использовать в шаблоне для Wordpress или Magento или Битрикс. И за одно обсудим какие изменения надо будет сделать в процессе разработки, что бы интегрировать такой вариант «верстки».
В каком виде верстальщикм-фрилансерам отдавать верстку вам, что бы вы ее использовали уже для прикручивая к SPA?
Ну и что бы два раза не вставать пример вашего подхода на реальном проекте:
<div class="Snippet__root___2B-wp" data-reactid=".0.7"> <div class="Snippet__output___sVK0p" data-reactid=".0.7.0"> <div class="Snippet__fileName___Tz7_C" data-reactid=".0.7.0.0">Output</div> <div class="Snippet__outputContent___2_vnF" data-reactid=".0.7.0.1"> <div class="ScopedSelectors__root___16yOh" data-reactid=".0.7.0.1.0"><p class="ScopedSelectors__text___1hOhe" data-reactid=".0.7.0.1.0.0">Scoped Selectors</p></div> </div> </div> <div class="Snippet__file___12x_l" data-reactid=".0.7.1:$ScopedSelectors=1js"> <div class="Snippet__fileName___Tz7_C" data-reactid=".0.7.1:$ScopedSelectors=1js.0">ScopedSelectors.js</div><pre class="Snippet__pre___3b3O_" data-reactid=".0.7.1:$ScopedSelectors=1js.1"> </pre> </div> <div class="Snippet__file___12x_l" data-reactid=".0.7.1:$ScopedSelectors=1css"> <div class="Snippet__fileName___Tz7_C" data-reactid=".0.7.1:$ScopedSelectors=1css.0">ScopedSelectors.css</div><pre class="Snippet__pre___3b3O_" data-reactid=".0.7.1:$ScopedSelectors=1css.1"> </pre> </div> </div>Jabher
04.11.2015 01:15+1А вы не путайте теплое с мягким. Это конкретный пример кода на реакте с его data-reactid, если их вырезать, получится вполне симпатично. Но реализация Css Modules может быть использована вообще где угодно.
Более того, если передавать нескомпилированные из оригинального шаблонизатора шаблоны — будет вообще легче жить зачастую.
С поправкой на то, что это именование классов для отладки, а по факту именование классов можно сделать любым, какой-нибудь другой фреймворк будет выдавать в сборке продакшна
<div class="2B-wp"> <div class="sVK0p"> <div class="Tz7_C">Output</div> <div class="2_vnF"> <div class="16yOh"> <p class="1hOhe">Scoped Selectors</p></div>
и так далее, что выглядит весьма многообещающе — места по крайней мере занимается куда меньше.
Более того, при помощи webpack это можно использовать как и где угодно. Например, в jade.
- var styles = require('Component.css') div(class=styles.container) div(class=styles.button) йа кнопко
Если что — выходные стили можно спокойно собрать себе в один файл и не париться даже.banzalik
04.11.2015 02:51+2- var styles = require('Component.css') div(class=styles.container) div(class=styles.button) йа кнопко
а теперь давайте прикрутим к этому jquery?Jabher
05.11.2015 13:26-1В этом году уже считается приличным вводить отдельные классы для JS-логики, отделяя биндинги от стилизационных классов, так что будет что-то вроде styles.button + " js-button". Правда, я не считаю это хорошим подходом и предпочитаю использовать custom elements для этих целей. Благо, они ie9+. В таком случае получаем что-то вроде
- var styles = require('Component.css') component-container(class=styles.container) multi-button(class=styles.button) йа кнопко
Что как по мне — является куда более читаемым, чем нагораживание стилей.
vithar
04.11.2015 09:23С поправкой на то, что это именование классов для отладки, а по факту именование классов можно сделать любым, какой-нибудь другой фреймворк будет выдавать в сборке продакшна
«Какой-нибудь другой фреймворк» и БЭМ-классы может выдавать в таком же минимальном виде, разницы нет.Jabher
05.11.2015 13:22Как я понял, претензия у вопрошающего была в том числе к data-reactid, который вот вообще не связан с реализацией css modules. Поэтому и уточнил про «другой фреймворк».
Я не спорю, что БЭМ может. Только нахрена, если все то же самое сейчас можно делать не ломая привычного подхода к разработке и не нагораживая монстра?
vitkarpov
05.11.2015 18:53но адепты БЭМ, мне кажется, не подумают даже хотя бы попробовать
Я «адепт БЭМ» и, тем не менее написал обзор CSS-модулей :)
БЭМ — появился не на пустом месте, а для решения конкретных задач. Если есть инструменты, которые могут решить эти задачи иначе: надо обязательно на них смотреть (как минимум, чтобы свой собственный взгляд в этом вопросе расширять).
moigagoo
03.11.2015 14:14+40Приведите аргументы и примеры. Чем именно БЭМ вреден? Что лучше?
Я не защищаю БЭМ. Мне просто интересно увидеть конкретные косяки, а не общие утверждения.
amorphius
03.11.2015 19:52+3Плюсую. Хотелось бы еще услышать альтернативы, а то автор советует изучить «другие практики», но к сожалению я о таких не слышал.
summerwind
03.11.2015 22:11-2А это общая черта всех подобных статей против БЭМ — громкие слова, общие утверждения и отсутствие конкретных аргументов или примеров. Ну, либо аргументы, вытекающие из недопонимания методологии.
cbrwizard
03.11.2015 14:17+4Статья какая-то однобокая. Автор пробовал верстать большие проекты без нагромождений !important? Есть HTML семантика, ок. А что делать когда на одной странице огромное количество элементов с одинаковыми тэгами и их нужно по разному стилизовать?
Если не нравится использовать БЭМ — можете не использовать. Но код ваш вряд ли будет таким же хорошим, как без него (если разве что вы не гениальны и не найдете ему замену типа как сейчас обсуждают модульный цсс).
tegArt
03.11.2015 14:56+11А что делать когда на одной странице огромное количество элементов с одинаковыми тэгами и их нужно по разному стилизовать
Я где-то слышал, что есть такая штука — класс, кажется, называется… Говорят, используя их (классы) можно стилизовать огромное количество элементов с одинаковыми тэгами. Или бэм предлагает революционный способ разной стилизации огромного количества элементов в одну строчку?cbrwizard
03.11.2015 15:55+14Если использовать классы без строгих правил их наименования (по сути, это то, чем БЭМ и является) то в большом проекте рано или поздно классы начнут путаться. Вы можете не использовать БЭМ, но для стабильности кода вам придется сделать строгие правила наименования классов. Имхо, создать свое правило наименование классов вместо использования общепринятого БЭМ — это как раз велосипед =] Мне кажется, что люди, не пишущие на БЭМ просто никогда не работали с большой постоянно меняющейся базой css кода, которая изменяется несколькими разработчиками.
nomn
03.11.2015 16:38-5О насколько большом проекте идет речь? Что-то мне подсказывает, что путанье классов будет видно очевидно, сразу и так же просто будет устранено, при этом не создав никакой путаницы. Да и никто не мешает использовать одни из существующих или собственные правила именования классов, которые решат эту проблему. В конце концов БЭМ это не только именование
JiLiZART
03.11.2015 16:55+6Пришел в проект где вообще не использовался БЭМ, теперь страдаю от того что не могу нормально переверстать страницу из-за того что не знаю какой класс в какой должен быть вложен, потому что они именованы как попало.
nomn
03.11.2015 19:46+2Если Вы переверстываете, то зачем Вам смотреть какой класс в каком должен быть вложен?
Если Вы вносите изменения в верстку, разве инспектор не показывает какие правила на блоке сработали?
Т.е. это не проблема отсутствия БЭМ, это, как Вы и сказали «они именованы как попало», хотя меня и заминусили, но я написал, что:
никто не мешает использовать одни из существующих или собственные правила именования классов, которые решат эту проблему.
Ohar
03.11.2015 22:02Ваша проблема не в БЭМ, а в криворукости тех, кто «именовал как попало».
Народная мудростьНеча на зеркало пенять, коль рожа крива.
stychos
03.11.2015 20:45Я перешёл на SCSS и забыл о большинстве проблем с разваливающимся CSS. По мне, это и есть тот самый модульный CSS. Но я не фронтендер, да и про БЭМ до сих пор не слышал, так что не знаю, о чём речь.
token
03.11.2015 14:24+3Согласен с автором во всем, ни разу не встречал ситуации где БЭМ мог бы решить задачу лучше чем правильное использование HTML + CSS.
JiLiZART
03.11.2015 16:56+5А можете описать эти правила? Я был бы рад перейти.
token
03.11.2015 16:58-15Неиссякаемым источником таких правил станет для вас w3c. Хотя можно начать с этого: developer.mozilla.org/en-US/docs/Web/CSS
norlin
03.11.2015 14:41+2Абсолютно не согласен с автором. Очень люблю БЭМ-подход к стилям в первую очередь за избавление от каскадности. Когда вижу css типа такого:
хочется плакать.body > div .content .row div.article .title > p span > a { /* и это далеко не худший пример */ }
С подобным подходом любые изменения в HTML-разметке страницы требуют обязательных изменений CSS-кода. БЭМ же позволяет почти полностью отделить разметку от стилей, сильно облегчая любые изменения, переносы/добавления/удаления элементов и т.д. и т.п.
Ну и повторное использование уже свёрстанных блоков становится намного проще.norlin
03.11.2015 14:47+5p.s. И, да:
БЭМ – это жесткий и очень топорный свод правил
Либо вы говорите про конкретную реализацию БЭМ, либо одно из двух.
В моём понимании, БЭМ => уход от каскадности + независимые блоки. А уж правила написания имён классов каждый может подобрать какие ему удобно, Яндекс лишь предложил один из возможных вариантов (скорее всего, учитывающий большинство возможных ситуаций, т.к. Яндексу необходимо уметь очень много всякого разного).
Andchir
03.11.2015 15:00+35Когда вижу css типа такого… хочется плакать.
<a class="link link__control menu-list__link menu-list__link_type_simple menu-list__link_size_small i-bem"></a>
А от такого не хочется плакать? Это взято с сайта ru.bem.info. Именно так выглядит набор костылей, о котором говорит автор данной статьи. Да, возможно, быстрее написать новый класс и воткнуть его в длинный список, чем учитывать все зависимости. Но лучше всё-таки потратить время и переписать нужный участок, т.к. в конечном итоге получится свалка в HTML и в CSS. В БЭМ есть не плохие идеи, но всё хорошо в меру.norlin
03.11.2015 15:04+6Не хочется, потому что это читаемо и легко меняется. Плакать-то хочется не от длины селектора, а от его некастомизируемости.
Если у вас есть селектор типа
то, чтобы у этой ссылки для какого-нибудь случая поменять цвет, вам придётся либо повторять весь этот селектор, либо использовать !important.body > div .content .row div.article .title > p span > a
В случае же с БЭМ вы можете просто добавить модификатор.Andchir
03.11.2015 15:17+7то, чтобы у этой ссылки для какого-нибудь случая поменять цвет, вам придётся либо повторять весь этот селектор
А в БЭМ не придется? Там класс это и есть повторение селектора со всеми вложенностями. Просто точка и пробел заменены на двойное подчеркивание.
либо использовать !important.
В вашем примере да, потому что его писал дилетант. Опытный верстальщик такого не напишет.norlin
03.11.2015 15:29-1Имя класса в БЭМ ни в коем случае не имеет ничего общего с вложенностью HTML-элементов. Имя класса в БЭМ семантическое и отображает суть элемента. А сложная структура с подчёркиваниями, ключевыми словами типа _type_ и т.д. – лишь частный случай реализации, который позволяет учесть максимальное количество возможных применений.
Опытный верстальщик такого не напишет.
Для продолжения предметной дискуссии, приведите ваш пример для следующего кода:Скрытый текст<body> <div> <div class="content"> <div class="row"> <div class="article"> <div class="title"> <p><span><a href=""></a></span></p> <div class="subtitle"><p></p></div> </div> <div class="body"> <h2></h2> <p> <a href=""></a> </p> </div> </div> </div> </div> </div> </body>tegArt
03.11.2015 15:43+13.title a { ... }
*sarcasm* невероятно круто, да? */sarcasm*
Еще раз хочу спросить, кто же требует всю родословную в селекторе описывать? Почему с вашей точки зрения абсолютно ненужное перечисление селектора начиная от body является аргументом в пользу БЭМ?norlin
03.11.2015 15:46-1Но в .subtitle тоже, теоретически, может появиться ссылка. И ваш класс автоматически её «зацепит».
tegArt
03.11.2015 15:57Он ее не зацепит, он ее опишет, и будут две одинаковые свойственные этому блоку ссылки без лишних описаний и классов. А что сделает в данном случае бэм? Если у вас что-то «может появиться» — это надо учитывать в структуре документа, как ниже в примере у Andchir
.article-author a {...} .article-subtitle a {...}norlin
03.11.2015 16:21Ну тут вы взяли уже классы из комментариев ниже, поэтому проследуем в эту ветку, чтобы не повторяться.
norlin
03.11.2015 15:50p.s.
абсолютно ненужное перечисление селектора начиная от body
К сожалению, на практике приходится постоянно сталкиваться с подобным подходом. Не обязательно от body, это не принципиально. Но длинные каскады встречаются очень часто.
Такой код, обычно, появляется при множественных модификациях вёрстки и стилей, при отсутствии БЭМ-подхода (не путать с BEM-tools).
EvilFox
03.11.2015 20:39+4Хотите возможно сильно огорчу? Мне самому БЭМ не особо нравится, но я понимаю почему его используют в тяжёлых веб-приложениях.
Это не только для удобства командной разработки, но ещё и производительность! У меня шаблон порвался когда я узнал что обозреватели читают селекторы справа налево. То есть в вашем случае если у вас в документе тысячи ссылок, и вы решите использовать «.title a» обозреватель обойдёт все «a» проверяя у них родитель «.title» причём в вашем случае (а у вас «пробел» а не «>») оно ещё выше будет подниматься вместо того чтобы прекратить обход после первого уровня.EvilFox
03.11.2015 20:43Вникать можно начать отсюда.
skaflock
04.11.2015 01:22Кстати, есть продолжение, из которого следует что даже сложные селекторы влияют на скорость загрузки в значительно меньшей степени, чем большой объем неиспользуемых стилей.
EvilFox
04.11.2015 18:28Да, слышал уже про неиспользуемые стили и я заметил что normalize.css очень сильно замедляет (тормоза при прокрутке!) некоторые большие страницы, так что бездумно подключать все эти сбрасыватели стилей не стоит.
Andchir
03.11.2015 15:43+3Имя класса в БЭМ семантическое и отображает суть элемента.
Любое имя класса должно отображать суть элемента.
Ваш пример у опытного верстальщика будет выглядеть примерно так:
<body> <div class="page-wrapper"> <div class="page-content"> <div class="row"> <div class="article"> <div class="article-title"> <div class="article-author"><span><a href="">Name</a></span></div> <div class="article-subtitle"><p></p></div> </div> <div class="article-body"> <h2></h2> <p> <a href=""></a> </p> </div> </div> </div> </div> </div> </body>
Если надо CSS, то напишу позже, пока нет времени, но думаю и так понятно.norlin
03.11.2015 15:48+5Поздравляю, вы написали имена классов, соответствующие БЭМ-методологии!
Блок article, содержащий элементы title, author, subtitle, body.
только для ссылки опустили, т.к. в данном примере ссылка одна и, в принципе, это несущественно. А если ссылок внутри author будет две, разных?Andchir
03.11.2015 16:13+4Поздравляю, вы написали имена классов, соответствующие БЭМ-методологии!
Здесь есть некоторые «идеи БЭМ». Точнее обошлось без жестких правил БЭМ, но с теми же положительными качествами. Поэтому я и писал выше «В БЭМ есть не плохие идеи, но всё хорошо в меру».
А если ссылок внутри author будет две, разных?
Вот тут как раз начнется самое интересное :) По БЭМу мне нужно будет делать примерно так:
<span class="article__link-author-wrapper"><a class="article__link-author_blue" href="">Name</a></span>
А без БЭМа так:
<span><a class="blue" href="">Name</a></span>
В стилях класс .blue можно описать один раз только цвет. А если есть какие-то особенности для блока .article .article-author, то нужно описать эти стили с учетом вложенности.
.blue { color: blue; } .article-author a.blue { font-style: italic; font-weight: bold; }norlin
03.11.2015 16:16+4Нет, я имел в виду, две разных ссылки. Вы сейчас написали «модификатор». А если у нас два разных элемента, которые не должны пересекаться по стилям?
К тому же, ваш класс .blue является глобальным и его могут использовать где-нибудь ещё. А потом вы в него добавите какой-нибудь ещё стиль для ссылки – и его автоматически (и обычно – незаметно) подхватит то самое «где-нибудь ещё». И это будет «незаметно», пока что-нибудь где-нибудь не развалится.Andchir
03.11.2015 17:56+1Я считаю, что глобальные классы вполне можно использовать, но с ограничениями. Например для ссылок разного цвета — не вижу ничего плохого. А для класса .active это, конечно, очень плохо. Как в примере из документации БЭМ:
.item { padding: 4px 10px; color: black; } .active { font-weight: bold; background: #ffc7c7; }
А потом вы в него добавите какой-нибудь ещё стиль для ссылки – и его автоматически (и обычно – незаметно) подхватит то самое «где-нибудь ещё».
В моем примере класс .blue описывает только цвет, пихать в него какие-то дополнительные стили будет лишним. Всё зависит от конкретного случая.
Две ссылки, одна из которых синего цвета:
<div class="article-author"> <span><a class="name" href="">Name</a></span> <span><a class="site blue" href="">Name</a></span> </div>
.blue { color: blue; } /* будем использовать повторно в разных блоках */ .article-author a.name, .article-author a.site { font-weight: bold; } .article-author a.site { font-style: italic; }
Чем это опасно? Замечу, что классы .name и .site я могу использовать в других блоках, но описывать их тоже внутри родителя. Тут есть семантика, а в БЭМ семантика страдает.banzalik
03.11.2015 19:18Замечу, что классы .name и .site я могу использовать в других блоках, но описывать их тоже внутри родителя.
Как вы собираетесь гарантировать, то что классы .name и .site не окажутся внутри других классов .name и .site?
Как будете решать какое из CSS правил для .name и .site сейчас должно примениться, а какое нет?Andchir
03.11.2015 22:40Приведите, пожалуйста, примеры как надо делать. Тогда можно будет сравнить и продолжить разговор.
vithar
03.11.2015 22:58.article-author__name { font-weight: bold; }
.article-author__site { font-style: italic; }Andchir
03.11.2015 23:15Спасибо. Уточнение: в данном случае я привел пример, в котором классы .name и .site находятся на последнем уровне вложенности. Считаю это допустимым.
Как вы собираетесь гарантировать, то что классы .name и .site не окажутся внутри других классов .name и .site?
Точно так же как ваша команда следует каким-то правилам, так и моя команда следует правилу: CSS классы с общими именами (без конкретики) допустимы только на последнем уровне вложенности. И описывать их надо внутри родителя.
Как будете решать какое из CSS правил для .name и .site сейчас должно примениться, а какое нет?
Не совсем понял вопроса. По-моему ответ есть в процитированном вами куске моего комментария.vithar
03.11.2015 23:22+1CSS классы с общими именами (без конкретики) допустимы только на последнем уровне вложенности
Вот есть у вас компонента menu, а ней логично есть item. А рядом есть navigation, а в нм логично тоже есть item.
И есть CSS:
.menu .item {}
.nevigation .item {}
И всё прекрасно работает, пока в какой-то из дней (обычно в пятницу перед сдачей проекта заказчику) меню не понадобится вложить в navigation. И вот тут начинается самое интересное.Andchir
03.11.2015 23:50+1И всё прекрасно работает, пока в какой-то из дней (обычно в пятницу перед сдачей проекта заказчику) меню не понадобится вложить в navigation. И вот тут начинается самое интересное.
В этом наше с вами отличие в подходе к работе. Для вас скорость превыше всего. Для меня не скорость, а качество и лаконичность кода. Вы считаете, что такой код это нормально:
Открыть<ul class="menu"> <li class="menu__item">Item 1</li> <li class="menu__item"> Item 2 <ul class="navigation"> <li class="navigation__item">>Item 1</li> <li class="navigation__item">>Item 2</li> </ul> </li> </ul>vithar
03.11.2015 23:54+1Мне важна не скорость, а пуленепробиваемость кода, чтобы он не ломался при изменениях на странице в неподходящий момент в неподходящем месте.
А как вы переверстаете? Как положено?Andchir
04.11.2015 01:25А как вы переверстаете? Как положено?
Извиняюсь, выше я ошибся. В этом случае всё хорошо, Вы правы.
Возьмем другой пример:
Открыть<ul class="main-menu"> <li class="main-menu-item"> <a>Item 1</a> </li> <li class="main-menu-item"> <a class="active">Item 1</a> </li> <li class="main-menu-item"> Item 2 <ul class="dropdown-menu"> <li class="dropdown-menu-item"> <a>Item 1</a> </li> <li class="dropdown-menu-item"> <a class="active">Item 2</a> </li> </ul> </li> </ul>banzalik
04.11.2015 02:44+1работает
<li class="main-menu-item"><a class="active"></a></li>
не работает
<li class="main-menu-item"><span class="active"></span></li>
<li class="main-menu-item"><span><a class="active"></a></span></li>
vithar
04.11.2015 09:31+2banzalik правильно пишет, малейшее изменение разметки — и стили перестают работать, и надо опять переделывать.
Так работает всегда:
.main-menu__item_active { color: #007FFF; font-weight: bold; } .dropdown-menu__item_active { color: #FF9000; font-style: italic; }Andchir
04.11.2015 14:45малейшее изменение разметки — и стили перестают работать
А что мне мешает немного подправить стили? Вы же меняете HTML, почему стили нельзя? Зато у меня будет всё чистенько, без нагромождений модификаторов.
Raul
04.11.2015 15:01Где гарантия, что класс, которые вы подправите, не используется в каком-нибудь другом месте верстки, и что изменения всё там не поломают?
БЭМ автоматически задает неймспейс. Классы, начинающиеся с названия блока .block__*, точно никогда и ни при каких изменениях не будут влиять ни на что за пределами конкретного компонента. Меняйте верстку внутри блока, меняете стили блока — гарантия 146%, что ничего стороннего не поломается!
vithar
04.11.2015 21:16+1Вёрстку делает один человек, а HTML потом в ходе жизни проекта меняет другой. А тот, кто делал вёрстку, делает уже другой проект и привлекать его к подправлению того, что сломалось — долго.
БЭМ родился исходя именно из этих условий, из промышленного производства сервисов, когда нет ни возможности, ни необходимости подправлять что-то в стилях при изменении разметки. А так же из необходимости делать компоненты, которые потом используются в произвольных местах, иногда самым неожиданным образом.
xobotyi
04.11.2015 11:30Т.е. вам непосредственный дочерний селектор религия запрещает использовать или что?
.menu > .item {} .nevigation > .item {}
А дальше хоть 10 раз одно в другое вложит, оно не посыпется.vithar
04.11.2015 11:35+2Вложите между .menu и .item что-то ещё и оно сразу перестанет работать:
http://habrahabr.ru/post/270075/#comment_8641681xobotyi
04.11.2015 11:43+1А зачем мне туда что-то вкладывать?
Я написал разметку, которая предполагает что внутри.menuлежат.item. А если вдруг, не пойми зачем, мне понадобится влепить что-либо между ними я просто добавлю один уровень в SCSS и будет не
.menu{ & > .item{} }
а
.menu{ & > .some_shitty_block > .item{} }
или если мне надо будет расписать стили того блока, то так:
.menu{ & > .some_shitty_block { & > .item{} } }
Все доводы БЭМщиков это какие-то членовредительские моменты, когда «где-то между» ВДРУГ! возникают левые блоки. У меня они не возникают вдруг, код пишу я и моя команда внутри котороой есть оговоренности, а чаще всего один глобальный блок — один разраб, а значит и разметка и стили пишет один мозг, а если у него элементы появляются «вдруг», то встает вопрос «какого он забыл в команде»
vintage
04.11.2015 12:19Очевидно, вы пишите монолитный код, а не конструктор. Из конструктора легко можно компоновать новые блоки, но цена этому — вы никогда не знаете какие блоки могут потребоваться внутри/снаружи/всередине.
Простейший пример: есть у вас форма, но полей стало как то слишком много и решено было превратить её в визард. С конструктором — достаточно положить внутрь формы блок визарда, раскидать поля по его страницам и всё. С монолитом вам придётся долго и муторно править такие вот каскадные селекторы.
Не, если вы только лендингами занимаетесь, то конструктор вам может и не нужен, но для чего-то более крупного — это просто мастхэв.xobotyi
04.11.2015 12:25Да ну как же, появлияется визард, инпуты имеют все то же отображение что и имели просто слилистически и семантически появляется еще и визард, вокруг инпутов.
т.е. если описывать.form>.wrapper input{}, а именно так я в большинстве случаев и сделаю, то ничто мне не помешает вкорячить вокруг инпутов визард, раскидав так же копипастом нужные инпуты по разным страницам.vintage
04.11.2015 12:37Помешает, ибо скорее всего .wrapper потребуется на каждой странице визарда, а не вокруг визарда целиком.
xobotyi
04.11.2015 12:41ну и будет у визарда описан свой
.wizard>.wrapperкоторый ну никак не будет аффекститься.form>.wrappervintage
04.11.2015 12:55А в случае конструктора можно было бы не заниматься этой копипастой. Я ещё раз подчеркну — многие кейсы вообще не требуют правки стилей, что незаменимо в гибких, настраиваемых пользователем, интерфейсах. И именно к этому стоит стремиться, а не к уменьшению классов в хтмл :-)
xobotyi
04.11.2015 12:56так приведенный мною пример тоже не требует правки стилей, в случае если визард уже сверстан.
Просто переделываешь копипастой хтпл и все, аналогично конструктору.
vintage
04.11.2015 11:41Такие селекторы слишком хрупкие и часто ломаются, когда вложенные элементы переносятся в другие места.
banzalik
04.11.2015 13:25+1xobotyi, у вас очень смелое предположение «мой код никто никогда не будет модифицировать, я не рассчитываю на то, что внутри этого тега появится что-то еще или у этого тега появится обертка, а если что-то и появится я быстренько все перепишу».
Именно от этого я и хочу избавиться, и в этом мне помогает БЭМ.
Реальные бизнес задачи сильно сложнее — css код написаный один раз нельзя менять в дальнейшем, если он уже растекся по всему проекту, скорей всего вы будете навешивать еще классов на участки, где требуется модификация и каскадом пытаться разруливать другие каскады, написанные раннее.
Через 2 года активной разработки проекта, встанет вопрос о том, что этот CSS стало сложно поддерживать, изменения в одном месте — взрывают UI в 5 других местах, станет вопрос, что все надо переписать — многие через это проходили.
banzalik
03.11.2015 17:21+5- каскад — это изменение веса селектора.
- изменение веса селектора — боль.
- чем чаще вы меняете вес селектора, тем сложнее его модифицировать или переиспользовать дальше, в другой части кода вашего проекта.
- вложение одних структур в другие с использованием каскада, и при использовании «абстрактных» именований вида '.item, .title, .link' — отдельный вид боли
Все, что для вас предлагает БЭМ — вынести каскад в имя класса, и не повышать вес селектора в тех ситуациях, когда в этом совершенно нет необходимости.
Проектирование UI, завязанного на вес селектора, я считаю плохой практикой и со мной в этом согласно достаточно много народу.
nazarpc
03.11.2015 20:01Я бы такое не написал, а за это:
<div class="title"> <p><span><a href=""></a></span></p> <div class="subtitle"><p></p></div> </div>
вообще руки выкручивать надо. Везде эти миллионы бесполезных безликих div, p, span которыми разбрасываются направо и налево, а потом говорят о вложенности и всякой ерунде.
Переписать хотя бы так:
<header> <h1><a></a></h1> <p></p> </header>
Здесь хоть смысл какой-то есть, и так весь ваш пример нужно переписать, тогда вам одного класса на корне логического блока будет достаточно для того, чтобы стилизовать его семантические внутренности, либо вообще обернуть в веб-компонент, тогда и класса не нужно, будет пользовательский тэг.
asci
03.11.2015 15:07+1мне от такого не хочется плакать, потому что мне понятно что здесь написано и, зачастую, очень легко в коде найти вхождения по названию класса. А вот наблюдать каскады, от которых толком не отнаследоваться в том же less — вот от этого плакать хочеться.
token
03.11.2015 15:15+2Мне кажется что и тот и тот пример это жесть, вложенность и количество селекторов — не улучшают читабельность кода. Просто нужен здоровый адекватный баланс между первым и вторым. В какие то моменты это будет похоже на div > span > .article > p, в какие то моменты на link link___control menu___list, но для этого нам ведь не нужен БЭМ так ведь? Зачем загонять себя в жесткие рамки правил? Если очевидно что один и тот же подход не может быть одинаково хорошо использован в различных случаях.
jodaka
03.11.2015 15:44+3От такого тоже хочется плакать, и это яркая иллюстрация случая, увидев который, люди, незнакомые с БЭМ, будут креститься и бежать от него, как от огня.
Я раньше работал в Яндексе и занимался фронтэндом, поэтому в курсе про bem tools, bem json, borschik и прочую упячку. И, надо признаться, я сильно недолюбливал БЭМ. Однако, устроившись работать в другую компанию, где никто ничего не навязывал, я со временем пришел к тому, что использую БЭМ подход именно для того, чтобы уйти от каскада. И при грамотном использовании код становится очень простым и удобным в поддержке. При этом я продолжаю считать full bem stack упячкой :)
Для тех, кто, как и автор статьи, считает, что БЭМ — это только костыли, рекомендую посмотреть вот это видео www.youtube.com/watch?v=hTmxbJF2Tts
f0rmat1k
03.11.2015 16:52+4Идея в том, что вам не надо на это смотреть, а смотреть надо на это:
{ block: 'link', elem: 'control' // и т.д. }
и так далее.
Что вам дает смотрение на хтмл? На это браузер должен смотреть. И почему вы называете это костылем? По мне так вполне понятно, что происходит с этим дом-узлом. Вам бы было более понятно такое?<a class="something-special"></a>? Если да, то чем?
Вообще, вы намеренно взяли пример очень сложного узла и представляете это, как костыль. В реальной жизни блоки с таким кол-ом модификаторов и миксов встречаются крайне редко. Пример показывает, что в принципе так делать можно, но это не значит, что так делать нужно. В большинстве случаев все гораздо проще.
Raul
03.11.2015 16:57+7Перестаньте думать, что живые люди пишут это руками!
В BEMJSON этот участок кода выглядит так:
{ block: 'link', mix: [ { block: 'link', elem: 'control' }, { block: 'menu-list', elem: 'link', mods: { type: 'simple', size: 'small' } } ], js: true }
symbix
03.11.2015 18:25Взгляните на RSCSS[1] — возможно, понравится.
Если под БЭМ иметь ввиду только методологию — RSCSS дает примерно же, но без адовых имен классов. Если же говорить о bem-tools — ну… не знаю, мне кажется, эта штука нужна только внутри Яндекса :)
[1] https://github.com/rstacruz/rscss
voischev
03.11.2015 22:21Вам этот комент тоже не помешало бы прочитать :)
http://habrahabr.ru/post/270075/comments/#comment_8640899
token
03.11.2015 15:11+3CSS это прежде всего семантика, вместо того чтобы пытаться описать body > div .content .row div.article .title > p span > a а можно одним единственным именем класса обозначить то чем данный элемент является, к примеру article-title и все. Если есть вероятность того что article-title будет использован дважды, то соотв. образом изменяем article-title на main-article-title и header-article-title (для примера).
norlin
03.11.2015 15:12-3Именно такой подход и является сутью БЭМ, если обобщить.
token
03.11.2015 15:19+3А зачем все это обзывать «БЭМ» и хардкодить в этом своде правил, что мол отныне будет так и только так и если это не так то это не БЭМ, а значит вообще не хорошо?
norlin
03.11.2015 15:31+1Не знаю, кто вам такое сказал. Лично я, когда собеседовал верстальщиков/фронтендеров, спрашивал «знаком ли вам подход БЭМ? Или вёрстка независимыми блоками?» Ну и, если было тестовое задание/примеры кода, то всё было обычно и так понятно.
Абсолютно не нужно 100% следование именно яндексовым правилам конкретной реализации БЭМ, но понимание самой методологии крайне желательно.token
03.11.2015 15:35+2Я у фронтендеров обычно спрашиваю знаком ли им JavaScript (CSS) и уж потом когда я удостоверюсь в том что человек шарит в чистом языке, можно спросить знает ли он jQuery / SASS / Less и все остальное. Ну вот зачем мне человек который знает БЭМ, но вот объяснить что это и зачем это КОНКРЕТНО ЕМУ не может.
norlin
03.11.2015 15:40-2Если взять гипотетическую ситуацию, когда у нас есть человек, понимающий БЭМ (на минуточку – методология вёрстки) и не знакомый при этом с CSS, то намного проще будет его обучить синтаксису CSS, чем «опытного верстальщика» без понимания подобного подхода научить БЭМ-методологии.
Естественно, вопрос про БЭМ-методологию – это «бонусный» вопрос. Важно не знание конкретной реализации, а подход человека и понимание им зачем делается то или иное.token
03.11.2015 15:46+5Иными словами для Вас человек который знает БЭМ но не знает CSS (на минуточку язык на котором это все и работает) — предпочтительней того который знает CSS но не знает БЭМ? Я правильно Вас понял?
norlin
03.11.2015 15:52-1Именно так. Другой вопрос, что найти человека, знакомого с БЭМ, но не знающего CSS, на практике невозможно.
А синтаксис CSS крайне простой, чтобы его незнание само по-себе было проблемой.
tegArt
03.11.2015 15:28+3а если не обобщать и не использовать бэм, то
<a class="link link__control menu-list__link menu-list__link_type_simple menu-list__link_size_small i-bem"></a>
превращается в
<a class="menu-link"></a>
и никто не заставляет описывать в css этот класс с полной «родословной» начиная от bodytoken
03.11.2015 15:32+1Именно! Но случаи ведь бывают разные поэтому никто не мешает вам добавить дополнительный класс, либо изменить название класса таким образом как это используется в БЭМ. Таким образом свобода выражения своих мыслей посредством CSS не обязательно приведет к хаосу в коде (в том случае если этого хаоса не было в голове разработчика изначально, но тут и БЭМ не поможет)
norlin
03.11.2015 15:33+2Кажется, тут многие путают конкретную реализацию БЭМ и, собственно, методологию. Класс menu-link вполне подходит для методологии, при условии, что этот класс используется для одного вида элементов.
block-element, модификатора нет, то есть – это у нас дефолтный вид для ссылки в меню. А «страшный» пример выше показывает максимально возможное количество «фич».token
03.11.2015 15:38+3А чем отличается реализация БЭМ от методологии БЭМ? Это не сарказм, я действительно не очень в курсе того, что существуют еще и альтернативные (может в т. ч. проприетарные) реализации.
norlin
03.11.2015 15:44+2Эм. Методология – это суть того, что хотят сделать. А реализация, это как осуществена данная методология на практике. Поэтому, абсолютно не важно, есть ли другие реализации или нет – теоретически, их никто не мешает создать, при желании. Более того, лично я никогда не использовал BEM-tools в своих проектах и считаю их, в общем случае, крайне неудобными, но, при этом, всегда стараюсь верстать по БЭМ-методологии.
voischev
03.11.2015 20:38+8Знали бы вы все, что за этим кроется и как эта строка изначально выглядела — так бы не говорили ;)
Этот HTML не написан руками разработчика так как вы его видите…
Кусок кода который ты привел сильно широко используется разными технологиям, т.е. это не просто HTML + CSS!
В данном случае тут смесь разных технологий, а именно:
2 разных шаблона разных компонент
js функциональность с разных уровней сборки
css c разных уровней сборки
В этом шаблоне используется такое понятие как mix (что это такое можешь сам почитать), то есть это никак нельзя равнозначно представить так как ты написал.
Если говорим только про HTML + CSS структуру, то давайте уберем все то что тут есть про JS (кстати это в системе сборки автоматом прилетает в код, как и многое другое), что бы хоть как то сравнивать.
Получим следующее:
<a class="link menu-list__link menu-list__link_type_simple menu-list__link_size_small"></a>
Разложим mix на два компонента, получим:
ссылку
<a class="link"></a>
и элемент пункта меню
<div class="menu-list__link menu-list__link_type_simple menu-list__link_size_small"></div>
…
с link все понятно.
Давай разберем menu__link
Явно что это элемент. Значит где то выше по дереву будет сам блок menu!
Посмотрим на модификаторы. Они явно не просто так!
menu-list__link_type_simple — явно что есть более сложные реализации пункта меню. Например на основе псевдо ссылки. (про декларативную шаблонизацию по модификаторам расписывать не буду) А возможно на других блоках например на основе кнопки.
menu-list__link_size_small — явно есть другие размеры меню. кстати это работает для для всех типов этого элемента
В итоге:
Оказывается — много всего можно понять из этого кода! А я никакого отношения к написанному коду не имею. За то понимаю БЭМ. ;)
А теперь попробуй рассказать хоть что-то не очевидное про твой пример
<a class="menu-link"></a>
Спасибо!voischev
03.11.2015 20:45+1Не говорю даже про плюсы в чуть более сложных проектах для верстки, чем «Landing Page» :)
Rosscian
04.11.2015 00:07+2Да, неплохо. Но давайте представим, что есть такой же элемент, а лучше два. каждый отличается от первого menu-link чем-то одним, например, шрифтом и фоном. Ваши действия? Навскидку:
— Дописать другие классы, перебивающие свойства первого. Жуть.
— Задать новый класс и скопировать все стили из первого, изменив нужные свойства. Но мы уже не можем реиспользовать код, мы повторяем себя. А если в будущем понадобится изменить еще что-то? Искать и править все классы? То есть, ухудшается поддержка.
— Если используем препроцессоры, применить экстенды и прочие плюшки. Опять же, проблема — может потребоваться изменить только первый класс, а невольно изменим и остальные.
— Вынести общие свойства в один класс, а разные — в его «подклассы». Удобно? Вполне. Вот только теперь у нас получается блок/элемент и его модификаторы, а по сути — методология БЭМ.
А если нужна возможность смены темы оформления страницы, как на главной того же Яндекса?
И не забываем, что длиннющие и устрашающие классы в HTML пишутся не руками.
Правда, у БЭМа есть и проблемы. Пожалуй, главная — что «чистый» БЭМ сам постоянно нарушает принцип DRY, ибо требует полной независимости блоков.
В общем, как обычно — смотрим на задачи, условия и, исходя из них, подбираем инструменты, одним из которых и является БЭМ. И уж точно не методология или ее разработчики виноваты в том, если ее начинают использовать не по уму.voischev
04.11.2015 09:28+1Да конечно — всё зависит от архитектуры вашего приложения.
Можно позвать на помощь препроцессоры в случаях с небольшими изменениями.
Но в БЭМ в частности в подходе разработки библиотек компонент — есть такое понятие как «темизация» https://github.com/bem/bem-components/tree/v2/design/common.blocks/link/_theme
То есть нужно понять где у вас границы темы и разложить темы в классы модификаторы. Только и всего
Будет следующее:
<a class="link link_theme_one"></a>
<a class="link link_theme_two"></a>
И тогда все будет хорошо. Вы будете точно знать какая ссылка будет использоваться в каком месте и с какой темой. Кстати в таком случае место использования совсем не важно, так как вы завязаны на «класс» ссылки и легко подобные ссылки можно будет поменять сразу во всем приложении (так чаще всего происходит при обновлении дизайна).
Вариант два — подмешать (сделать микс) другой элемент там где это нужно.
Тот же самый присловутый пример с ссылкой и пунктом меню:
<nav class="menu"> <a class="link menu__item"></a> </nav>
и на menu__item уже навесить нужные стили, дополнив базовые стили ссылки.
Это прям крутота! Целых два варианта решения описанной проблемы! :) (на самом деле больше)
По моему опыту (а у меня его прям очень много) БЭМ никогда нигде не жмет, а делает только лучше. Значительно ускоряет разработку. Дает возможность легко передавать работу / обучать других сотрудников. Разрабатывать библиотеки. Максимально реиспользовать уже сделанное
voischev
04.11.2015 09:39Я привел пример решения поставленной задачи причем выглядит круто! А как бы вы решили эту задачу? :)
Rosscian
04.11.2015 11:53А вы точно меня имеете в виду?)
Я-то отвечал на этот комментарий и говорил, что
<a class="menu-link"></a>
совсем не так круто, как это может показаться на первый взгляд. Собственно, и вопрос про темизацию был туда же — как, не используя БЭМ, можно легко решить эту задачу.
banzalik
03.11.2015 20:58+2CSS это прежде всего семантика
CSS — это прежде всего визуальная составляющая
dixoNich
03.11.2015 15:13+10Не увидел ни одного аргумента у автора статьи, не увидел реальных примеров. Обсуждать, по-моему, нечего. Видимо, автору дали поддерживать проект, а он ничего не понял и излил сюда душу :)
gluck59
03.11.2015 15:17+21Заинтересовался БЭМ, начал читать о ней и наткнулся на ролик Школы вебмастеров Яндекса, где кто-то из евангелистов БЭМ подробно разъясняет методологию и в качестве примера тут же создает веб-страницу по ней.
Примерно на десятой минуте он начинает путаться в названиях классов, которые только что создал… это продолжается несколько минут, после чего я не выдержал, закрыл ролик и перестал думать о БЭМ.
Прошу меня простить, я ненастоящий сварщик, некрепкий духом, неверный основам и вообще не самурай.
gubber
03.11.2015 15:23У меня к БЭМу на счёт CSS вопросов нет. Но вот что касается общей применимости методологии — вот тут у меня вопросы.
Если мы строим полностью динамическое web-приложение, так же всё более менее понятно.
Но когда половина контента генерируется сервером, а другую часть хочется реализовать с использованием того де БЭМ. Вот тут возникают вопросы:
- Надо ли «статический»(с точки зрения приложения) контент оборачивать в компоненты
- Если надо, то как это лучше сделать?
- Если же не надо, то приходится «вклеивать» БЭМовские вклеивать в DOM, что убивает всю прелесть использования БЭМ. Т.к. получаем частично спагетти код, для встраивания компонентов в DOM, для навешивания слушателей на «статические» компоненты.
Пока я не смог разрешить для себя эти вопросы. И использую только CSS-ную часть от БЭМ. Оно действительно упрощает повторное использование и кастомизацию интерфейса.
dom1n1k
03.11.2015 15:41+6Изучить другие методологии? Это какие же? Нет их.
Ну точнее, они есть — но сколько я ни пытался понять их преимущества, мне это не удалось.
Единственное более-менее удобоваримое исключение — OOCSS, да и то не фонтан. Что-то с серединки на половинку.
БЭМ поначалу выглядит непривычно, и я тоже подходил к нему со скепсисом. Но потом понял — сейчас это практически единственный вариант, который одновременно понятен и эффективен. Он слегка громоздок, но это разумная плата за понятность, однозначность и стандартность.
Конечно, даже его можно довести до абсурда, навешивая на каждый элемент по 5 классов и 10 модификаторов. Но при разумном применении всё более чем окей.
Единственное, мне больше нравится «западная» модификация БЭМа, где модификаторы имеют сокращенный синтаксис.cbrwizard
03.11.2015 15:49Люто, бешено плюсую. Критикуя что-то будьте объективны и предлагайте варианты.
Tab10id
03.11.2015 18:16+2smacss
dom1n1k
03.11.2015 18:20Оно довольно похоже на MCSS.
Пока читаешь доку — ну вроде да, есть своя логика.
Как переходишь к практике — ваще непонятно что, как, когда и зачем нужно делать.
voischev
03.11.2015 22:28+2Недавно в ленте твиттера было сообщение о том что автор OOCSS или SMACSS писал что бы люди использовали БЭМ вместо того что он придумал
dom1n1k
03.11.2015 23:53Про MCSS было такое сообщение, причем самим автором тут на хабре. Насчет вышеперечисленных не знаю.
Delka
04.11.2015 13:34+2Вот оно:
@HugoGiraudel Most common misspelling is “SMACCS”. I should just rename it to BEM.— Snook (@snookca) 5 июня 2015
Tab10id
05.11.2015 13:16Крайне неожиданно и любопытно. Идеи smacss и БЭМ конечно пересекаются основными критериями, но я бы не стал однозначно утверждать что одна методология во всем лучше другой.
kmmbvnr
03.11.2015 15:47+3Пока БЕМ был действительно внутрирунетовской штучкой, я тоже к нему скептически относился.
Но недавно гугл выпустил css фреймворк основанный на БЕМ — www.getmdl.io
token
03.11.2015 15:51Приведу пример. Есть у меня библиотека компонентов состоящая из двух элементов: superInput и superSelect. Для того чтобы иметь возможность встраивать эти компоненты в существующие страницы без возможности конфликтов я присвою их корневым элементам классы: myLib-superInput и myLib-superSelect, т. е. HTML будет выглядеть так:
<div class="myLib-superInput"> тут что то еще </div>
Для стилизации контента самого элемента, а также его детей я буду использовать CSS:
.myLib-superInput { ... } .myLib-superInput input { ... }
Теперь вопрос: это уже БЭМ или еще не БЭМ?norlin
03.11.2015 15:58.myLib-superInput input
вот это не соответствует БЭМ, на мой взгляд.
Т.к. если у нас есть блок .myLib-superInput, то его элемент input должен иметь свой уникальный (среди других классов) идентификатор, по которому, при необходимости, можно было бы наследоваться.token
03.11.2015 16:04+4Вот это просто ломает мне мозг, зачем я должен думать в CSS'е о том, что откуда должно наследоваться. Еще и идентификаторы какие то, у меня и так все прекрасно работает и проблем никогда ни у кого не вызывало (кроме адептов БЭМ).
К сожалению для того чтобы привести более внятные аргументы мне нужно будет изучить БЭМ, но ни времени ни желания изучать эту «прорывную» технологию у меня нет, а потому я пожалуй воздержусь от дальнейшей критики.norlin
03.11.2015 16:08-3На страничке из двух контролов вам про наследование элементов совсем не надо думать. А на крупном портале, где есть с десяток модификаций одной кнопочки или те же контролы в 5 разных вариациях – вот там придётся думать.
Более того, если взять идеальную ситуацию «у нас есть 100% ТЗ, где полностью описаны все элементы и их поведение и это ТЗ меняться не будет никогда» – тогда БЭМ тоже будет излишен, можно и так заверстать. Но в реальных условиях любой проект развивается, меняется, перевёрстывается, передизайнивается – и вот тогда вся эта штука очень пригождается, чтобы держать вёрстку в адекватном состоянии без запредельных усилий.token
03.11.2015 16:12Вы не поверите, но два этих контрола — это лишь пример реально существующей (и успешно работающей) ситуации, которую Вы описали в своем комментарии. Полностью все так и есть.
ionicman
03.11.2015 15:53+5Господа, чего Вы ссоритесь?
Просто же все.
БЭМ как и CSS — это инструменты. Как и любой инструмент, для каких-то задач хорошо подходит один, для каких-то — другой.
Самый универсальный и беспроблемный инструмент — это CSS.
В большинстве случаев его хватает с головой и код получается вполне нормальный, читаемый и чистый. Естественно, применять его надо с головой — а иначе все что угодно, даже самое идеальное, можно превратить в трэш. Есть случаи, где реально наследование мешает. Однако, большинство этих случаев — рукожопость верстальщика и (или) архитектора.
Однако, если Вы собираете больше двух однотипных и выдержанных в одном стиле сайтов из стандартных повторяющихся «кусков», делающихся разными группами девелопперов — то, возможно, Вам будет интересен БЭМ. Он позволяет быстро собирать и обновлять такую штуку.
Части эти могут разрабатываться независимо и внедряться также. Это удобно, особенно для веб-приложений. Отсутствие наследования позволяет не бояться, что при изменении силя какого-либо блока где-то что-то уедет за его пределами.
БЭМ был очень распиарен Яндексом, они очень любят пиарить свои поделки — им надо — они же на бирже играются :)
Популярность и универсальность БЭМа, а также профит от него дико преувеличен.
Лично я не понимал БЭМ сначала, и даже спрашивал на хабре в чем фишка.
Затем был опыт использования его в несколькоих сторонних проектах. В одном оно было прибито гвоздями из цикла — гики от него в восторге, Яндекс не может ошибаться!
А вот в паре других оно реально работало.
По моему опыту — для большинства простых сайтов БЭМ не нужен вовсе. Он начинает давать профит при большом парке однотипных сайтов, или в случае разработки масштабного веб-приложения, компоненты которого как раз и пишутся с использованием БЭМ, а, затем, как из конструктора, из этих блоков строится приложение.
В любом случае, увы и ах — БЭМ — это костыль. Подвижки к этой теме делает нативный шэдоудом, и если он взлетит — то тогда все это поделие не нужно будет.
Ну и еще я не люблю, когда что-то называют серебряной пулей. Нет такого, все зависит от задач.
Как то так.
Как в том анекдоте:
-Свет мой зеркальце скажи, да всю правду доложи, яль на свете всех милее, всех прекрасней и белее?
-Ты красива, спору нет…
-И все?!
-И все...norlin
03.11.2015 16:00BEM-tools – инструмент и, возможно, «костыль», неуниверсальный и всё такое.
БЭМ сам по-себе – методология вёрстки, предлагающая, в первую очередь, определённые правила для селекторов. И эта методология универсальная (в том плане, что с её помощью можно сверстать проект любой сложности и его при этом будет легче поддерживать, чем если писать на CSS, не придерживаясь методологии).
Комментарии к данному посту показывают, что многие не видят разницы между этими двумя понятиями.ionicman
03.11.2015 16:04+7Костыль она по тому например, что использует CSS на очень странный манер.
Фишка CSS — это каскады (он даже расшифровывается как Cascading Style Sheets), а в БЭМ предлагают от него отказаться.
Есть и еще почему.
Ну и про костыль — это не только мое мнение. Вы-же ветку-то читали? :)
И, сверстанное на БЭМ, ничем не проще или лучше поддерживаемо, чем сверстанное с головой на CSS. Это — заблуждение.
Примерно — одинаково.norlin
03.11.2015 16:09БЭМ предлагают от него отказаться.
Что ж поделать, если для сложной вёрстки каскады создают больше проблем, чем пользы.ionicman
03.11.2015 16:12+2Не создают они проблем при сложной верстке.
Совсем. Для этого нужно лишь одно — согласованная дока внутри проекта об именовании классов.
И все.
Если ее нет — то Вас и БЭМ не спасет.
Если она есть и разработчики ее придерживаются — никаких проблем каскады не доставляют.
Это как согласованный code-style. Тоже самое. Он должен быть в проекте.
И все. Максимум, что может покрэшится от наследования — это что-то в пределах одного куска, пилящегося одной командой. Это быстро обнаруживается и лечится. Наследование тут не причем — причем прожект менеджер который орет, что нужно «вчера» и неофиты. Таким же образом может покрэшится и что-то в питоне. Давайте тогда ограничим набор операторов в питоне? )))norlin
03.11.2015 16:14-2Ещё раз – самый наглядный пример проблемы каскадов – это переопределение какого-нибудь свойства у «глубого закопанного» элемента. Приходится либо повторять весь селектор (и следить теперь за ним в двух местах при изменениях), либо использовать !important.
ionicman
03.11.2015 16:17+5Вот честно — ни разу такой проблемы не возникало.
Ни у меня, ни у коллег.
Но прострелить себе ногу вообще чем угодно можно. И никакая методолгия не спасет :)norlin
03.11.2015 16:18Могу предположить, что вы не участвовали в крупных живых проектах с legacy-кодом.
ionicman
03.11.2015 16:22+1Предположить Вы можете, однако с реальностью это пересекается плохо :)
Аукцион и портал запущенный 7 лет назад. Как думаете, как там с легаси?
Но тут дело в том, что если люди грамотные — то прежде, чем лезть хотелки делать, общее представление о проекте и как он сделан надо иметь.
Если Вы это разобрали (или были доки и концепция — что еще круче) — то тогда у Вас такой проблемы не будет.
Если не разобрались, или концепции вообще не было — опять-же БЭМ не спасет, ибо вверху есть body input {}
:D Образно.
Ну а если Вы все причесали и переделали на БЭМ это == все причесали и переделали на CSS.norlin
03.11.2015 16:25если люди грамотные
Ну естественно! Если люди грамотные, то ни ТЗ, ни таск-трекеры, вообще никакие формальности не нужны будут – грамотные люди и так сделают всё хорошо.
В общем, чтобы поставить точку в бессмысленной ветке дискуссии, предлагаю считать БЭМ-методологию всего лишь style guide соглашением для вёрстки.ionicman
03.11.2015 16:29+1Дак вроде не это обсуждали, а по большей степени то, что БЭМ пихают в рунете вовсю как серебряную пулю, коей она абсолютно не является. Что мол перейдете на БЭМ — и все проблемы исчезнут, сайты станет поддерживать легче и вообще все будет классно. Так вот, как я выше уже написал — это — заблуждение.
Ну и там не только стайл-гайд, увы.
Я же не говорил, что БЭМ — это плохо. Но для большинства задач в веб — БЭМ излишне тяжелая и не имеет смысла.token
03.11.2015 16:31+1И это ведь мы затронули лишь CSS — часть БЭМ. Там вроде бы есть еще и целая костыльная мастерская для JavaScript…
ionicman
03.11.2015 16:32Там много что есть, что делает ее «костыльной».
Однако, если ее применять для тех задач, для которых она была сделана — то это окупается.
Другое дело что многие с пеной у рта пытаются использовать ее везде.
norlin
03.11.2015 16:32+1Не понимаю, почему БЭМ может быть «излишня», т.к. никаких оверхедов она за собой не несёт. Естественно, для странички с одной формочкой оно излишне, а если же у вас хотя бы пара страничек вёрстки – то вполне норм, не говоря уже о бОльших проектах.
token
03.11.2015 16:35А вы уверены в том что она не несет никаких оверхэдов? Есть ли статистика проседания перформанса браузера в зависимости от общего количества классов / селекторов (это ведь все нужно где то держать в памяти) против того же самого но на каскадах?
norlin
03.11.2015 16:39+2Не знаю насчёт современных браузеров, но на момент создания БЭМ я ещё работал в Яндексе и там была презентация на эту тему.
Уход от каскада, кстати, был обоснован, в том числе, выигрышем в производительности рендеринга.
Если на пальцах, то на тот момент браузерные движки рендерили селекторы справа налево.
То есть, чтобы исполнить селектор вида.title div a
браузер сначала выбирал все элементы «a», потом среди них искал те, у которых родитель «div», и, наконец, те, в которых у «div» родитель .title
При использовании же уникальных классов, выборка сразу же была по имени класса. Цифр не вспомню, было давно.
Количество же классов на производительность не влияло (как минимум, на порядках тысяч разных имён классов).token
03.11.2015 16:44браузер сначала выбирал все элементы «a», потом среди них искал те, у которых родитель «div», и, наконец, те, в которых у «div» родитель .title
Странная логика выборки селекторов, больше похоже на описание работы Internet Explorer…
Количество же классов на производительность не влияло (как минимум, на порядках тысяч разных имён классов).
Есть ведь еще и памятьnorlin
03.11.2015 16:47Странная логика выборки селекторов
ну как я и сказал, это относилось к тем временам (если не ошибаюсь, 2008-9гг). Но далеко не только к ИЕ, насколько я помню, все браузеры так работали. Не знаю насчёт современных движков, так глубоко не копал.vintage
04.11.2015 10:04Никто никогда так не работал ибо это глупо. Браузер не ищет элементы к которым можно применить конкретный стиль. Браузер ищет стили которые можно применить к конкретному элементу. Отсюда и фильтрация стилей справа налево.
ionicman
03.11.2015 16:41В плане перфоманса БЭМ быстрее будет — браузер не использует просчет наследования.
Другое дело, что выигрыш будет таков, что прочувствовать его на себе может только что-то уровня Яндекса. :)
ionicman
03.11.2015 16:35+1Оверхэдов она несет массу.
Во-первых, это еще одна сущность в проекте, и народ должен уметь ее (как верстльщики так и девелопы)
Во-вторых у Вас завязаны руки с каскадами — а они очень и очень удобны в некоторых случаях.
В-третьих, любое 3-rd пати (контролы или что-то еще) придется переписывать, чтобы удовлетворяло.
А иначе у Вас будет солянка, а не БЭМ.
Это первое, что вспомнил из проекта. Это не оверхэд?norlin
03.11.2015 16:44+1Если речь всё ещё идёт о методологии, то:
Во-первых: не более, чем любой style guide.
Во-вторых: Они могут быть удобны для быстрого хака, но в стратегическом плане они менее удобны. Более того, БЭМ не требует ПОЛНОСТЬЮ отказываться от каскадов, в некоторых случаях они оправданы.
В-третьих, вовсе не обязательно. Любые контролы идут со своими стилями и при использовании на проекте БЭМ-нейминга как раз уходит риск пересечения классов (при использовании частоупотребимых типа .article, .content и т.д.), т.к. неизвестно, что там в сторонних стилях могли накодить.
При написании же своих стилей к, например, js-контролу, нет никакой сложности сразу написать их в стиле БЭМ.ionicman
03.11.2015 16:48+1Тем не менее это все описанное — оверхэды :)
Ну и если Вы не будете все в проекте точить под БЭМ, зачем он Вам? Он работает нормально только когда на него полностью все завязано.
Например, используя 3rd пати стиль или каскад где-то as is Вы рискуете нарваться на тот-же самый глюк, ради отсутствия которого Вы и начали использовать БЭМ.
Смысл тогда?
Это технология тотальна для всего сайта — либо Вы используете только ее — и тогда получаете все ее плюсы, а иначе Вы просто делаете что-то странное.norlin
03.11.2015 16:51Например, используя 3rd пати стиль или каскад где-то as is Вы рискуете получить тотже самый глюк, ради отсутствия которого Вы и начали использовать БЭМ
Не рискую, потому что оно никак не будет пересекаться с моими именами классов (т.к. они уникальные и совпадение крайне маловероятно, в отличие от использования общеупотребимых слов).
Это технология тотальна для всего сайта — либо Вы используете только ее — и тогда получаете все ее плюсы, либо нет.
Это касается BEM-tools, но никак не методологии.
Ещё раз – по-сути, эта методология не более чем style-guide. И любые оверхеды – не более, чем у любого другого style-guide.ionicman
03.11.2015 16:56+1Не рискую, потому что оно никак не будет пересекаться с моими именами классов
И этот же аргумент можно использовать и для чистого CSS, нет? ))))
На самом деле откуда Вы в этом так уверены? Запросто можете словить. Ибо кто знает что там в 3-party было. menu-item там стилизовался неудачно, а у вас он тоже есть.
Вобщем, давайте так — я свои доводы привел.
Вы свои — на этом и разойдемся — дальше просто полемика.
Вы евангелист БЭМа, я же — нет. Я вижу в нем только инструмент, который в некоторых случаях неплох. И когда он неплох — можно его юзать. У меня потребительское отношение к этому.
token
03.11.2015 16:55Вообще было бы круто если бы существовала тулза на вход которой давали бы CSS / HTML / JS а на выходе она упрощала бы CSS до минимально возможного скелета (также с попутным переименованием длинных классов в короткие), подобно тому как это делает Google Closure Compiler для JavaScript'а. Я в свое время пытался такое сделать, но уперся в невозможность определения того что именно является именем класса / частью селектора и т. д., а маркировать такие вещи каким то особым образом — уничтожало весь шарм. При наличии данного инструмента, было бы все равно был ли БЭМ или нет, на выходе все равно получалось бы то что работало бы максимально быстро и занимало бы как можно меньше.
vithar
03.11.2015 21:53+2Такая утилита для преобразования css была написана в Яндексе в 2010:
https://github.com/gfranco/jeanny/
Мы использовали её на странице результатов поиска:
https://blog.yandex.ru/post/23106/
Потом отказались, поскольку в JS классы иногда зашиваются в строки и склеиваются, все случаи обработать невозможно и вёрстка иногда ломается после минимизации.
Но если у вас статика без CSS-классов в JS — можно использовать, минификация будет работать.token
04.11.2015 01:07Ну у меня чуть дальше продвинулось. Я просто зашивал мап (было — стало) и пропускал jQuery селекторы через него при выполнении
norlin
03.11.2015 16:13+2чем сверстанное с головой на CSS
Как показали комментаторы выше, «свёрстанное с головой», по-сути, подходит под БЭМ-методологию. Просто те, кто «верстает с головой» без БЭМ, делают это неосознанно, за счёт чего могут быть накладки.ionicman
03.11.2015 16:18«Подходит» и «является» немого разные вещи, не находите?
norlin
03.11.2015 16:19Это уже демагогия. Важна суть, а не название.
ionicman
03.11.2015 16:25Просто под «похоже» можно что угодно здесь подвести, ибо средства для достижения всего этого ограничены — по-сути это только CSS + HTML.
Однако похожесть не говорит о том, что Вы пишите на БЭМе — это я имел ввиду.
БЭМ — все таки достаточно точно описанная методолгия. И, либо Вы ей точно следуете и получаете БЭМ, либо у Вас не БЭМ :)norlin
03.11.2015 16:27И тут мы уходим в рекурсию…
ionicman
03.11.2015 16:30Не уходим, я не про тулзы говорю а про методологию, ага? :)
norlin
03.11.2015 16:34+1Это было к
либо Вы ей точно следуете и получаете БЭМ, либо у Вас не БЭМ
Если речь про методологию – то замена нейминга на какой-то другой аналогичный не говорит о том, что вы перестали использовать БЭМ. Но, при этом, оно лишь «похоже» на оригинальное описание методологии.ionicman
03.11.2015 16:38Там обычно не аналогичный, а просто иногда используют часть похожего нейминга. Ну и БЭМ ведь не совсем только нейминг, кроме того он строгий, согласно методолгии.
А то так много что БЭМом можно обозвать будет :)norlin
03.11.2015 16:46… и тут я уже в который раз скажу, что важна суть, а не наименование. Пусть обзывают как хотят.
token
03.11.2015 16:22+3Видимо вся дискуссия упрется в то, что каждый заморачивается так как ему удобней. Просто одним удобней отстрелить себе руку для того чтобы потом когда нибудь в будущем эта рука не воспользовалась пистолетом лежащем в ящике, а другие обходятся и без столь радикальных мер.
gubber
03.11.2015 17:15-2Фишка CSS — это каскады (он даже расшифровывается как Cascading Style Sheets), а в БЭМ предлагают от него отказаться.
В блоге Яндекса была запись, в которой они объясняли причину отказа от каскадности: в нагруженных каскадными стилями страницах, применение стилей тормозилось именно из-за необходимости рассчитывать применимость стиля.
f0rmat1k
03.11.2015 16:40+8Довольно странная статья: с одной стороны кажется, будто у автора остро бомбит об БЭМ, с другой стороны судя по аргументации, автор не понимает, что такое БЭМ, и считает, что это средство, чтоб не верстать таблицами.
Я понимаю, что Яндекс в последнее время можно журить, но это не значит, что на айти любой треш-пост, где ругают Яндекс, надо плюсовать. Печально.
jakobz
03.11.2015 17:35+2Ага. Тоже вот зашел посмотреть как автора пожурят за то что его бомбит, и он вообще не очень понимает о чем и про что говорит. Ан нет.
shoomyst
03.11.2015 16:58+9Яндекс верстает таблицами, поэтому БЭМ это ужасно. Я все верно понял из этой статьи? :)
indrauolles
03.11.2015 17:52Не являюсь фанатом ни full bem stack, ни яндексовской реализации БЭМа. Но уже не хватает «хабразаряда», чтобы плюсовать все взвешенные ответы norlin. Технологию БЭМ-стека/методологию БЭМ можно использовать частично — необязательно писать на bemjson, необязательно использовать сборщик enb, можно позаимствовать какие-то идеи для CSS, можно использовать только js-фреймворк i-bem.js.
(Имею опыт работы с тремя проектами с большим количеством кода, как «красивого-вылизанного», так и не очень хорошего).
AmdY
03.11.2015 18:54+6У меня от БЭМ сильное чувство, что ребята как-то недопоняли CSS, не осилели LESS и в итоге налепили велосипедов. Но вот удивляет, что тепреь набравшись опыта и знаний они вместо того чтобы забросить велосипед, они активно его продвигают сравнивая с говновёрсткой с глобальными классами и оправдывая некой скоростью, которая даже во времена ie 5.5 уже была неактуальна.
banzalik
03.11.2015 19:06-2Почти все современные подходы в верстке — модульность.
БЭМ — тоже про модульность.
У вас претензия только к названиям классов или есть что-то по существу?
Приведите примеры хорошей верстки с подходами в корне отличающимися от тех, что использует БЭМ.AmdY
03.11.2015 19:16+2Почему современные? CSS сто лет назад придумали умные люди и сделали его с большим запасом прочности. Создание модулей-компонентов уже заложено в CSS, а БЭМ это тоже но со своими костылями и ограничениями, этакий антивирус бабушкина.
И меня удивляет их агрессивное навязывание этой технологии, которая очень неудобная, требует своего инструментария и противоречит тому, чему ещё недавно учил яндекс — семантической разметке.banzalik
03.11.2015 19:27И именно из-за своего несовершенства CSS развивается по сей день.
Когда проэктировался CSS не предполагалось такие сложные UI. БЭМ — это попытка жить упорядоченно в мире сложных UI интерфейсов.
CSS до сих пор никак не решает проблему сложных UI, это проблему пытаются решить с помощью web components и попытку сложно назвать очень удачной.AmdY
03.11.2015 19:35+1Добавляются новые эффекты и новые типы селектов, идея остаётся той же как и обратная совместимость. Именно гибкость селектов направлена на богатый UI, а БЭМ от него отказывается в сторону точных классов на конкретный элемент, это его очередной минус. Яндекс всё же не контора про красивые и динамичные UI.
jakobz
03.11.2015 20:38+1CSS придумали чтобы буковки раскрашивать. В CSS нет ни одного признака что его создавали под масштабные задачи: нет никакой модульности, нет возможности хоть какой-то абстракции, ничего там нет про запас прочности.
Зато есть каскадинг, который опять же удобен на маленьких задачах, а на больших — ведет к аду.
Именно из-за ущербности CSS у нас есть LESS, БЭМ, и подобное.AmdY
03.11.2015 21:08Да, пожалуй я погорячился, без предпроцессоров css совсем плох на больших задачах. Но Бэм так же задачу не решает, он тащит за собой аналогичый инструментарий.
jakobz
03.11.2015 21:25+1Ну как. БЭМ — это прежде всего модули для CSS. Блок — модуль, модификаторы — API модуля, элементы — внутренняя реализация.
Плюс БЭМ-а — легковесность. Фактически это просто naming convention, который можно применить к голому CSS. Хотя из-за длины имен классов — делать БЭМ поверх голого CSS пожалуй не стоит.
Этот naming convention можно (и нужно) дополнить тулзами. Можно тулзами от яндекса, хотя про что и зачем там эти их BEM JSON — я вообще не понимаю. Это какая-то их внутренняя кухня.
Но можно взять тот же LESS (все равно нужен) и писать там вместо block__element, &__element. А для какого-нибудь ангуляра — прикрутить хелпер типа такого: https://github.com/tenphi/angular-bem
И вот уже имеется какая-никакая модульность, и все более-менее удобно и понятно.
Да, есть более тяжеловесные и радикальные решения — например выкинуть CSS совсем, и писать стили на JS: http://blog.vjeux.com/2014/javascript/react-css-in-js-nationjs.html (кстати в докладе разбираются недостатки CSS на больших проектах в фейсбуке)
Но более тяжеловесные и радикальные решения — это дорого, и не всем надо. И вот нишу между «5 страниц изящного хипстерского семантического CSS» и «у нас 50 приложений с общим CSS на 20 мегабайт» — как раз удачно заполняет BEM и CSS-препроцессоры.AmdY
04.11.2015 00:13+2.block .element ничем не уступает block__element, а как вложенность растёт так и БЭМ преврашается в ужос. Чтобы прописывать это в шаблоны нужен ещё один предпроцессор или плагин как вы приводили для ангуляра. Чтобы эти классы запомнить и раставить нужны жирные мануалы. Плюс зачем-то выпячиваю наружу вроде детали оформления btn__color--grey. Никто не мешает без БЭМ договориться о правилах именования. Нормальный верстальщик затем практически любое оформление сделает не лазя в шаблоны, а только используя css+less.
БЭМ же не единственная методология, вроде мода с появлением препроцессоров на них прошла, а здесь яндекс выкатил свою погремушку с тяжёлым наслением от любви к xslt шаблонам. И школота потянулась на громкое имя, лепят свой БЭМ, а в реальности ляпают инлайн стили когда английские слова заканчиваются.jakobz
04.11.2015 00:37+1.block .element уступает .block__element тем, что имя «element» становится занято. Т.е. имея ".header .icon" ты не можешь уже сделать просто ".icon".
В твоих рассуждениях неправильно одно — не всегда CSS пишет «нормальный верстальщик». Есть проекты где верстальщика нет совсем, а есть 20 человек разработчиков. И вот один пилит попап, который надо сдать вчера, и ему надо у кнопки добавить справа padding. И если ему не запретить делать .mypopup-footer-new .button.save { padding-right: 20px } — в CSS будет ад через месяц.
Если у тебя весь CSS делает один верстальщик — у тебя нет никаких таких проблем, которые решает БЭМ. Если он еще и хороший верстальщик — ему можно дать картинку, и пусть пишет CSS как ему хочется. Хоть по БЭМ, хоть каскадом, хоть инлайнами.AmdY
04.11.2015 02:44Бум. Что-то мы друг друга не понимаем. Я как раз и говорю, что достаточно использовать вложенность стилей и они будут разнесены по нейспейсам, не пересекаясь. Нельзя делать глобальных классов. А вот
".block .element {}" и ".other-block .element {}" хотя и имеют совпадающий класс element, но они разные и стили не пересекаются. В тоже время, если их оформление совпадает, то можно использовать миксины, например
.block { .element { color: red; } } .other-block { .element { color: blue; // если хотим миксин - .block .element; } }
а в коде
<div class="block"> <div class="element">Красный цвет</div> </div> <div class="other-block"> <div class="element">Синий цвет</div> </div>
а в случае BEM было бы что-то вроде block__element--color-red и block__element--color-blue, и в случае если нам подадобится поменять цвет, нужно править и стили и шаблоны.jakobz
04.11.2015 02:54Проблемы будут если у тебя где-то будет:
.element { font-family: "Comic Sans"; }
Т.е. кто-то использует имя для блока, совпадающее с именем элемента.
Но есть и другие проблемы. Блоки могут вкладываться. И например такое вот:
<div class="block"> <div class="element">Красный цвет</div> <div class="other-block"> <div class="element">Синий цвет</div> </div> </div>
— будет уже зависеть от того, в каком порядке у тебя CSS склеилсяAmdY
04.11.2015 03:12+1По поводу первого кейса я писал
>>Нельзя делать глобальных классов.
БЭМ же тоже от такого не спасает, определит что-то стили для «div» и полчишь глобальные проблемы. Точно так же не спасет от каскадности, если есть правило для block, оно проникнет и в вложенные block__element.
Проблему вложенности решается через более стогие правила css вроде
.block > element {}
плюс можно использовать того же less и заинклудить в .block. element правила .other-block, тогда за счёт более весомых селекторов будут применяться нужные, плюс в качестве бонуса получим возможность стилизовать вложенные блоки.
Используешь ты БЭМ или нет, каскадность CSS у тебя остаётся и проблемы с ней те же.jakobz
04.11.2015 03:34Ну как не спасает. По БЭМ как раз нельзя делать глобальные стили для div. И случайно сделать селекторы, которые проникают в чужие блоки — тоже не выйдет, только если сознательно нарушить правила.
Если решать проблему вложенности через более строгие селекторы — у тебя к CSS привязывается структура HTML. Что тоже неприятно. И там, вероятно, даже больше писать надо будет — особенно если элемент куда-то глубоко вложен.
Вообще, мне кажется что ты не против идеи изолировать CSS, тебе просто не нравится что классы получаются здоровенные. Но на практике, с тем же LESS и каким-нибудь angular-bem, оно будет как-то так:
.message { &--warning { color: yellow; } }
и
<div block="message" mods="warning" />
Т.е. как по мне смысл БЭМ не в том, чтобы заставить бедных верстальщиков писать классы в пол страницы шириной. Смысл в том, чтобы простыми и относительно штатными средствами организовать себе в стилях модульность. И если нет возможности использовать тузлы, и надо писать на голом CSS — я вероятно выбрал бы code convention не заставляющие писать столько много букв. Но сам принцип БЭМ, по возможности, я бы оставил.
vithar
04.11.2015 09:41А вот
http://habrahabr.ru/post/270075/#comment_8641817
".block .element {}" и ".other-block .element {}" хотя и имеют совпадающий класс element, но они разные и стили не пересекаются.
а в случае BEM было бы что-то вроде block__element--color-red и block__element--color-blue,
В случае БЭМ это было бы
<div class="block"> <div class="block__element">Красный цвет</div> </div> <div class="other-block"> <div class="other-block__element">Синий цвет</div> </div>
.block__.element { color: red; } .other-block__element { color: blue; }vintage
04.11.2015 10:20Так ещё круче:
[div my-block]
[div my-block=«element»]Красный цвет[/div]
[/div]
[div my-other-block]
[div my-other-block=«element»]Синий цвет[/div]
[/div]
[my-block=«element»] { color: red; }
[my-other-block=«element»] { color: blue; }vithar
04.11.2015 11:20«Просто всё уже было»:
https://ru.bem.info/forum/-68/vintage
04.11.2015 11:31+1Никогда не разделял этого вашего стремления «минифицировать любой ценой» :-)
vithar
04.11.2015 11:42Простите, но это вы мне пишете «Так ещё круче», а не я вам.
Я вам оппонирую, что мы уже все возможные варианты рассмотрели и даже использовали это в продакшене. Потом отказались от «извращений» в пользу простых классов и простой схемы именования.vintage
04.11.2015 12:32+1Ну а вы мне кидаете статью про минификацию. Это, конечно, интересная инженерная задача, но совсем бестолковая. Особенно в эпоху клиентской шаблонизации.
Ну да, а пихать все классы в один атрибут — совсем не извращение :-)
Delka
04.11.2015 13:43Повышая специфичность, вы лишаетесь возможности менять разметку и переносить блоки: delka.name/blog/2013/04/bem-otkroveniya-prinyavshih-veru
Я тоже раньше так писал, но таким блокам нужно создать (скопировать) контекст! Им нужно создать вокруг них, выше, те же самые блоки с такими же классами. Если тебе нужно перенести блок на другую страницу — тебе нужно создать такие же родительские блоки. Или нафигачить кучу бессистемных multiple classes :(
stychos
03.11.2015 20:52А SCSS/Less не про модульность разве?
banzalik
03.11.2015 20:54+1SCSS/Less — про несовершенство CSS.
stychos
03.11.2015 20:56Я вот честно, в глаза до сих пор не видел этот БЭМ, но из увиденного в комментариях немного ужаснулся. Не понимаю, что мешает использовать препроцессоры для обеспечения этой пресловутой модульности?
banzalik
03.11.2015 21:05+1А я не понимаю, как препроцессоры могут в этом помочь — они помогают писать CSS код, а модульность — это из разряда архитектуры проекта.
stychos
03.11.2015 21:14С моей точки зрения, препроцессор позволяет разбить код так, как удобно архитектору, хоть по модулям, хоть по количеству килобайт на файл, кому что нравится. А как БЭМ помогает? Это что вообще, кодогенератор? Из того, что прочёл тут, мне показалось, что эти ребята хотят заменить html json'ом, но при чём тут вообще стили? Кто до этого момента мешал архитектору приложения раскладывать «модули» по отдельным папочкам?
stychos
03.11.2015 21:20Более того, я совсем не фронтендер, в своих проектах всегда создавал такие же «модули» по структуре. Но фронтендеры меня ругали, что я лох, ничего не понимаю, и вообще — надо использовать всякие модные requirejs, и прочие сборщики проектов. На мои аргументы о размерах кода и портабельности всей связки php+html+js+css в виде модуля — всегда получал «это всё устаревшая никому не нужная ерунда». И тут, внезапно, выясняется…
jakobz
04.11.2015 01:02+1БЭМ — это naming convention, который позволяет делать то, что в языках программирования называется namespaces.
LESS и прочие препроцессоры — позволяют разнести код по файлам. Но сами по себе они ничего не делают для того, чтобы правила в этих файлах не влияли друг на друга.
БЭМ — это простые правила, которые гарантируют что селекторы из одного «модуля» не влияют на другие модули. И что единственный способ повлиять на селекторы внутри модуля — навесить модификаторы.
БЕМ и LESS — ортогональны. Мы используем и LESS, и БЭМ. Причем никто не запрещает пользоваться и другими инструментами инкапсуляции из LESS — всякими хелперами-миксинами, например. Главное принцип «модули не лезут внутрь друг к другу» соблюдать.
Например если есть .fancy-button, у которого внутри .fancy-button__label — не надо делать штуки типа ".my_panel .fancy-button__label { color: red }". Надо идти в fancy-button.css, и делать там модификатор fancy-button--important.
Блок должен оставаться «черным ящиком», это главный принцип. Внутри — юзай что хочешь, это уже не суть важно.
Классический принцип «разделяй и властвуй», ничего более.vithar
04.11.2015 09:48+1Например если есть .fancy-button, у которого внутри .fancy-button__label — не надо делать штуки типа ".my_panel .fancy-button__label { color: red }". Надо идти в fancy-button.css, и делать там модификатор fancy-button--important.
Лучше использовать миксы (https://ru.bem.info/method/definitions/#Микс), чем плодить модификаторы. В данном случае лучше сделать ".my-panel__button-label {color: red}" и использовать как «class='my-panel__button-label fancy-button__label'.»jakobz
04.11.2015 14:19Я не очень понимаю миксы в БЭМ. Мне кажется они нарушают принципы, которые сам БЭМ и задает. Может быть они имеют смысл при верстке на чистом CSS, или в рамках тулчейна яндекса. Но тоже самое можно сделать миксинами CSS-препроцессора, и это будет более прямо и безопасно
Мы вообще используем БЭМ поверх React. У нас под каждый компонент есть блок в отдельном less-файле. И стили компонента может использовать только сам компонент. Единственный легальный способ поменять внешний компонента — передать ему другие props-ы. Как и какие модификаторы он вешает — его личное дело. В принципе, мы часто и inline-стили вешаем — например ширину колонки в таблице, там слишком много букв писать по классу каждой колонке.
Я думаю что это уже настоящий БЭМ, но идея та же — инкапсуляция компонентов.
Delka
03.11.2015 19:26+2БЭМ не противопоставляет себя семантической верстке.
БЭМ дополняет её, вносит ещё один уровень смысла (семантики) в документ.
Презентационная верстка: мы знаем что есть какая-то красная кнопка.
<input class="big_red_button">
Семантическая верстка: мы знаем что это какая-то кнопка покупки товара.
<input class="order-button">
Семантическая верстка + БЭМ: это кнопка оплаты в форме покупки со скидкой.
<input class="order-button discount-checkout__submit">Delka
03.11.2015 19:32+1И про то, кому БЭМ облегчает работу:
Например, если бы я попросил вас удалить все классы, относящиеся к пользователю, в этом куске кода, какие бы вы выбросили?
<div class="media user premium"> <img class="img photo avatar" src="" /> <p class="body bio">...</p> </div>
…а в этом?
<div class="media user--premium"> <img class="media__img user__photo avatar" src="" /> <p class="media__body user__bio">...</p> </div>
funca
03.11.2015 20:14Любая практическая методология, предполагает некий алгоритм успеха. Иными словами, если в заданных условиях делать все согласно методологии, то желаемый результат будет достигнут. В этом их польза методологий.
Многие покупаются на БЭМ-методологию в расчете, дескать, вот щаз как внедрим и все станет «зашибись», как Яндексе. Проблемы возникают из-за того, что многие так же забывают, что как и любая практическая методология, БЭМ имеет свою конкретную область применения — мало кто понимает насколько все «зашибись» в Яндексе, почему так, как устроена разработка и какова роль в этом БЭМ.
Эффективность решения задач повышается за счет использования подходящих технологий, накопления опыта, повторного использования кода и автоматизации. Методологии же нужны, чтобы создавать технологии. В Яндексе примерно так все и устроено: одни люди занимаются разработкой технологий следуя БЭМ и прочим методологиям — кодят инструментарий, компоненты, пишут документацию, рассказывают на конференциях как все круто, другие — решают с помощью них практические задачи.
Если вы не Яндекс, то у вас наверняка совершенно другие исходные условия, и и поэтому БЭМ-методология работать не будет. Но такой вывод следует из определения, поэтому является банальным и ни кому не интересным.
tadatuta
03.11.2015 21:02Приведу такой неслучайный список сайтов, сверстанных по БЭМ:
http://www.microsoft.com/ru-ru/azure/wizard/
http://mymail.my.com/ru/
http://sheben96.ru/
http://smartpack.pro/
Они ведь ничего общего с Яндексом не имеют. Скажите, почему БЭМ-методология для них сработала?AmdY
03.11.2015 21:21+1Отличные примеры, хочешь показать что такое плохой БЭМ, покажи их.
первый вовсе надстройка над bootstrap с его глобальными b-btn b-btn_green b-btn_block, ну и масса прочей лапши
второй получше, но це ужос footer-nav-list__foo dropdown__menu__item
два последних проекта вовсе напичканы инлайн стилями.funca
04.11.2015 00:20Когда смотришь на конечный результат, о методологиях сложно судить. Несоответствия могут быть тупо результатом наслоения работы разных людей, в разное время, которые придерживались разных подходов.
funca
03.11.2015 23:47Если уж все люди на планете знакомы друг с другом через шесть рукопожатий максимум, то в рамках отдельно взятого города что-то общее с Яндексом имеют, наверное, через одного. По-видимому, кому-то очень хотелось чтобы так случилось.
Tab10id
03.11.2015 20:15+2Терпеть не могу БЭМ, но, к сожалению, не могу упрекнуть данный подход в том, что от него нет практической пользы. БЭМ инструмент созданный для вполне конкретной цели — независимая стилизация различных компонентов страницы. Иначе говоря, для того, чтобы сверстанный компонент отображался адекватно независимо от того, на какую страницу портала (или какого-либо внешнего ресурса), и в какую их областей этой страницы ты бы его не пихнул. БЭМ справляется с этой задачей.
Ругать или хвалить в БЭМе можно только средства которыми это было достигнуто. В данном случае это уход от классической методологии использования каскада в «каскадных таблицах стилей». С учетом того, что в исходниках css'а (sass, less и тд) каскадность никуда не девается, то проблема не такая уж и серьезная.
Проблемой же в БЭМе я считаю то, что при применении данного подхода, верстка становится делом слишком «машинным», теряется семантика элементов страницы. В случае огромных функционально связанных между собой порталов с разными командами разработчиков данных подход полностью оправдан, это тот случай когда много думать вредно. Другое дело, что редко кому приходится разрабатывать нечто настолько огромное.
В остальных же случаях достаточно более «мягких» методологий. Лично я предпочитаю smacss, так как на мой взгляд он не портит семантику и действительно позволяет масштабировать проект. Да, думать приходится много, но оно того стоит.
ЗЫ: Ну и… мне не нравятся стандартные рекомендации по именованию классов в БЭМ. Все эти "__" и "--" довольно омерзительны=)tadatuta
03.11.2015 20:52+2Раскройте, пожалуйста, мысль — как именно БЭМ портит семантику?
Tab10id
03.11.2015 22:09+3Разберу приведенный выше пример
- link
- menu-list__link
- menu-list__link_size_small
Из приведенного только link просматривается в качестве семантического элемента, хотя и это лишнее, так как link наверняка является <a href="...">.
Класс menu-list__link не имеет отношения к семантике, вообще…
В классе menu-list__link_size_small к семантике отношение могла бы иметь только часть link_size_small, если бы назвалась не link_size_small, а, к примеру, link_secondary или link_is_secondary (да, я знаю что в данном примере, size это модификатор, а small это его значение, в этом и есть семантическая проблема, этот класс говорит не о смысле элемента, а о его отображении)vithar
03.11.2015 22:17Как раз в этих классах семантики (смысла) сильно больше, чем в голых a, span и прочих div.
Про link_size_small:There are only two hard things in computer science: cache invalidation and naming things.
То, как именованы конкретные переменные — не проблема методологии, а проблема конкретного именующего.Tab10id
03.11.2015 23:08+2То, как именованы конкретные переменные — не проблема методологии, а проблема конкретного именующего.
Проблема правильного имени класса есть только в «link», ее я и имел ввиду когда написал что лучше уж пусть будет голый <a>, чем <a> с таким классом.
Для простоты мысленно дадим ему более адекватное имя, full-article-link, к примеру.
В итоге получится:
- full-article-link
- menu-list__full-article-link
- menu-list__full-article-link_size_small
- Первый класс семантикой наполнился
- Второй по прежнему не имеет семантического смысла, линк как был, так и остается ссылкой на полную статью, нам незачем дополнительно подчеркивать это отдельным классом, а то что данный линк лежит внутри меню мы можем узнать просто посмотрев на DOM
- Третий класс по прежнему не говорит нам ничего о ссылке, он говорит только о том, что она маленькая, а не о том почему она такая
Последнее как раз ограничение именно методологии, так работают модификаторы.
Самая семантичная замена size_small, которую я смог сейчас придумать это importance_low, но:
- класс смотрится стремно
- намекает на то что где-то должен быть importance_high и подобные, вряд ли наличие подобных классов предполагалось в приведенном изначально примере, сомневаюсь что модификатор size там нес какую-либо смысловую нагрузку
- в БЭМ'е обычно так не делают
Можно еще попытаться преобразовать модификатор size в некий «булевый» модификатор, к примеру, «secondary» как я написал в предыдущем комментарии, тогда класс будет иметь вид: «menu-list__full-article-link_secondary», семантика появляется. Но при этом должно поменяться и css-правило для данного класса. Грубо говоря вместо:
.menu-list__full-article-link_size_small { font-size: 7px; }
должно стать:
@mixin small-font { font-size: 7px; } .menu-list__full-article-link_secondary { @include small-font; // что-то еще }
А это уже не совсем классический подход к БЭМ-модификаторамvithar
03.11.2015 23:16-1Нет, menu-list__link не должно становиться .menu-list__full-article-link.
В этом примере menu-list__link это ссылка внутри блока menu-list и она смешивается с full-article-link. Блок menu-list это какое-то меню, которое ничего не знает, что в него вкладывают, его семантика — быть меню и показывать всё, что в него положат.
Ну и secondary лучше задавать для full-article-link: .full-article-link_secondary (хотя предполагаю, что абстрактное меню может иметь в себе ссылки разных размеров (оставим за скобками зачем это нужно) и _size_small указывает как раз на это, что может быть ещё normal).
tadatuta
03.11.2015 23:45Если вы заявляете, что «Класс menu-list__link не имеет отношения к семантике, вообще», видимо, стоит определиться с тем, что мы подразумеваем под термином «семантика». Подсмотрел в Википедии такое определение: «Семантика языка — это смысловое значение слов». Вроде по menu-list__link вполне понятно, какой смысл вкладывал автор?
Вы упускаете важный момент: БЭМ про компоненты (примерно как web components).
Рассматриваемый пример говорит следующее:
link — это ссылка. Универсальная, используемая совершенно произвольно. Полный аналог тега <a>. Следующий класс menu-list__link говорит, что данная ссылка кроме прочего является частью универсального меню (семантически очень похоже на семантику тега <li>, но уже чуть более конкретно). Кроме того эта ссылка имеет определенное свойство menu-list__link_size_small (аналогия — пропсы и стейты в Реакте).
Отличие от варианта с menu-list__full-article-link_secondary (который, конечно, тоже вполне имеет право на жизнь) в том, что мы однажды на проекте определили, как ведут себя абстрактные ссылки, отдельно — как ведет себя меню, а дальше применяя композицию, можем собирать из таких кирпичей что-то более сложное.
Т.е. это некая середина между совсем уж абстрактными <a> и <li>, у которых семантики немногим больше, чем у <div> и <span>, но все-таки с шансом на реиспользование и возможность при рефакторинге менять код для всех ссылок сразу (да, препроцессоры тоже позволяют этого добиться, вопрос лишь в том, что современный компонент — это сумма стилей, скриптов и разметки, а тут уже препроцессоров не хватает).
Ну а довод вида «то что данный линк лежит внутри меню мы можем узнать просто посмотрев на DOM» как раз и является иллюстрацией того, что с БЭМ исчезает необходимость смотреть в DOM или, наоборот, правя HTML подсматривать в стили, чтобы понять, что это за компонент. Это как называть переменные осмысленно, вместо i, j, k — тоже ведь можно по коду понять, что i хранит данные пользователя, j — флаг авторизации, а k — цену товара.Tab10id
05.11.2015 14:07Не люблю отвечать на отдельные части комментариев (обычно это приводит только к разрастанию холивара), поэтому постараюсь кратко и по существу.
Почти готов согласится с Вами по поводу наличия семантики в классе menu-list__link, если в данном случае действительно имеется ввиду ссылка элемента меню. Снова спишем на неудачное имя класса и предположим что на самом деле имеется ввиду menu-list__menu-item-link. Но хотел бы заметить что далеко не факт что имелось ввиду именно это, к примеру могла бы быть примерно такая структура DOM:
.menu-list .menu-list__link .... %hr .menu-list__link .... | .menu-list__link .... | .menu-list__link ...
По поводу абстракций… Мне как раз то чего всегда хочется избежать их на итоговой странице, ИМХО, абстракциям место только в исходниках, в своих проектах я с этой задачей справляюсь.
Честно говоря не понимаю о чем мы сейчас спорим, я согласен с тем что БЭМ выполняет свою задачу, я лишь говорю о том, что классический подход к применению данной методологии имеет свою цену, а неклассический подход идентичен по результату тому же smacss (отличие будет только в наличии в стилях " > ." вместо "__" и в количестве классов у элементов).
tadatuta
03.11.2015 20:39+2Я время от времени слышу, что Яндекс агрессивно продвигает БЭМ. В частности об этом сказал автор поста, zapolnoch и AmdY.
Расскажите, пожалуйста, что вы понимаете под агрессивным продвижением?
Я слежу за этой темой и за последний год слышал про пару докладов на яндексовых же Субботниках, еще пару на других конференциях от яндексоидов и, наверное, пяток докладов от людей не из Яндекса, пару статей на Хабре и, вроде, всё. Зато последнее время про БЭМ регулярно пишут западные разработчики: https://www.google.com/search?q=bem+methodology&lr=lang_enfunca
04.11.2015 00:35+1Создается ощущение, что БЭМ в версте стал сродни MVC в программировании, в том смысле, что каждый находит его во всем, что видит, но понимает по-своему. Когда я читаю github.com/google/material-design-lite/wiki/Understanding-BEM, в душу начинает закрадываться сомнение, что это тот же БЭМ, который у Яндекса.
stas404
04.11.2015 00:39-1funca
04.11.2015 10:35+1Загляните в исходники mdl (какой-нибудь кнопки например, github.com/google/material-design-lite/blob/master/src/button/_button.scss). Они спокойно используют каскады между b-e-m в любых комбинациях, переопределяют стили других «блоков». По сути, это обычный CSS, как в boostrap, foundation и т.п., только с необыкновенно длинющими названиями классов.
tadatuta
04.11.2015 13:21+1Загляните в исходники bem-components: https://github.com/bem/bem-components/blob/v2/design/common.blocks/button/_theme/button_theme_islands.styl
Мы спокойно используем каскады и переопределяем стили других блоков, когда это обосновано.
Загляните, наконец, в описание методологии: https://ru.bem.info/faq/#Почему-нежелательно-использовать-вложенные-селекторы
Там явно написано, почему БЭМ не рекомендует вложенные селекторы и приводятся примеры, когда это оправдано.
В душу начинает закрадываться сомнение, что в Яндексе тот же БЭМ, который рисуют в своем воображении благодарные пользователи ;)
sashabeep
03.11.2015 20:54Когда я вижу на обычном сайте с одним единственным шаблоном весь этот ужас с двойными тире, подчеркиваниями и прочим вытекающим, я не могу понять, с чего вдруг придурок, который это верстал, придумал что это круто, а самое главное — что это пишется вручную.
Число сайтов, которым нужен БЕМ ничтожно мало в натуральном выражении.
И, да, каскад — это одна из букв в аббревиатуре CSS.tadatuta
03.11.2015 21:17+1Так все-таки, какие проблемы возникают на этом обычном сайте с одним единственным шаблоном из-за подчеркиваний?
А то столько придурков убеждены, что БЭМ — норм (http://webstandardsdays.ru/2014/05/24/pres/bem-ok)…
sashabeep
03.11.2015 23:02+1Использовать кучу трудночитаемых классов вместо простых блоков типа nav,header,aside и т.п в сайте, у которого этих самых блоков код наплакал, дизайн которого не предусматривает, как минимум, никакой масштабируемости в течение нескольких ближайших N*5 лет — глупо. Иногда смотришь и думаешь, неужели где-то конкурс проводят на использование как можно меньшего количества тегов
vithar
03.11.2015 23:11-1«хум хау»
Мне использование БЭМ позволяет всё разложить по компонентам и иметь реализацию каждого компонента в одном месте:
https://github.com/vithar/bem.info/tree/master/common.blocks
Ну и что тут трудночитаемого?
https://github.com/vithar/bem.info/blob/master/common.blocks/nav/nav.csssashabeep
03.11.2015 23:19Вы так говорите, как будто до этого никто не раскладывал все по компонентам.
Некоторые школы предпочитают сверхдлинные мечи. С точки зрения моей Стратегии — это слабые школы. Они не принимают принципа «рубить врага любыми средствами». Они предпочитают особо длинный меч. Полагаясь на его длину, они думают нанести поражение противнику с расстояния.
tadatuta
03.11.2015 23:55+1Про придурки и глупо я услышал. А вот какие проблемы возникнут на этом злополучном сайте, где кот наплакал и не планируется масштабируемости — нет. Расскажите?
sashabeep
04.11.2015 10:45+1Нет никаких проблем. Клиент попользуется им, а когда дизайн выйдет из моды, через пару лет он будет переверстан заново за несколько часов
dom1n1k
03.11.2015 21:19+2Каскад был совершенно логичен на момент своего изобретения.
Сегодня же, когда веб-страницы и (о, ужас) веб-приложения условжнились на пару порядков — он показал своё несовершенство во всей красе.
Нет, я конечно же, не предлагаю отказаться от него совсем — в умеренных количествах он нужен.
Но решить полностью все задачи, стоящие перед верстальщиком в 2010-х годах он не в состоянии, это инфа 146%.
Конечно, в идеальном мире было бы намного круче, если бы на нас свалился некий более современный вариант CSS с обновленной архитектурой и устраненными недостатками. Но, как все мы понимаем, этого не случится ещё долго. В этом смысла да, БЭМ — отчасти костыль. Но это лучшее из имеющегося.
Rosscian
04.11.2015 00:16+2Посмотрите, например, на bemto. Это не круто, это просто удобно, понятно и совсем не сложно.
И, да, каскад — это одна из букв в аббревиатуре CSS.
А многие ли, сочиняя аббревиатуру DHTML, думали о JS как языке серверной и тем более десктопной разработки?voischev
04.11.2015 09:08А вот еще на что можно посмотреть. https://github.com/rajdee/posthtml-bem инструмент еще проще. И можно использовать с любым шаблонизатором
sashabeep
04.11.2015 11:07Да зачем мне на что-то смотреть?
В моей предметной области в ближайшие несколько лет даже не предвидится проектов, которым нужны сборщики, модные шаблонизаторы и прочее… Я же не ору на каждом углу что так, как я должен работать каждый, и как-то по-другому — это лажа и отстой. Соглашение об именовании классов давно сложилось в голове и описано в корпоративном вики, где также есть все готовые, кхм, «блоки» для всего, что нужно и не нужно — всему этому я обучу толкового человека за 1 день. И даже если он обзовет «модификаторы» или переверстает «блоки» как ему заблагорассудится, и объяснит, что так правильно и это реально будет удобнее, чем было — всегда пожалуйста.
Вот вам реальный юзкейс, сколько времени уйдет, чтобы добавить новую форму на сайт на шареде, используя, хотя бы, тот же SASS? Открыть проект — сверстать, скомпилить, закинуть...? А если проекта на конкретной машине нет и работаешь из дома, а форму кровь из носа надо сверстать девочке до понедельника, потому что у нее KPI и всё такое? Вписывать в компилированный Это же не тру! И так на 99% всех сайтов объемом не больше пары тысяч страниц…
Для каждого вида труда найдется свой инструментvoischev
04.11.2015 11:19Как-то, сильно уж противоречиво написали. Никто никого не заставляет, скорее рекомендуем. Кстати ваше корпоративная wiki и то, что сложилось в голове, ничем не лучше и не хуже что вам предлагают.
Rosscian
04.11.2015 11:46Да зачем мне на что-то смотреть? В моей предметной области в ближайшие несколько лет даже не предвидится проектов, которым нужны сборщики, модные шаблонизаторы и прочее…
Как минимум для того, чтобы знать, от чего отказываетесь. Вдруг понравится?
А код, картинки и прочее руками сжимаете? И все-все стили в одном файле?
Я же не ору на каждом углу что так, как я должен работать каждый, и как-то по-другому — это лажа и отстой.
Да я как бы тоже. Вообще, у меня сложилось впечатление, что вы пишете только «голый» HTML/CSS. Если так удобнее — что ж, каждому свое, но присмотреться к прогрессу никогда не вредно.
А если проекта на конкретной машине нет и работаешь из дома, а форму кровь из носа надо сверстать девочке до понедельника, потому что у нее KPI и всё такое?
А в чем проблема иметь все на домашней машине? Если же есть только чужая машина, то вряд ли вы будете в блокноте верстать. Скорее зайдете на тот же codepen, который уже даже PostCSS поддерживает — то есть там даже компилировать ничего не придется.sashabeep
04.11.2015 16:41Никто не говорил, что не пробовал, в моих реалиях это совершенно не нужно.
Пишу голый html/css, хотя, в-общем, html пишу редко, готовых блоков написал очень много, и мне теперь не нужно их писать, а что, это плохо? Файлов несколько, но какая разница? Не очень понял. Все минифицируется на лету. Подход немного другой, и работает без всяких выделенных серверов, и править руками все просто.
Проблема в том, что на работе надо работать, а дома — только в крайнем случае и с многократно увеличенной оплатой.
Compass, например, мне очень нравится, то, с какой скоростью можно делать там «жвачку», которая отнимает время — «бальзам на душу» и всё такое. Но применить мне его негде.
stychos
03.11.2015 20:59Автор, зачем Вы выдернули меня из моего уютного мирка, в котором долгое время обитал только чистый css, а недавно только подселился и scss? Нет, ну я пару раз в жизни видел html-код всяких яндексов, но никогда не думал, что это — пишут люди, и что это целая модная, стильная и молодёжная методика.
norlin
03.11.2015 21:19Это как раз не люди пишут, а роботы. Люди пишут что-то вроде такого, если говорить конкретно о Яндексе.
stychos
03.11.2015 21:30Да, уже увидел — это немного спасает ситуацию. Но за вот такое меня фротендеры всегда ругали. Я всегда строил приложения по принципу таких «модулей», где в одном конкретном модуле в иерархической системе лежит вся необходимая ему информация — php, html-форма, стили, js, картинки и всё такое. Я им говорил: так меньше генерируемого кода, быстрее загрузка, — мне отвечали, что сейчас всем на это наплевать, это прошлый век, и вообще иди учи requirejs, grunt, gulp b ещё тысячи других менеждеров пакетов для менеджеров пакетов.
vithar
03.11.2015 22:11+14Вообще статья явный наброс на вентилятор, но отвечу на некоторые замечания на правах соавтора БЭМ (вместе с veged).
Если сверстать страничку таблицами, как это было во времена IE6, то улучшения от перехода на БЭМ с такой верстки определенно будут.
«Плохая аналогия как банан в лифте». Вёрстка таблицами и использование правил именования БЭМ в HTML/CSS — ортогональны друг другу и ни как не пересекаются.
Есть хорошие готовые практики, которые давно решают все задачи сопровождаемости.
Приведите их, мне правда очень интересно узнать практики которые прям «давно» и «решают».
Если бы БЭМ был так прекрасен, как описывают авторы, не было бы срача.
Если у чего-то нет хэйтеров — это что-то абсолютно никому не нужно.
БЭМ — это жесткий и очень топорный свод правил, который не несет никакой практической пользы
Практическая польза от правил в БЭМ примерно такая же, как от полиморфизма, инкапсуляции и наследования в ООП. Правила задают систему, система позволяет быстрее разбираться в чужом и своём коде.
Не создают они (каскады) проблем при сложной верстке.
Рекомендую почитать историю создания БЭМ (https://ru.bem.info/method/history/). Если вам каскад в вёрстке не создаёт проблем и не хочется ограничивать область видимости и область применимости селектора — я вам очень завидую, у вас впереди ещё много открытий чудных.
Единственное, мне больше нравится «западная» модификация БЭМа, где модификаторы имеют сокращенный синтаксис.
В «официальном» БЭМ тоже есть сокращённый синтаксис модификаторов:
https://ru.bem.info/method/naming-convention/#%D0%98%D0%BC%D1%8F-%D0%BC%D0%BE%D0%B4%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%82%D0%BE%D1%80%D0%B0
А разделители между блоком, элементом и модификатором могут быть любые. Например, .block%element&modifier — соответствует БЭМ нотации.
У меня от БЭМ сильное чувство, что ребята как-то недопоняли CSS, не осилели LESS и в итоге налепили велосипедов.
Спецификации HTML4 и CSS2.1 были мной прочитаны раза 4 за всё время работы от начала и до конца. Думаю, что это сильно больше, чем их прочитало 99% веб-разработчиков.
Советую почитать описание методологии, мы его недавно переписали, на наш взгляд стало понятнее:
https://ru.bem.info/method/definitions/
Если есть вопросы — приходите на форум, обсудим/ответим/поможем:
https://ru.bem.info/forum/kmmbvnr
04.11.2015 08:37А чем БЕМ лучше чем — github.com/rstacruz/rscss?
vithar
04.11.2015 09:55+1БЭМ проще, непробиваемее, не только по css.
rscss это упрощённый вариант БЭМ, в котором введены дополнительные искусственные ограничения. Автору так нравится больше, вай бы и нот?
sashabeep
03.11.2015 23:29С тех пор, как ооп, полиморфизм и прочие красивости с ним пришли во фронтенд — все и заверте…
В — общем все претензии в итоге сводятся в одну — агрессивный маркетинг и, как следствие, холивар между пофигистами и апологетами
Andre_487
04.11.2015 19:22+2Знаете, что я скажу вам, господа? Мир фронтенда — бегун на костылях в принципе, но бегун быстрый. У нас особая ситуация — наши программы выполняются в браузерах, возможности которых ограничены, конкретные браузеры выпускаются разными, никак не связанными командами, а версии обновляются неравномерно.
HTML изначально был предназначен для статей, связанных гиперссылками, но разработчики и пользователи захотели красивых страничек, и начали использовать таблицы для позиционирования и всякие атрибуты для украшательств. Это костыль или чистейший гений архитектуры? Конечно, костыль — таблица же для данных, а не для верстки страниц.
Версии обновляются медленно, а мы хотим новых возможностей JS или писать для браузера на совершенно другом языке. Появляются полифиллы, транспайлеры и компиляторы в JS. Так что же, разве не костылями являются Babel или TypeScript? Да конечно костылями — это же надо, компилировать высокоуровневый язык в JavaScript! А кое-кто ведь и низкоуровневые компилирует! Это вынужденная мера, но путем таких костылей мы получаем огромные возможности.
Так же, поскольку у нас нет иного выбора, кроме CSS, а возможности его ограничены, приходится на этих ограниченных возможностях строить методологии, которые оградят разработчиков от стрельбы по ногам и облегчают масштабируемость и поддерживаемость кода. Отсюда и появились БЭМ и другие его братья. Да, они ограничивают некоторые возможности CSS и привносят некоторые правила, которые можно назвать костылями с точки зрения академической архитектуры. К примеру, селекторы в БЭМ — классический пример борьбы с коллизиями при использовании глобальных переменных. Но это не от хорошей жизни — в современном CSS нет других возможностей создавать пространства имен.
Но что делать, отказаться от любых хаков, лишь бы не вылезать из калеи, в которую нас загоняют веб-технологии в чистом виде? Конечно нет, если бы мы так делали — веб не пришел бы туда, куда пришел.
Веб — богатейшая почва для набросов, можно сорвать покровы с любой актуальной технологии и методологии и потешить тем самым самолюбие, но стоит ли этим заниматься? Может быть, лучше было бы разработать достойную альтернативу или пойти и заняться улучшением какой-нибудь из текущих? Может быть, оно само по себе и не взлетит и не станет лучше, но свежая идея — тоже очень важная в мире веба штука.
asci
BEM приучает и хорошо сочетается с компонетной разработкой, которая тут, в 2015м году стала довольно популярной среди фронтендеров
nazarpc
Хм… для компонентной разработки придумали веб-компоненты, а правила именования CSS классов не решают проблему в корне. То есть проблемы по сути никуда не делись, просто придумали некоторый костыль который позволяет реже наступать на грабли.
vitkarpov
В Яндексе компонентый подход приняли задолго до того, как это стало популярно и все к этому пришли. Виталий Харисов первый раз рассказывал про БЭМ, кажется, еще в лохматом 2007 году.
i360u
Вот тут все как раз наоборот: имеено при современном компонентном подходе, при использовании, для сборки интерфейса, чего-то типа Реакта или Полимера, БЭМ — становится не нужен вообще. Вместо блока-элемента-модификатора мы имеем компонент-элемент-параметр, и большая часть этой конструкции часто сильно связана с JS-кодом (биндинг css-классов). БЭМ был хорошим решением в свое время, но не стоит тащить этого динозавра в светлое будущее.