Комментарии 270
BEM приучает и хорошо сочетается с компонетной разработкой, которая тут, в 2015м году стала довольно популярной среди фронтендеров
Хм… для компонентной разработки придумали веб-компоненты, а правила именования CSS классов не решают проблему в корне. То есть проблемы по сути никуда не делись, просто придумали некоторый костыль который позволяет реже наступать на грабли.
Вот тут все как раз наоборот: имеено при современном компонентном подходе, при использовании, для сборки интерфейса, чего-то типа Реакта или Полимера, БЭМ — становится не нужен вообще. Вместо блока-элемента-модификатора мы имеем компонент-элемент-параметр, и большая часть этой конструкции часто сильно связана с JS-кодом (биндинг css-классов). БЭМ был хорошим решением в свое время, но не стоит тащить этого динозавра в светлое будущее.
Я вот не верстальщик, так и не понял что за БЭМ. Большая Электронная Машина? Обычно не применяемую в массах аббревиатуру расшифровывают в начале статьи.
Да я то уже разобрался, спасибо.
А наминусили то за что? Какого хрена? В чём не прав?
А наминусили то за что? Какого хрена? В чём не прав?
Поговорка есть такая: не погуглив не спрашивай
А при чём здесь «не погуглив», зачем вообще на хабре что-то публиковать — ведь есть всезнающий гугл...?
Я сделал замечание по поводу оформления статьи и понеслось… Вместо «Спасибо, поправил» заминусили и в карму насрали… Ужас!!!
Я сделал замечание по поводу оформления статьи и понеслось… Вместо «Спасибо, поправил» заминусили и в карму насрали… Ужас!!!
Замечания по оформлению обычно в личку отправляют. Возможно, поэтому. ;-)
Так на Хабре чуть ли половина статей содержит термины/аббревиатуры без последующей расшифровки. Статьи ж пишутся для определённой аудитории. Смотрите на теги — если там «семантическая верстка, табличная верстка, бэм», статья в хабах Веб-разработка, HTML, CSS, а я не верстальщик, то логично что я нифига там не пойму, тем более в заголовке статьи не было фразы «для чайников».
Всё таки хабр это не закрытый форум для «верстальщиков», здесь более широкая аудитория, 9,7к просмотров на данный момент, и вряд ли все глубоко погружены в тему, по сему наверное надо оформлять статьи с расчётом, что её прочтут не только узкие специалисты.
Вообще, есть же теги
Типа БЭМ. Можно вполне использовать для новичков.
<abbr title="" ></abbr>
<acronym title="" ></acronym>
Типа БЭМ. Можно вполне использовать для новичков.
Да можно и ссылочку прикрутить, если не лениться.
Вообще-то как минимум стоит посмотреть на хабы, в которых размещена статья. Подавляющее большинство читающих эти хабы если не используют БЭМ везде и не разбираются в тонкостях, то с аббревиатурой у них точно проблем нет.
Я повторю фразу, которую говорил уже года два назад, кажется.
Бэм это попытка влететь в светлое будущее (уже настоящее), размахивая костылями. Если приложить достаточно усилий — может и получиться, но без слез на это не взглянешь, я согласен тут.
Бэм это попытка влететь в светлое будущее (уже настоящее), размахивая костылями. Если приложить достаточно усилий — может и получиться, но без слез на это не взглянешь, я согласен тут.
НЛО прилетело и опубликовало эту надпись здесь
пойдем от обратного — НЕ костылем является решение, которое оставляет довольно приличный workflow, не вносит избыточности и при этом дает необходимый функционал без существенных оговорок. В случае с БЭМ — всегда есть ощутимые оговорки (если вот сейчас спор зайдет об этом — то это явно троллинг, потому что БЭМ сам по себе оговорка, звучащая как «есть три типа сущностей»), и есть два решения — либо вся экосистема (то есть ломается workflow ко всем хренам собачьим), либо следование гайдам (то есть внесение адовой избыточности). По-моему это явный костыль, полагающийся на разработчика.
НЛО прилетело и опубликовало эту надпись здесь
Например, css modules — через уже существующие реализации в сборщиках. Это простое, эффективное и качественное решение, позволяющее разработчику почти бесплатно (дополнительный пункт в пайплайне сборки и определенные незначительные изменения в процессе разработки) получить изоляцию модулей стилей.
В моем случае, например, это обеспечивается webpack+css-loader+postcss-loader[postcss-local-by-default], и выглядит как
Думаю, это выглядит как довольно неплохой и вполне читаемый шаблон, легко интегрирующийся с почти любым фреймворком (местами, конечно, можно чуть подпилить, но мне в силу используемых библиотек это не нужно). В отличии от БЭМ.
Еще есть другие, альтернативные варианты, предусматривающие более глубокий пересмотр подхода к стилизации, но адепты БЭМ, мне кажется, не подумают даже хотя бы попробовать.
В моем случае, например, это обеспечивается 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>`
Думаю, это выглядит как довольно неплохой и вполне читаемый шаблон, легко интегрирующийся с почти любым фреймворком (местами, конечно, можно чуть подпилить, но мне в силу используемых библиотек это не нужно). В отличии от БЭМ.
Еще есть другие, альтернативные варианты, предусматривающие более глубокий пересмотр подхода к стилизации, но адепты БЭМ, мне кажется, не подумают даже хотя бы попробовать.
НЛО прилетело и опубликовало эту надпись здесь
А вы не путайте теплое с мягким. Это конкретный пример кода на реакте с его data-reactid, если их вырезать, получится вполне симпатично. Но реализация Css Modules может быть использована вообще где угодно.
Более того, если передавать нескомпилированные из оригинального шаблонизатора шаблоны — будет вообще легче жить зачастую.
С поправкой на то, что это именование классов для отладки, а по факту именование классов можно сделать любым, какой-нибудь другой фреймворк будет выдавать в сборке продакшна
и так далее, что выглядит весьма многообещающе — места по крайней мере занимается куда меньше.
Более того, при помощи webpack это можно использовать как и где угодно. Например, в jade.
Если что — выходные стили можно спокойно собрать себе в один файл и не париться даже.
Более того, если передавать нескомпилированные из оригинального шаблонизатора шаблоны — будет вообще легче жить зачастую.
С поправкой на то, что это именование классов для отладки, а по факту именование классов можно сделать любым, какой-нибудь другой фреймворк будет выдавать в сборке продакшна
<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) йа кнопко
Если что — выходные стили можно спокойно собрать себе в один файл и не париться даже.
НЛО прилетело и опубликовало эту надпись здесь
В этом году уже считается приличным вводить отдельные классы для JS-логики, отделяя биндинги от стилизационных классов, так что будет что-то вроде styles.button + " js-button". Правда, я не считаю это хорошим подходом и предпочитаю использовать custom elements для этих целей. Благо, они ie9+. В таком случае получаем что-то вроде
Что как по мне — является куда более читаемым, чем нагораживание стилей.
- var styles = require('Component.css')
component-container(class=styles.container)
multi-button(class=styles.button) йа кнопко
Что как по мне — является куда более читаемым, чем нагораживание стилей.
С поправкой на то, что это именование классов для отладки, а по факту именование классов можно сделать любым, какой-нибудь другой фреймворк будет выдавать в сборке продакшна«Какой-нибудь другой фреймворк» и БЭМ-классы может выдавать в таком же минимальном виде, разницы нет.
Как я понял, претензия у вопрошающего была в том числе к data-reactid, который вот вообще не связан с реализацией css modules. Поэтому и уточнил про «другой фреймворк».
Я не спорю, что БЭМ может. Только нахрена, если все то же самое сейчас можно делать не ломая привычного подхода к разработке и не нагораживая монстра?
Я не спорю, что БЭМ может. Только нахрена, если все то же самое сейчас можно делать не ломая привычного подхода к разработке и не нагораживая монстра?
но адепты БЭМ, мне кажется, не подумают даже хотя бы попробовать
Я «адепт БЭМ» и, тем не менее написал обзор CSS-модулей :)
БЭМ — появился не на пустом месте, а для решения конкретных задач. Если есть инструменты, которые могут решить эти задачи иначе: надо обязательно на них смотреть (как минимум, чтобы свой собственный взгляд в этом вопросе расширять).
Приведите аргументы и примеры. Чем именно БЭМ вреден? Что лучше?
Я не защищаю БЭМ. Мне просто интересно увидеть конкретные косяки, а не общие утверждения.
Я не защищаю БЭМ. Мне просто интересно увидеть конкретные косяки, а не общие утверждения.
Плюсую. Хотелось бы еще услышать альтернативы, а то автор советует изучить «другие практики», но к сожалению я о таких не слышал.
А это общая черта всех подобных статей против БЭМ — громкие слова, общие утверждения и отсутствие конкретных аргументов или примеров. Ну, либо аргументы, вытекающие из недопонимания методологии.
Статья какая-то однобокая. Автор пробовал верстать большие проекты без нагромождений !important? Есть HTML семантика, ок. А что делать когда на одной странице огромное количество элементов с одинаковыми тэгами и их нужно по разному стилизовать?
Если не нравится использовать БЭМ — можете не использовать. Но код ваш вряд ли будет таким же хорошим, как без него (если разве что вы не гениальны и не найдете ему замену типа как сейчас обсуждают модульный цсс).
Если не нравится использовать БЭМ — можете не использовать. Но код ваш вряд ли будет таким же хорошим, как без него (если разве что вы не гениальны и не найдете ему замену типа как сейчас обсуждают модульный цсс).
А что делать когда на одной странице огромное количество элементов с одинаковыми тэгами и их нужно по разному стилизовать
Я где-то слышал, что есть такая штука — класс, кажется, называется… Говорят, используя их (классы) можно стилизовать огромное количество элементов с одинаковыми тэгами. Или бэм предлагает революционный способ разной стилизации огромного количества элементов в одну строчку?
Если использовать классы без строгих правил их наименования (по сути, это то, чем БЭМ и является) то в большом проекте рано или поздно классы начнут путаться. Вы можете не использовать БЭМ, но для стабильности кода вам придется сделать строгие правила наименования классов. Имхо, создать свое правило наименование классов вместо использования общепринятого БЭМ — это как раз велосипед =] Мне кажется, что люди, не пишущие на БЭМ просто никогда не работали с большой постоянно меняющейся базой css кода, которая изменяется несколькими разработчиками.
О насколько большом проекте идет речь? Что-то мне подсказывает, что путанье классов будет видно очевидно, сразу и так же просто будет устранено, при этом не создав никакой путаницы. Да и никто не мешает использовать одни из существующих или собственные правила именования классов, которые решат эту проблему. В конце концов БЭМ это не только именование
Пришел в проект где вообще не использовался БЭМ, теперь страдаю от того что не могу нормально переверстать страницу из-за того что не знаю какой класс в какой должен быть вложен, потому что они именованы как попало.
НЛО прилетело и опубликовало эту надпись здесь
Если Вы переверстываете, то зачем Вам смотреть какой класс в каком должен быть вложен?
Если Вы вносите изменения в верстку, разве инспектор не показывает какие правила на блоке сработали?
Т.е. это не проблема отсутствия БЭМ, это, как Вы и сказали «они именованы как попало», хотя меня и заминусили, но я написал, что:
Если Вы вносите изменения в верстку, разве инспектор не показывает какие правила на блоке сработали?
Т.е. это не проблема отсутствия БЭМ, это, как Вы и сказали «они именованы как попало», хотя меня и заминусили, но я написал, что:
никто не мешает использовать одни из существующих или собственные правила именования классов, которые решат эту проблему.
Ваша проблема не в БЭМ, а в криворукости тех, кто «именовал как попало».
Народная мудрость
Неча на зеркало пенять, коль рожа крива.
НЛО прилетело и опубликовало эту надпись здесь
Согласен с автором во всем, ни разу не встречал ситуации где БЭМ мог бы решить задачу лучше чем правильное использование HTML + CSS.
Ах, это сокральное «правильное использование HTML + CSS».
А можете описать эти правила? Я был бы рад перейти.
Неиссякаемым источником таких правил станет для вас w3c. Хотя можно начать с этого: developer.mozilla.org/en-US/docs/Web/CSS
Абсолютно не согласен с автором. Очень люблю БЭМ-подход к стилям в первую очередь за избавление от каскадности. Когда вижу css типа такого:
С подобным подходом любые изменения в HTML-разметке страницы требуют обязательных изменений CSS-кода. БЭМ же позволяет почти полностью отделить разметку от стилей, сильно облегчая любые изменения, переносы/добавления/удаления элементов и т.д. и т.п.
Ну и повторное использование уже свёрстанных блоков становится намного проще.
body > div .content .row div.article .title > p span > a {
/* и это далеко не худший пример */
}С подобным подходом любые изменения в HTML-разметке страницы требуют обязательных изменений CSS-кода. БЭМ же позволяет почти полностью отделить разметку от стилей, сильно облегчая любые изменения, переносы/добавления/удаления элементов и т.д. и т.п.
Ну и повторное использование уже свёрстанных блоков становится намного проще.
p.s. И, да:
В моём понимании, БЭМ => уход от каскадности + независимые блоки. А уж правила написания имён классов каждый может подобрать какие ему удобно, Яндекс лишь предложил один из возможных вариантов (скорее всего, учитывающий большинство возможных ситуаций, т.к. Яндексу необходимо уметь очень много всякого разного).
БЭМ – это жесткий и очень топорный свод правилЛибо вы говорите про конкретную реализацию БЭМ, либо одно из двух.
В моём понимании, БЭМ => уход от каскадности + независимые блоки. А уж правила написания имён классов каждый может подобрать какие ему удобно, Яндекс лишь предложил один из возможных вариантов (скорее всего, учитывающий большинство возможных ситуаций, т.к. Яндексу необходимо уметь очень много всякого разного).
Когда вижу 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. В БЭМ есть не плохие идеи, но всё хорошо в меру.
Не хочется, потому что это читаемо и легко меняется. Плакать-то хочется не от длины селектора, а от его некастомизируемости.
Если у вас есть селектор типа
В случае же с БЭМ вы можете просто добавить модификатор.
Если у вас есть селектор типа
body > div .content .row div.article .title > p span > aВ случае же с БЭМ вы можете просто добавить модификатор.
то, чтобы у этой ссылки для какого-нибудь случая поменять цвет, вам придётся либо повторять весь этот селекторА в БЭМ не придется? Там класс это и есть повторение селектора со всеми вложенностями. Просто точка и пробел заменены на двойное подчеркивание.
либо использовать !important.В вашем примере да, потому что его писал дилетант. Опытный верстальщик такого не напишет.
Имя класса в БЭМ ни в коем случае не имеет ничего общего с вложенностью HTML-элементов. Имя класса в БЭМ семантическое и отображает суть элемента. А сложная структура с подчёркиваниями, ключевыми словами типа _type_ и т.д. – лишь частный случай реализации, который позволяет учесть максимальное количество возможных применений.
Опытный верстальщик такого не напишет.Для продолжения предметной дискуссии, приведите ваш пример для следующего кода:
Скрытый текст
Можете переименовать любые классы + определите селектор для ссылки внутри .title.<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>.title a { ... }
*sarcasm* невероятно круто, да? */sarcasm*
Еще раз хочу спросить, кто же требует всю родословную в селекторе описывать? Почему с вашей точки зрения абсолютно ненужное перечисление селектора начиная от body является аргументом в пользу БЭМ?
Но в .subtitle тоже, теоретически, может появиться ссылка. И ваш класс автоматически её «зацепит».
Он ее не зацепит, он ее опишет, и будут две одинаковые свойственные этому блоку ссылки без лишних описаний и классов. А что сделает в данном случае бэм? Если у вас что-то «может появиться» — это надо учитывать в структуре документа, как ниже в примере у Andchir
.article-author a {...}
.article-subtitle a {...}
Ну тут вы взяли уже классы из комментариев ниже, поэтому проследуем в эту ветку, чтобы не повторяться.
p.s.
Такой код, обычно, появляется при множественных модификациях вёрстки и стилей, при отсутствии БЭМ-подхода (не путать с BEM-tools).
абсолютно ненужное перечисление селектора начиная от bodyК сожалению, на практике приходится постоянно сталкиваться с подобным подходом. Не обязательно от body, это не принципиально. Но длинные каскады встречаются очень часто.
Такой код, обычно, появляется при множественных модификациях вёрстки и стилей, при отсутствии БЭМ-подхода (не путать с BEM-tools).
Хотите возможно сильно огорчу? Мне самому БЭМ не особо нравится, но я понимаю почему его используют в тяжёлых веб-приложениях.
Это не только для удобства командной разработки, но ещё и производительность! У меня шаблон порвался когда я узнал что обозреватели читают селекторы справа налево. То есть в вашем случае если у вас в документе тысячи ссылок, и вы решите использовать «.title a» обозреватель обойдёт все «a» проверяя у них родитель «.title» причём в вашем случае (а у вас «пробел» а не «>») оно ещё выше будет подниматься вместо того чтобы прекратить обход после первого уровня.
Это не только для удобства командной разработки, но ещё и производительность! У меня шаблон порвался когда я узнал что обозреватели читают селекторы справа налево. То есть в вашем случае если у вас в документе тысячи ссылок, и вы решите использовать «.title a» обозреватель обойдёт все «a» проверяя у них родитель «.title» причём в вашем случае (а у вас «пробел» а не «>») оно ещё выше будет подниматься вместо того чтобы прекратить обход после первого уровня.
Вникать можно начать отсюда.
Кстати, есть продолжение, из которого следует что даже сложные селекторы влияют на скорость загрузки в значительно меньшей степени, чем большой объем неиспользуемых стилей.
Имя класса в БЭМ семантическое и отображает суть элемента.Любое имя класса должно отображать суть элемента.
Ваш пример у опытного верстальщика будет выглядеть примерно так:
<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, то напишу позже, пока нет времени, но думаю и так понятно.
Поздравляю, вы написали имена классов, соответствующие БЭМ-методологии!
Блок article, содержащий элементы title, author, subtitle, body.
только для ссылки опустили, т.к. в данном примере ссылка одна и, в принципе, это несущественно. А если ссылок внутри author будет две, разных?
Блок article, содержащий элементы title, author, subtitle, body.
только для ссылки опустили, т.к. в данном примере ссылка одна и, в принципе, это несущественно. А если ссылок внутри author будет две, разных?
Поздравляю, вы написали имена классов, соответствующие БЭМ-методологии!Здесь есть некоторые «идеи БЭМ». Точнее обошлось без жестких правил БЭМ, но с теми же положительными качествами. Поэтому я и писал выше «В БЭМ есть не плохие идеи, но всё хорошо в меру».
А если ссылок внутри 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; }
Нет, я имел в виду, две разных ссылки. Вы сейчас написали «модификатор». А если у нас два разных элемента, которые не должны пересекаться по стилям?
К тому же, ваш класс .blue является глобальным и его могут использовать где-нибудь ещё. А потом вы в него добавите какой-нибудь ещё стиль для ссылки – и его автоматически (и обычно – незаметно) подхватит то самое «где-нибудь ещё». И это будет «незаметно», пока что-нибудь где-нибудь не развалится.
К тому же, ваш класс .blue является глобальным и его могут использовать где-нибудь ещё. А потом вы в него добавите какой-нибудь ещё стиль для ссылки – и его автоматически (и обычно – незаметно) подхватит то самое «где-нибудь ещё». И это будет «незаметно», пока что-нибудь где-нибудь не развалится.
Я считаю, что глобальные классы вполне можно использовать, но с ограничениями. Например для ссылок разного цвета — не вижу ничего плохого. А для класса .active это, конечно, очень плохо. Как в примере из документации БЭМ:
Две ссылки, одна из которых синего цвета:
Чем это опасно? Замечу, что классы .name и .site я могу использовать в других блоках, но описывать их тоже внутри родителя. Тут есть семантика, а в БЭМ семантика страдает.
.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 я могу использовать в других блоках, но описывать их тоже внутри родителя. Тут есть семантика, а в БЭМ семантика страдает.
НЛО прилетело и опубликовало эту надпись здесь
Приведите, пожалуйста, примеры как надо делать. Тогда можно будет сравнить и продолжить разговор.
.article-author__name { font-weight: bold; }
.article-author__site { font-style: italic; }
.article-author__site { font-style: italic; }
Спасибо. Уточнение: в данном случае я привел пример, в котором классы .name и .site находятся на последнем уровне вложенности. Считаю это допустимым.
Как вы собираетесь гарантировать, то что классы .name и .site не окажутся внутри других классов .name и .site?Точно так же как ваша команда следует каким-то правилам, так и моя команда следует правилу: CSS классы с общими именами (без конкретики) допустимы только на последнем уровне вложенности. И описывать их надо внутри родителя.
Как будете решать какое из CSS правил для .name и .site сейчас должно примениться, а какое нет?Не совсем понял вопроса. По-моему ответ есть в процитированном вами куске моего комментария.
CSS классы с общими именами (без конкретики) допустимы только на последнем уровне вложенностиВот есть у вас компонента menu, а ней логично есть item. А рядом есть navigation, а в нм логично тоже есть item.
И есть CSS:
.menu .item {}
.nevigation .item {}
И всё прекрасно работает, пока в какой-то из дней (обычно в пятницу перед сдачей проекта заказчику) меню не понадобится вложить в navigation. И вот тут начинается самое интересное.
И всё прекрасно работает, пока в какой-то из дней (обычно в пятницу перед сдачей проекта заказчику) меню не понадобится вложить в 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>
Ну а чё, заказчик ведь не видит кода, ему пофигу… Раз два и готово.
А я лучше переверстаю как положено.
Мне важна не скорость, а пуленепробиваемость кода, чтобы он не ломался при изменениях на странице в неподходящий момент в неподходящем месте.
А как вы переверстаете? Как положено?
А как вы переверстаете? Как положено?
А как вы переверстаете? Как положено?Извиняюсь, выше я ошибся. В этом случае всё хорошо, Вы правы.
Возьмем другой пример:
Открыть
<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>
Класс .active я опишу так:
.main-menu-item > a.active { color: #007FFF; font-weight: bold; }
.dropdown-menu-item > a.active { color: #FF9000; font-style: italic; }
Если вдруг наше меню нужно поместить в блок, у которого тоже может быть класс .active, то там тоже можно описать через родителя и конфликта не будет.
Правило, которое я дал выше, стоит переформулировать более точно :) Позже подумаю над этим.
НЛО прилетело и опубликовало эту надпись здесь
banzalik правильно пишет, малейшее изменение разметки — и стили перестают работать, и надо опять переделывать.
Так работает всегда:
Так работает всегда:
.main-menu__item_active { color: #007FFF; font-weight: bold; }
.dropdown-menu__item_active { color: #FF9000; font-style: italic; }
малейшее изменение разметки — и стили перестают работатьА что мне мешает немного подправить стили? Вы же меняете HTML, почему стили нельзя? Зато у меня будет всё чистенько, без нагромождений модификаторов.
Где гарантия, что класс, которые вы подправите, не используется в каком-нибудь другом месте верстки, и что изменения всё там не поломают?
БЭМ автоматически задает неймспейс. Классы, начинающиеся с названия блока .block__*, точно никогда и ни при каких изменениях не будут влиять ни на что за пределами конкретного компонента. Меняйте верстку внутри блока, меняете стили блока — гарантия 146%, что ничего стороннего не поломается!
БЭМ автоматически задает неймспейс. Классы, начинающиеся с названия блока .block__*, точно никогда и ни при каких изменениях не будут влиять ни на что за пределами конкретного компонента. Меняйте верстку внутри блока, меняете стили блока — гарантия 146%, что ничего стороннего не поломается!
Вёрстку делает один человек, а HTML потом в ходе жизни проекта меняет другой. А тот, кто делал вёрстку, делает уже другой проект и привлекать его к подправлению того, что сломалось — долго.
БЭМ родился исходя именно из этих условий, из промышленного производства сервисов, когда нет ни возможности, ни необходимости подправлять что-то в стилях при изменении разметки. А так же из необходимости делать компоненты, которые потом используются в произвольных местах, иногда самым неожиданным образом.
БЭМ родился исходя именно из этих условий, из промышленного производства сервисов, когда нет ни возможности, ни необходимости подправлять что-то в стилях при изменении разметки. А так же из необходимости делать компоненты, которые потом используются в произвольных местах, иногда самым неожиданным образом.
Т.е. вам непосредственный дочерний селектор религия запрещает использовать или что?
А дальше хоть 10 раз одно в другое вложит, оно не посыпется.
.menu > .item {}
.nevigation > .item {}
А дальше хоть 10 раз одно в другое вложит, оно не посыпется.
Вложите между .menu и .item что-то ещё и оно сразу перестанет работать:
http://habrahabr.ru/post/270075/#comment_8641681
http://habrahabr.ru/post/270075/#comment_8641681
А зачем мне туда что-то вкладывать?
Я написал разметку, которая предполагает что внутри
а
или если мне надо будет расписать стили того блока, то так:
Все доводы БЭМщиков это какие-то членовредительские моменты, когда «где-то между» ВДРУГ! возникают левые блоки. У меня они не возникают вдруг, код пишу я и моя команда внутри котороой есть оговоренности, а чаще всего один глобальный блок — один разраб, а значит и разметка и стили пишет один мозг, а если у него элементы появляются «вдруг», то встает вопрос «какого он забыл в команде»
Я написал разметку, которая предполагает что внутри
.menu лежат .item. А если вдруг, не пойми зачем, мне понадобится влепить что-либо между ними я просто добавлю один уровень в SCSS и будет не.menu{
& > .item{}
}
а
.menu{
& > .some_shitty_block > .item{}
}
или если мне надо будет расписать стили того блока, то так:
.menu{
& > .some_shitty_block {
& > .item{}
}
}
Все доводы БЭМщиков это какие-то членовредительские моменты, когда «где-то между» ВДРУГ! возникают левые блоки. У меня они не возникают вдруг, код пишу я и моя команда внутри котороой есть оговоренности, а чаще всего один глобальный блок — один разраб, а значит и разметка и стили пишет один мозг, а если у него элементы появляются «вдруг», то встает вопрос «какого он забыл в команде»
Очевидно, вы пишите монолитный код, а не конструктор. Из конструктора легко можно компоновать новые блоки, но цена этому — вы никогда не знаете какие блоки могут потребоваться внутри/снаружи/всередине.
Простейший пример: есть у вас форма, но полей стало как то слишком много и решено было превратить её в визард. С конструктором — достаточно положить внутрь формы блок визарда, раскидать поля по его страницам и всё. С монолитом вам придётся долго и муторно править такие вот каскадные селекторы.
Не, если вы только лендингами занимаетесь, то конструктор вам может и не нужен, но для чего-то более крупного — это просто мастхэв.
Простейший пример: есть у вас форма, но полей стало как то слишком много и решено было превратить её в визард. С конструктором — достаточно положить внутрь формы блок визарда, раскидать поля по его страницам и всё. С монолитом вам придётся долго и муторно править такие вот каскадные селекторы.
Не, если вы только лендингами занимаетесь, то конструктор вам может и не нужен, но для чего-то более крупного — это просто мастхэв.
Да ну как же, появлияется визард, инпуты имеют все то же отображение что и имели просто слилистически и семантически появляется еще и визард, вокруг инпутов.
т.е. если описывать
т.е. если описывать
.form>.wrapper input{}, а именно так я в большинстве случаев и сделаю, то ничто мне не помешает вкорячить вокруг инпутов визард, раскидав так же копипастом нужные инпуты по разным страницам.Помешает, ибо скорее всего .wrapper потребуется на каждой странице визарда, а не вокруг визарда целиком.
ну и будет у визарда описан свой
.wizard>.wrapper который ну никак не будет аффекститься .form>.wrapperТакие селекторы слишком хрупкие и часто ломаются, когда вложенные элементы переносятся в другие места.
НЛО прилетело и опубликовало эту надпись здесь
Я бы такое не написал, а за это:
вообще руки выкручивать надо. Везде эти миллионы бесполезных безликих div, p, span которыми разбрасываются направо и налево, а потом говорят о вложенности и всякой ерунде.
Переписать хотя бы так:
Здесь хоть смысл какой-то есть, и так весь ваш пример нужно переписать, тогда вам одного класса на корне логического блока будет достаточно для того, чтобы стилизовать его семантические внутренности, либо вообще обернуть в веб-компонент, тогда и класса не нужно, будет пользовательский тэг.
<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>
Здесь хоть смысл какой-то есть, и так весь ваш пример нужно переписать, тогда вам одного класса на корне логического блока будет достаточно для того, чтобы стилизовать его семантические внутренности, либо вообще обернуть в веб-компонент, тогда и класса не нужно, будет пользовательский тэг.
НЛО прилетело и опубликовало эту надпись здесь
Не верю, что человек такое напишет. Скорее это вывод LESS или аналога.
мне от такого не хочется плакать, потому что мне понятно что здесь написано и, зачастую, очень легко в коде найти вхождения по названию класса. А вот наблюдать каскады, от которых толком не отнаследоваться в том же less — вот от этого плакать хочеться.
Мне кажется что и тот и тот пример это жесть, вложенность и количество селекторов — не улучшают читабельность кода. Просто нужен здоровый адекватный баланс между первым и вторым. В какие то моменты это будет похоже на div > span > .article > p, в какие то моменты на link link___control menu___list, но для этого нам ведь не нужен БЭМ так ведь? Зачем загонять себя в жесткие рамки правил? Если очевидно что один и тот же подход не может быть одинаково хорошо использован в различных случаях.
От такого тоже хочется плакать, и это яркая иллюстрация случая, увидев который, люди, незнакомые с БЭМ, будут креститься и бежать от него, как от огня.
Я раньше работал в Яндексе и занимался фронтэндом, поэтому в курсе про bem tools, bem json, borschik и прочую упячку. И, надо признаться, я сильно недолюбливал БЭМ. Однако, устроившись работать в другую компанию, где никто ничего не навязывал, я со временем пришел к тому, что использую БЭМ подход именно для того, чтобы уйти от каскада. И при грамотном использовании код становится очень простым и удобным в поддержке. При этом я продолжаю считать full bem stack упячкой :)
Для тех, кто, как и автор статьи, считает, что БЭМ — это только костыли, рекомендую посмотреть вот это видео www.youtube.com/watch?v=hTmxbJF2Tts
Я раньше работал в Яндексе и занимался фронтэндом, поэтому в курсе про bem tools, bem json, borschik и прочую упячку. И, надо признаться, я сильно недолюбливал БЭМ. Однако, устроившись работать в другую компанию, где никто ничего не навязывал, я со временем пришел к тому, что использую БЭМ подход именно для того, чтобы уйти от каскада. И при грамотном использовании код становится очень простым и удобным в поддержке. При этом я продолжаю считать full bem stack упячкой :)
Для тех, кто, как и автор статьи, считает, что БЭМ — это только костыли, рекомендую посмотреть вот это видео www.youtube.com/watch?v=hTmxbJF2Tts
Идея в том, что вам не надо на это смотреть, а смотреть надо на это:
и так далее.
Что вам дает смотрение на хтмл? На это браузер должен смотреть. И почему вы называете это костылем? По мне так вполне понятно, что происходит с этим дом-узлом. Вам бы было более понятно такое?
Вообще, вы намеренно взяли пример очень сложного узла и представляете это, как костыль. В реальной жизни блоки с таким кол-ом модификаторов и миксов встречаются крайне редко. Пример показывает, что в принципе так делать можно, но это не значит, что так делать нужно. В большинстве случаев все гораздо проще.
{
block: 'link',
elem: 'control'
// и т.д.
}
и так далее.
Что вам дает смотрение на хтмл? На это браузер должен смотреть. И почему вы называете это костылем? По мне так вполне понятно, что происходит с этим дом-узлом. Вам бы было более понятно такое?
<a class="something-special"></a>
? Если да, то чем?Вообще, вы намеренно взяли пример очень сложного узла и представляете это, как костыль. В реальной жизни блоки с таким кол-ом модификаторов и миксов встречаются крайне редко. Пример показывает, что в принципе так делать можно, но это не значит, что так делать нужно. В большинстве случаев все гораздо проще.
Перестаньте думать, что живые люди пишут это руками!
В BEMJSON этот участок кода выглядит так:
В BEMJSON этот участок кода выглядит так:
{
block: 'link',
mix: [
{
block: 'link',
elem: 'control'
},
{
block: 'menu-list',
elem: 'link',
mods: {
type: 'simple',
size: 'small'
}
}
],
js: true
}
Взгляните на RSCSS[1] — возможно, понравится.
Если под БЭМ иметь ввиду только методологию — RSCSS дает примерно же, но без адовых имен классов. Если же говорить о bem-tools — ну… не знаю, мне кажется, эта штука нужна только внутри Яндекса :)
[1] https://github.com/rstacruz/rscss
Если под БЭМ иметь ввиду только методологию — RSCSS дает примерно же, но без адовых имен классов. Если же говорить о bem-tools — ну… не знаю, мне кажется, эта штука нужна только внутри Яндекса :)
[1] https://github.com/rstacruz/rscss
НЛО прилетело и опубликовало эту надпись здесь
Вам этот комент тоже не помешало бы прочитать :)
http://habrahabr.ru/post/270075/comments/#comment_8640899
http://habrahabr.ru/post/270075/comments/#comment_8640899
CSS это прежде всего семантика, вместо того чтобы пытаться описать body > div .content .row div.article .title > p span > a а можно одним единственным именем класса обозначить то чем данный элемент является, к примеру article-title и все. Если есть вероятность того что article-title будет использован дважды, то соотв. образом изменяем article-title на main-article-title и header-article-title (для примера).
Именно такой подход и является сутью БЭМ, если обобщить.
А зачем все это обзывать «БЭМ» и хардкодить в этом своде правил, что мол отныне будет так и только так и если это не так то это не БЭМ, а значит вообще не хорошо?
Не знаю, кто вам такое сказал. Лично я, когда собеседовал верстальщиков/фронтендеров, спрашивал «знаком ли вам подход БЭМ? Или вёрстка независимыми блоками?» Ну и, если было тестовое задание/примеры кода, то всё было обычно и так понятно.
Абсолютно не нужно 100% следование именно яндексовым правилам конкретной реализации БЭМ, но понимание самой методологии крайне желательно.
Абсолютно не нужно 100% следование именно яндексовым правилам конкретной реализации БЭМ, но понимание самой методологии крайне желательно.
Я у фронтендеров обычно спрашиваю знаком ли им JavaScript (CSS) и уж потом когда я удостоверюсь в том что человек шарит в чистом языке, можно спросить знает ли он jQuery / SASS / Less и все остальное. Ну вот зачем мне человек который знает БЭМ, но вот объяснить что это и зачем это КОНКРЕТНО ЕМУ не может.
Если взять гипотетическую ситуацию, когда у нас есть человек, понимающий БЭМ (на минуточку – методология вёрстки) и не знакомый при этом с CSS, то намного проще будет его обучить синтаксису CSS, чем «опытного верстальщика» без понимания подобного подхода научить БЭМ-методологии.
Естественно, вопрос про БЭМ-методологию – это «бонусный» вопрос. Важно не знание конкретной реализации, а подход человека и понимание им зачем делается то или иное.
Естественно, вопрос про БЭМ-методологию – это «бонусный» вопрос. Важно не знание конкретной реализации, а подход человека и понимание им зачем делается то или иное.
а если не обобщать и не использовать бэм, то
превращается в
и никто не заставляет описывать в css этот класс с полной «родословной» начиная от body
<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 этот класс с полной «родословной» начиная от body
Именно! Но случаи ведь бывают разные поэтому никто не мешает вам добавить дополнительный класс, либо изменить название класса таким образом как это используется в БЭМ. Таким образом свобода выражения своих мыслей посредством CSS не обязательно приведет к хаосу в коде (в том случае если этого хаоса не было в голове разработчика изначально, но тут и БЭМ не поможет)
Кажется, тут многие путают конкретную реализацию БЭМ и, собственно, методологию. Класс menu-link вполне подходит для методологии, при условии, что этот класс используется для одного вида элементов.
block-element, модификатора нет, то есть – это у нас дефолтный вид для ссылки в меню. А «страшный» пример выше показывает максимально возможное количество «фич».
block-element, модификатора нет, то есть – это у нас дефолтный вид для ссылки в меню. А «страшный» пример выше показывает максимально возможное количество «фич».
А чем отличается реализация БЭМ от методологии БЭМ? Это не сарказм, я действительно не очень в курсе того, что существуют еще и альтернативные (может в т. ч. проприетарные) реализации.
Эм. Методология – это суть того, что хотят сделать. А реализация, это как осуществена данная методология на практике. Поэтому, абсолютно не важно, есть ли другие реализации или нет – теоретически, их никто не мешает создать, при желании. Более того, лично я никогда не использовал BEM-tools в своих проектах и считаю их, в общем случае, крайне неудобными, но, при этом, всегда стараюсь верстать по БЭМ-методологии.
Знали бы вы все, что за этим кроется и как эта строка изначально выглядела — так бы не говорили ;)
Этот HTML не написан руками разработчика так как вы его видите…
Кусок кода который ты привел сильно широко используется разными технологиям, т.е. это не просто HTML + CSS!
В данном случае тут смесь разных технологий, а именно:
2 разных шаблона разных компонент
js функциональность с разных уровней сборки
css c разных уровней сборки
В этом шаблоне используется такое понятие как mix (что это такое можешь сам почитать), то есть это никак нельзя равнозначно представить так как ты написал.
Если говорим только про HTML + CSS структуру, то давайте уберем все то что тут есть про JS (кстати это в системе сборки автоматом прилетает в код, как и многое другое), что бы хоть как то сравнивать.
Получим следующее:
Разложим mix на два компонента, получим:
ссылку
и элемент пункта меню
…
с link все понятно.
Давай разберем menu__link
Явно что это элемент. Значит где то выше по дереву будет сам блок menu!
Посмотрим на модификаторы. Они явно не просто так!
menu-list__link_type_simple — явно что есть более сложные реализации пункта меню. Например на основе псевдо ссылки. (про декларативную шаблонизацию по модификаторам расписывать не буду) А возможно на других блоках например на основе кнопки.
menu-list__link_size_small — явно есть другие размеры меню. кстати это работает для для всех типов этого элемента
В итоге:
Оказывается — много всего можно понять из этого кода! А я никакого отношения к написанному коду не имею. За то понимаю БЭМ. ;)
А теперь попробуй рассказать хоть что-то не очевидное про твой пример
Спасибо!
Этот 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>
Спасибо!
Да, неплохо. Но давайте представим, что есть такой же элемент, а лучше два. каждый отличается от первого menu-link чем-то одним, например, шрифтом и фоном. Ваши действия? Навскидку:
— Дописать другие классы, перебивающие свойства первого. Жуть.
— Задать новый класс и скопировать все стили из первого, изменив нужные свойства. Но мы уже не можем реиспользовать код, мы повторяем себя. А если в будущем понадобится изменить еще что-то? Искать и править все классы? То есть, ухудшается поддержка.
— Если используем препроцессоры, применить экстенды и прочие плюшки. Опять же, проблема — может потребоваться изменить только первый класс, а невольно изменим и остальные.
— Вынести общие свойства в один класс, а разные — в его «подклассы». Удобно? Вполне. Вот только теперь у нас получается блок/элемент и его модификаторы, а по сути — методология БЭМ.
А если нужна возможность смены темы оформления страницы, как на главной того же Яндекса?
И не забываем, что длиннющие и устрашающие классы в HTML пишутся не руками.
Правда, у БЭМа есть и проблемы. Пожалуй, главная — что «чистый» БЭМ сам постоянно нарушает принцип DRY, ибо требует полной независимости блоков.
В общем, как обычно — смотрим на задачи, условия и, исходя из них, подбираем инструменты, одним из которых и является БЭМ. И уж точно не методология или ее разработчики виноваты в том, если ее начинают использовать не по уму.
— Дописать другие классы, перебивающие свойства первого. Жуть.
— Задать новый класс и скопировать все стили из первого, изменив нужные свойства. Но мы уже не можем реиспользовать код, мы повторяем себя. А если в будущем понадобится изменить еще что-то? Искать и править все классы? То есть, ухудшается поддержка.
— Если используем препроцессоры, применить экстенды и прочие плюшки. Опять же, проблема — может потребоваться изменить только первый класс, а невольно изменим и остальные.
— Вынести общие свойства в один класс, а разные — в его «подклассы». Удобно? Вполне. Вот только теперь у нас получается блок/элемент и его модификаторы, а по сути — методология БЭМ.
А если нужна возможность смены темы оформления страницы, как на главной того же Яндекса?
И не забываем, что длиннющие и устрашающие классы в HTML пишутся не руками.
Правда, у БЭМа есть и проблемы. Пожалуй, главная — что «чистый» БЭМ сам постоянно нарушает принцип DRY, ибо требует полной независимости блоков.
В общем, как обычно — смотрим на задачи, условия и, исходя из них, подбираем инструменты, одним из которых и является БЭМ. И уж точно не методология или ее разработчики виноваты в том, если ее начинают использовать не по уму.
Да конечно — всё зависит от архитектуры вашего приложения.
Можно позвать на помощь препроцессоры в случаях с небольшими изменениями.
Но в БЭМ в частности в подходе разработки библиотек компонент — есть такое понятие как «темизация» https://github.com/bem/bem-components/tree/v2/design/common.blocks/link/_theme
То есть нужно понять где у вас границы темы и разложить темы в классы модификаторы. Только и всего
Будет следующее:
И тогда все будет хорошо. Вы будете точно знать какая ссылка будет использоваться в каком месте и с какой темой. Кстати в таком случае место использования совсем не важно, так как вы завязаны на «класс» ссылки и легко подобные ссылки можно будет поменять сразу во всем приложении (так чаще всего происходит при обновлении дизайна).
Вариант два — подмешать (сделать микс) другой элемент там где это нужно.
Тот же самый присловутый пример с ссылкой и пунктом меню:
и на menu__item уже навесить нужные стили, дополнив базовые стили ссылки.
Это прям крутота! Целых два варианта решения описанной проблемы! :) (на самом деле больше)
По моему опыту (а у меня его прям очень много) БЭМ никогда нигде не жмет, а делает только лучше. Значительно ускоряет разработку. Дает возможность легко передавать работу / обучать других сотрудников. Разрабатывать библиотеки. Максимально реиспользовать уже сделанное
Можно позвать на помощь препроцессоры в случаях с небольшими изменениями.
Но в БЭМ в частности в подходе разработки библиотек компонент — есть такое понятие как «темизация» 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 уже навесить нужные стили, дополнив базовые стили ссылки.
Это прям крутота! Целых два варианта решения описанной проблемы! :) (на самом деле больше)
По моему опыту (а у меня его прям очень много) БЭМ никогда нигде не жмет, а делает только лучше. Значительно ускоряет разработку. Дает возможность легко передавать работу / обучать других сотрудников. Разрабатывать библиотеки. Максимально реиспользовать уже сделанное
Я привел пример решения поставленной задачи причем выглядит круто! А как бы вы решили эту задачу? :)
А вы точно меня имеете в виду?)
Я-то отвечал на этот комментарий и говорил, что
совсем не так круто, как это может показаться на первый взгляд. Собственно, и вопрос про темизацию был туда же — как, не используя БЭМ, можно легко решить эту задачу.
Я-то отвечал на этот комментарий и говорил, что
<a class="menu-link"></a>
совсем не так круто, как это может показаться на первый взгляд. Собственно, и вопрос про темизацию был туда же — как, не используя БЭМ, можно легко решить эту задачу.
НЛО прилетело и опубликовало эту надпись здесь
Не увидел ни одного аргумента у автора статьи, не увидел реальных примеров. Обсуждать, по-моему, нечего. Видимо, автору дали поддерживать проект, а он ничего не понял и излил сюда душу :)
Заинтересовался БЭМ, начал читать о ней и наткнулся на ролик Школы вебмастеров Яндекса, где кто-то из евангелистов БЭМ подробно разъясняет методологию и в качестве примера тут же создает веб-страницу по ней.
Примерно на десятой минуте он начинает путаться в названиях классов, которые только что создал… это продолжается несколько минут, после чего я не выдержал, закрыл ролик и перестал думать о БЭМ.
Прошу меня простить, я ненастоящий сварщик, некрепкий духом, неверный основам и вообще не самурай.
Примерно на десятой минуте он начинает путаться в названиях классов, которые только что создал… это продолжается несколько минут, после чего я не выдержал, закрыл ролик и перестал думать о БЭМ.
Прошу меня простить, я ненастоящий сварщик, некрепкий духом, неверный основам и вообще не самурай.
Много воды и никаких аргументов.
У меня к БЭМу на счёт CSS вопросов нет. Но вот что касается общей применимости методологии — вот тут у меня вопросы.
Если мы строим полностью динамическое web-приложение, так же всё более менее понятно.
Но когда половина контента генерируется сервером, а другую часть хочется реализовать с использованием того де БЭМ. Вот тут возникают вопросы:
Пока я не смог разрешить для себя эти вопросы. И использую только CSS-ную часть от БЭМ. Оно действительно упрощает повторное использование и кастомизацию интерфейса.
Если мы строим полностью динамическое web-приложение, так же всё более менее понятно.
Но когда половина контента генерируется сервером, а другую часть хочется реализовать с использованием того де БЭМ. Вот тут возникают вопросы:
- Надо ли «статический»(с точки зрения приложения) контент оборачивать в компоненты
- Если надо, то как это лучше сделать?
- Если же не надо, то приходится «вклеивать» БЭМовские вклеивать в DOM, что убивает всю прелесть использования БЭМ. Т.к. получаем частично спагетти код, для встраивания компонентов в DOM, для навешивания слушателей на «статические» компоненты.
Пока я не смог разрешить для себя эти вопросы. И использую только CSS-ную часть от БЭМ. Оно действительно упрощает повторное использование и кастомизацию интерфейса.
Изучить другие методологии? Это какие же? Нет их.
Ну точнее, они есть — но сколько я ни пытался понять их преимущества, мне это не удалось.
Единственное более-менее удобоваримое исключение — OOCSS, да и то не фонтан. Что-то с серединки на половинку.
БЭМ поначалу выглядит непривычно, и я тоже подходил к нему со скепсисом. Но потом понял — сейчас это практически единственный вариант, который одновременно понятен и эффективен. Он слегка громоздок, но это разумная плата за понятность, однозначность и стандартность.
Конечно, даже его можно довести до абсурда, навешивая на каждый элемент по 5 классов и 10 модификаторов. Но при разумном применении всё более чем окей.
Единственное, мне больше нравится «западная» модификация БЭМа, где модификаторы имеют сокращенный синтаксис.
Ну точнее, они есть — но сколько я ни пытался понять их преимущества, мне это не удалось.
Единственное более-менее удобоваримое исключение — OOCSS, да и то не фонтан. Что-то с серединки на половинку.
БЭМ поначалу выглядит непривычно, и я тоже подходил к нему со скепсисом. Но потом понял — сейчас это практически единственный вариант, который одновременно понятен и эффективен. Он слегка громоздок, но это разумная плата за понятность, однозначность и стандартность.
Конечно, даже его можно довести до абсурда, навешивая на каждый элемент по 5 классов и 10 модификаторов. Но при разумном применении всё более чем окей.
Единственное, мне больше нравится «западная» модификация БЭМа, где модификаторы имеют сокращенный синтаксис.
Люто, бешено плюсую. Критикуя что-то будьте объективны и предлагайте варианты.
smacss
Оно довольно похоже на MCSS.
Пока читаешь доку — ну вроде да, есть своя логика.
Как переходишь к практике — ваще непонятно что, как, когда и зачем нужно делать.
Пока читаешь доку — ну вроде да, есть своя логика.
Как переходишь к практике — ваще непонятно что, как, когда и зачем нужно делать.
Недавно в ленте твиттера было сообщение о том что автор OOCSS или SMACSS писал что бы люди использовали БЭМ вместо того что он придумал
Про MCSS было такое сообщение, причем самим автором тут на хабре. Насчет вышеперечисленных не знаю.
А вот тоже самое от автора MCSS: habrahabr.ru/post/256109/#comment_8442829
Вот оно:
@HugoGiraudel Most common misspelling is “SMACCS”. I should just rename it to BEM.— Snook (@snookca) 5 июня 2015
Пока БЕМ был действительно внутрирунетовской штучкой, я тоже к нему скептически относился.
Но недавно гугл выпустил css фреймворк основанный на БЕМ — www.getmdl.io
Но недавно гугл выпустил css фреймворк основанный на БЕМ — www.getmdl.io
Приведу пример. Есть у меня библиотека компонентов состоящая из двух элементов: superInput и superSelect. Для того чтобы иметь возможность встраивать эти компоненты в существующие страницы без возможности конфликтов я присвою их корневым элементам классы: myLib-superInput и myLib-superSelect, т. е. HTML будет выглядеть так:
Для стилизации контента самого элемента, а также его детей я буду использовать CSS:
Теперь вопрос: это уже БЭМ или еще не БЭМ?
<div class="myLib-superInput">
тут что то еще
</div>
Для стилизации контента самого элемента, а также его детей я буду использовать CSS:
.myLib-superInput {
...
}
.myLib-superInput input {
...
}
Теперь вопрос: это уже БЭМ или еще не БЭМ?
.myLib-superInput inputвот это не соответствует БЭМ, на мой взгляд.
Т.к. если у нас есть блок .myLib-superInput, то его элемент input должен иметь свой уникальный (среди других классов) идентификатор, по которому, при необходимости, можно было бы наследоваться.
Вот это просто ломает мне мозг, зачем я должен думать в CSS'е о том, что откуда должно наследоваться. Еще и идентификаторы какие то, у меня и так все прекрасно работает и проблем никогда ни у кого не вызывало (кроме адептов БЭМ).
К сожалению для того чтобы привести более внятные аргументы мне нужно будет изучить БЭМ, но ни времени ни желания изучать эту «прорывную» технологию у меня нет, а потому я пожалуй воздержусь от дальнейшей критики.
К сожалению для того чтобы привести более внятные аргументы мне нужно будет изучить БЭМ, но ни времени ни желания изучать эту «прорывную» технологию у меня нет, а потому я пожалуй воздержусь от дальнейшей критики.
На страничке из двух контролов вам про наследование элементов совсем не надо думать. А на крупном портале, где есть с десяток модификаций одной кнопочки или те же контролы в 5 разных вариациях – вот там придётся думать.
Более того, если взять идеальную ситуацию «у нас есть 100% ТЗ, где полностью описаны все элементы и их поведение и это ТЗ меняться не будет никогда» – тогда БЭМ тоже будет излишен, можно и так заверстать. Но в реальных условиях любой проект развивается, меняется, перевёрстывается, передизайнивается – и вот тогда вся эта штука очень пригождается, чтобы держать вёрстку в адекватном состоянии без запредельных усилий.
Более того, если взять идеальную ситуацию «у нас есть 100% ТЗ, где полностью описаны все элементы и их поведение и это ТЗ меняться не будет никогда» – тогда БЭМ тоже будет излишен, можно и так заверстать. Но в реальных условиях любой проект развивается, меняется, перевёрстывается, передизайнивается – и вот тогда вся эта штука очень пригождается, чтобы держать вёрстку в адекватном состоянии без запредельных усилий.
Господа, чего Вы ссоритесь?
Просто же все.
БЭМ как и CSS — это инструменты. Как и любой инструмент, для каких-то задач хорошо подходит один, для каких-то — другой.
Самый универсальный и беспроблемный инструмент — это CSS.
В большинстве случаев его хватает с головой и код получается вполне нормальный, читаемый и чистый. Естественно, применять его надо с головой — а иначе все что угодно, даже самое идеальное, можно превратить в трэш. Есть случаи, где реально наследование мешает. Однако, большинство этих случаев — рукожопость верстальщика и (или) архитектора.
Однако, если Вы собираете больше двух однотипных и выдержанных в одном стиле сайтов из стандартных повторяющихся «кусков», делающихся разными группами девелопперов — то, возможно, Вам будет интересен БЭМ. Он позволяет быстро собирать и обновлять такую штуку.
Части эти могут разрабатываться независимо и внедряться также. Это удобно, особенно для веб-приложений. Отсутствие наследования позволяет не бояться, что при изменении силя какого-либо блока где-то что-то уедет за его пределами.
БЭМ был очень распиарен Яндексом, они очень любят пиарить свои поделки — им надо — они же на бирже играются :)
Популярность и универсальность БЭМа, а также профит от него дико преувеличен.
Лично я не понимал БЭМ сначала, и даже спрашивал на хабре в чем фишка.
Затем был опыт использования его в несколькоих сторонних проектах. В одном оно было прибито гвоздями из цикла — гики от него в восторге, Яндекс не может ошибаться!
А вот в паре других оно реально работало.
По моему опыту — для большинства простых сайтов БЭМ не нужен вовсе. Он начинает давать профит при большом парке однотипных сайтов, или в случае разработки масштабного веб-приложения, компоненты которого как раз и пишутся с использованием БЭМ, а, затем, как из конструктора, из этих блоков строится приложение.
В любом случае, увы и ах — БЭМ — это костыль. Подвижки к этой теме делает нативный шэдоудом, и если он взлетит — то тогда все это поделие не нужно будет.
Ну и еще я не люблю, когда что-то называют серебряной пулей. Нет такого, все зависит от задач.
Как то так.
Как в том анекдоте:
-Свет мой зеркальце скажи, да всю правду доложи, яль на свете всех милее, всех прекрасней и белее?
-Ты красива, спору нет…
-И все?!
-И все...
Просто же все.
БЭМ как и CSS — это инструменты. Как и любой инструмент, для каких-то задач хорошо подходит один, для каких-то — другой.
Самый универсальный и беспроблемный инструмент — это CSS.
В большинстве случаев его хватает с головой и код получается вполне нормальный, читаемый и чистый. Естественно, применять его надо с головой — а иначе все что угодно, даже самое идеальное, можно превратить в трэш. Есть случаи, где реально наследование мешает. Однако, большинство этих случаев — рукожопость верстальщика и (или) архитектора.
Однако, если Вы собираете больше двух однотипных и выдержанных в одном стиле сайтов из стандартных повторяющихся «кусков», делающихся разными группами девелопперов — то, возможно, Вам будет интересен БЭМ. Он позволяет быстро собирать и обновлять такую штуку.
Части эти могут разрабатываться независимо и внедряться также. Это удобно, особенно для веб-приложений. Отсутствие наследования позволяет не бояться, что при изменении силя какого-либо блока где-то что-то уедет за его пределами.
БЭМ был очень распиарен Яндексом, они очень любят пиарить свои поделки — им надо — они же на бирже играются :)
Популярность и универсальность БЭМа, а также профит от него дико преувеличен.
Лично я не понимал БЭМ сначала, и даже спрашивал на хабре в чем фишка.
Затем был опыт использования его в несколькоих сторонних проектах. В одном оно было прибито гвоздями из цикла — гики от него в восторге, Яндекс не может ошибаться!
А вот в паре других оно реально работало.
По моему опыту — для большинства простых сайтов БЭМ не нужен вовсе. Он начинает давать профит при большом парке однотипных сайтов, или в случае разработки масштабного веб-приложения, компоненты которого как раз и пишутся с использованием БЭМ, а, затем, как из конструктора, из этих блоков строится приложение.
В любом случае, увы и ах — БЭМ — это костыль. Подвижки к этой теме делает нативный шэдоудом, и если он взлетит — то тогда все это поделие не нужно будет.
Ну и еще я не люблю, когда что-то называют серебряной пулей. Нет такого, все зависит от задач.
Как то так.
Как в том анекдоте:
-Свет мой зеркальце скажи, да всю правду доложи, яль на свете всех милее, всех прекрасней и белее?
-Ты красива, спору нет…
-И все?!
-И все...
BEM-tools – инструмент и, возможно, «костыль», неуниверсальный и всё такое.
БЭМ сам по-себе – методология вёрстки, предлагающая, в первую очередь, определённые правила для селекторов. И эта методология универсальная (в том плане, что с её помощью можно сверстать проект любой сложности и его при этом будет легче поддерживать, чем если писать на CSS, не придерживаясь методологии).
Комментарии к данному посту показывают, что многие не видят разницы между этими двумя понятиями.
БЭМ сам по-себе – методология вёрстки, предлагающая, в первую очередь, определённые правила для селекторов. И эта методология универсальная (в том плане, что с её помощью можно сверстать проект любой сложности и его при этом будет легче поддерживать, чем если писать на CSS, не придерживаясь методологии).
Комментарии к данному посту показывают, что многие не видят разницы между этими двумя понятиями.
Костыль она по тому например, что использует CSS на очень странный манер.
Фишка CSS — это каскады (он даже расшифровывается как Cascading Style Sheets), а в БЭМ предлагают от него отказаться.
Есть и еще почему.
Ну и про костыль — это не только мое мнение. Вы-же ветку-то читали? :)
И, сверстанное на БЭМ, ничем не проще или лучше поддерживаемо, чем сверстанное с головой на CSS. Это — заблуждение.
Примерно — одинаково.
Фишка CSS — это каскады (он даже расшифровывается как Cascading Style Sheets), а в БЭМ предлагают от него отказаться.
Есть и еще почему.
Ну и про костыль — это не только мое мнение. Вы-же ветку-то читали? :)
И, сверстанное на БЭМ, ничем не проще или лучше поддерживаемо, чем сверстанное с головой на CSS. Это — заблуждение.
Примерно — одинаково.
БЭМ предлагают от него отказаться.Что ж поделать, если для сложной вёрстки каскады создают больше проблем, чем пользы.
Не создают они проблем при сложной верстке.
Совсем. Для этого нужно лишь одно — согласованная дока внутри проекта об именовании классов.
И все.
Если ее нет — то Вас и БЭМ не спасет.
Если она есть и разработчики ее придерживаются — никаких проблем каскады не доставляют.
Это как согласованный code-style. Тоже самое. Он должен быть в проекте.
И все. Максимум, что может покрэшится от наследования — это что-то в пределах одного куска, пилящегося одной командой. Это быстро обнаруживается и лечится. Наследование тут не причем — причем прожект менеджер который орет, что нужно «вчера» и неофиты. Таким же образом может покрэшится и что-то в питоне. Давайте тогда ограничим набор операторов в питоне? )))
Совсем. Для этого нужно лишь одно — согласованная дока внутри проекта об именовании классов.
И все.
Если ее нет — то Вас и БЭМ не спасет.
Если она есть и разработчики ее придерживаются — никаких проблем каскады не доставляют.
Это как согласованный code-style. Тоже самое. Он должен быть в проекте.
И все. Максимум, что может покрэшится от наследования — это что-то в пределах одного куска, пилящегося одной командой. Это быстро обнаруживается и лечится. Наследование тут не причем — причем прожект менеджер который орет, что нужно «вчера» и неофиты. Таким же образом может покрэшится и что-то в питоне. Давайте тогда ограничим набор операторов в питоне? )))
Ещё раз – самый наглядный пример проблемы каскадов – это переопределение какого-нибудь свойства у «глубого закопанного» элемента. Приходится либо повторять весь селектор (и следить теперь за ним в двух местах при изменениях), либо использовать !important.
Вот честно — ни разу такой проблемы не возникало.
Ни у меня, ни у коллег.
Но прострелить себе ногу вообще чем угодно можно. И никакая методолгия не спасет :)
Ни у меня, ни у коллег.
Но прострелить себе ногу вообще чем угодно можно. И никакая методолгия не спасет :)
Могу предположить, что вы не участвовали в крупных живых проектах с legacy-кодом.
Предположить Вы можете, однако с реальностью это пересекается плохо :)
Аукцион и портал запущенный 7 лет назад. Как думаете, как там с легаси?
Но тут дело в том, что если люди грамотные — то прежде, чем лезть хотелки делать, общее представление о проекте и как он сделан надо иметь.
Если Вы это разобрали (или были доки и концепция — что еще круче) — то тогда у Вас такой проблемы не будет.
Если не разобрались, или концепции вообще не было — опять-же БЭМ не спасет, ибо вверху есть body input {}
:D Образно.
Ну а если Вы все причесали и переделали на БЭМ это == все причесали и переделали на CSS.
Аукцион и портал запущенный 7 лет назад. Как думаете, как там с легаси?
Но тут дело в том, что если люди грамотные — то прежде, чем лезть хотелки делать, общее представление о проекте и как он сделан надо иметь.
Если Вы это разобрали (или были доки и концепция — что еще круче) — то тогда у Вас такой проблемы не будет.
Если не разобрались, или концепции вообще не было — опять-же БЭМ не спасет, ибо вверху есть body input {}
:D Образно.
Ну а если Вы все причесали и переделали на БЭМ это == все причесали и переделали на CSS.
если люди грамотныеНу естественно! Если люди грамотные, то ни ТЗ, ни таск-трекеры, вообще никакие формальности не нужны будут – грамотные люди и так сделают всё хорошо.
В общем, чтобы поставить точку в бессмысленной ветке дискуссии, предлагаю считать БЭМ-методологию всего лишь style guide соглашением для вёрстки.
Дак вроде не это обсуждали, а по большей степени то, что БЭМ пихают в рунете вовсю как серебряную пулю, коей она абсолютно не является. Что мол перейдете на БЭМ — и все проблемы исчезнут, сайты станет поддерживать легче и вообще все будет классно. Так вот, как я выше уже написал — это — заблуждение.
Ну и там не только стайл-гайд, увы.
Я же не говорил, что БЭМ — это плохо. Но для большинства задач в веб — БЭМ излишне тяжелая и не имеет смысла.
Ну и там не только стайл-гайд, увы.
Я же не говорил, что БЭМ — это плохо. Но для большинства задач в веб — БЭМ излишне тяжелая и не имеет смысла.
И это ведь мы затронули лишь CSS — часть БЭМ. Там вроде бы есть еще и целая костыльная мастерская для JavaScript…
Не понимаю, почему БЭМ может быть «излишня», т.к. никаких оверхедов она за собой не несёт. Естественно, для странички с одной формочкой оно излишне, а если же у вас хотя бы пара страничек вёрстки – то вполне норм, не говоря уже о бОльших проектах.
А вы уверены в том что она не несет никаких оверхэдов? Есть ли статистика проседания перформанса браузера в зависимости от общего количества классов / селекторов (это ведь все нужно где то держать в памяти) против того же самого но на каскадах?
Не знаю насчёт современных браузеров, но на момент создания БЭМ я ещё работал в Яндексе и там была презентация на эту тему.
Уход от каскада, кстати, был обоснован, в том числе, выигрышем в производительности рендеринга.
Если на пальцах, то на тот момент браузерные движки рендерили селекторы справа налево.
То есть, чтобы исполнить селектор вида
При использовании же уникальных классов, выборка сразу же была по имени класса. Цифр не вспомню, было давно.
Количество же классов на производительность не влияло (как минимум, на порядках тысяч разных имён классов).
Уход от каскада, кстати, был обоснован, в том числе, выигрышем в производительности рендеринга.
Если на пальцах, то на тот момент браузерные движки рендерили селекторы справа налево.
То есть, чтобы исполнить селектор вида
.title div aбраузер сначала выбирал все элементы «a», потом среди них искал те, у которых родитель «div», и, наконец, те, в которых у «div» родитель .title
При использовании же уникальных классов, выборка сразу же была по имени класса. Цифр не вспомню, было давно.
Количество же классов на производительность не влияло (как минимум, на порядках тысяч разных имён классов).
браузер сначала выбирал все элементы «a», потом среди них искал те, у которых родитель «div», и, наконец, те, в которых у «div» родитель .title
Странная логика выборки селекторов, больше похоже на описание работы Internet Explorer…
Количество же классов на производительность не влияло (как минимум, на порядках тысяч разных имён классов).
Есть ведь еще и память
В плане перфоманса БЭМ быстрее будет — браузер не использует просчет наследования.
Другое дело, что выигрыш будет таков, что прочувствовать его на себе может только что-то уровня Яндекса. :)
Другое дело, что выигрыш будет таков, что прочувствовать его на себе может только что-то уровня Яндекса. :)
Оверхэдов она несет массу.
Во-первых, это еще одна сущность в проекте, и народ должен уметь ее (как верстльщики так и девелопы)
Во-вторых у Вас завязаны руки с каскадами — а они очень и очень удобны в некоторых случаях.
В-третьих, любое 3-rd пати (контролы или что-то еще) придется переписывать, чтобы удовлетворяло.
А иначе у Вас будет солянка, а не БЭМ.
Это первое, что вспомнил из проекта. Это не оверхэд?
Во-первых, это еще одна сущность в проекте, и народ должен уметь ее (как верстльщики так и девелопы)
Во-вторых у Вас завязаны руки с каскадами — а они очень и очень удобны в некоторых случаях.
В-третьих, любое 3-rd пати (контролы или что-то еще) придется переписывать, чтобы удовлетворяло.
А иначе у Вас будет солянка, а не БЭМ.
Это первое, что вспомнил из проекта. Это не оверхэд?
Если речь всё ещё идёт о методологии, то:
Во-первых: не более, чем любой style guide.
Во-вторых: Они могут быть удобны для быстрого хака, но в стратегическом плане они менее удобны. Более того, БЭМ не требует ПОЛНОСТЬЮ отказываться от каскадов, в некоторых случаях они оправданы.
В-третьих, вовсе не обязательно. Любые контролы идут со своими стилями и при использовании на проекте БЭМ-нейминга как раз уходит риск пересечения классов (при использовании частоупотребимых типа .article, .content и т.д.), т.к. неизвестно, что там в сторонних стилях могли накодить.
При написании же своих стилей к, например, js-контролу, нет никакой сложности сразу написать их в стиле БЭМ.
Во-первых: не более, чем любой style guide.
Во-вторых: Они могут быть удобны для быстрого хака, но в стратегическом плане они менее удобны. Более того, БЭМ не требует ПОЛНОСТЬЮ отказываться от каскадов, в некоторых случаях они оправданы.
В-третьих, вовсе не обязательно. Любые контролы идут со своими стилями и при использовании на проекте БЭМ-нейминга как раз уходит риск пересечения классов (при использовании частоупотребимых типа .article, .content и т.д.), т.к. неизвестно, что там в сторонних стилях могли накодить.
При написании же своих стилей к, например, js-контролу, нет никакой сложности сразу написать их в стиле БЭМ.
Тем не менее это все описанное — оверхэды :)
Ну и если Вы не будете все в проекте точить под БЭМ, зачем он Вам? Он работает нормально только когда на него полностью все завязано.
Например, используя 3rd пати стиль или каскад где-то as is Вы рискуете нарваться на тот-же самый глюк, ради отсутствия которого Вы и начали использовать БЭМ.
Смысл тогда?
Это технология тотальна для всего сайта — либо Вы используете только ее — и тогда получаете все ее плюсы, а иначе Вы просто делаете что-то странное.
Ну и если Вы не будете все в проекте точить под БЭМ, зачем он Вам? Он работает нормально только когда на него полностью все завязано.
Например, используя 3rd пати стиль или каскад где-то as is Вы рискуете нарваться на тот-же самый глюк, ради отсутствия которого Вы и начали использовать БЭМ.
Смысл тогда?
Это технология тотальна для всего сайта — либо Вы используете только ее — и тогда получаете все ее плюсы, а иначе Вы просто делаете что-то странное.
Например, используя 3rd пати стиль или каскад где-то as is Вы рискуете получить тотже самый глюк, ради отсутствия которого Вы и начали использовать БЭМНе рискую, потому что оно никак не будет пересекаться с моими именами классов (т.к. они уникальные и совпадение крайне маловероятно, в отличие от использования общеупотребимых слов).
Это технология тотальна для всего сайта — либо Вы используете только ее — и тогда получаете все ее плюсы, либо нет.Это касается BEM-tools, но никак не методологии.
Ещё раз – по-сути, эта методология не более чем style-guide. И любые оверхеды – не более, чем у любого другого style-guide.
Не рискую, потому что оно никак не будет пересекаться с моими именами классов
И этот же аргумент можно использовать и для чистого CSS, нет? ))))
На самом деле откуда Вы в этом так уверены? Запросто можете словить. Ибо кто знает что там в 3-party было. menu-item там стилизовался неудачно, а у вас он тоже есть.
Вобщем, давайте так — я свои доводы привел.
Вы свои — на этом и разойдемся — дальше просто полемика.
Вы евангелист БЭМа, я же — нет. Я вижу в нем только инструмент, который в некоторых случаях неплох. И когда он неплох — можно его юзать. У меня потребительское отношение к этому.
Вообще было бы круто если бы существовала тулза на вход которой давали бы CSS / HTML / JS а на выходе она упрощала бы CSS до минимально возможного скелета (также с попутным переименованием длинных классов в короткие), подобно тому как это делает Google Closure Compiler для JavaScript'а. Я в свое время пытался такое сделать, но уперся в невозможность определения того что именно является именем класса / частью селектора и т. д., а маркировать такие вещи каким то особым образом — уничтожало весь шарм. При наличии данного инструмента, было бы все равно был ли БЭМ или нет, на выходе все равно получалось бы то что работало бы максимально быстро и занимало бы как можно меньше.
Такая утилита для преобразования css была написана в Яндексе в 2010:
https://github.com/gfranco/jeanny/
Мы использовали её на странице результатов поиска:
https://blog.yandex.ru/post/23106/
Потом отказались, поскольку в JS классы иногда зашиваются в строки и склеиваются, все случаи обработать невозможно и вёрстка иногда ломается после минимизации.
Но если у вас статика без CSS-классов в JS — можно использовать, минификация будет работать.
https://github.com/gfranco/jeanny/
Мы использовали её на странице результатов поиска:
https://blog.yandex.ru/post/23106/
Потом отказались, поскольку в JS классы иногда зашиваются в строки и склеиваются, все случаи обработать невозможно и вёрстка иногда ломается после минимизации.
Но если у вас статика без CSS-классов в JS — можно использовать, минификация будет работать.
чем сверстанное с головой на CSSКак показали комментаторы выше, «свёрстанное с головой», по-сути, подходит под БЭМ-методологию. Просто те, кто «верстает с головой» без БЭМ, делают это неосознанно, за счёт чего могут быть накладки.
«Подходит» и «является» немого разные вещи, не находите?
Это уже демагогия. Важна суть, а не название.
Просто под «похоже» можно что угодно здесь подвести, ибо средства для достижения всего этого ограничены — по-сути это только CSS + HTML.
Однако похожесть не говорит о том, что Вы пишите на БЭМе — это я имел ввиду.
БЭМ — все таки достаточно точно описанная методолгия. И, либо Вы ей точно следуете и получаете БЭМ, либо у Вас не БЭМ :)
Однако похожесть не говорит о том, что Вы пишите на БЭМе — это я имел ввиду.
БЭМ — все таки достаточно точно описанная методолгия. И, либо Вы ей точно следуете и получаете БЭМ, либо у Вас не БЭМ :)
И тут мы уходим в рекурсию…
Не уходим, я не про тулзы говорю а про методологию, ага? :)
Это было к
Если речь про методологию – то замена нейминга на какой-то другой аналогичный не говорит о том, что вы перестали использовать БЭМ. Но, при этом, оно лишь «похоже» на оригинальное описание методологии.
либо Вы ей точно следуете и получаете БЭМ, либо у Вас не БЭМ
Если речь про методологию – то замена нейминга на какой-то другой аналогичный не говорит о том, что вы перестали использовать БЭМ. Но, при этом, оно лишь «похоже» на оригинальное описание методологии.
Видимо вся дискуссия упрется в то, что каждый заморачивается так как ему удобней. Просто одним удобней отстрелить себе руку для того чтобы потом когда нибудь в будущем эта рука не воспользовалась пистолетом лежащем в ящике, а другие обходятся и без столь радикальных мер.
Фишка CSS — это каскады (он даже расшифровывается как Cascading Style Sheets), а в БЭМ предлагают от него отказаться.
В блоге Яндекса была запись, в которой они объясняли причину отказа от каскадности: в нагруженных каскадными стилями страницах, применение стилей тормозилось именно из-за необходимости рассчитывать применимость стиля.
Господа, чего Вы ссоритесь?
Просто же все.
Довольно странная статья: с одной стороны кажется, будто у автора остро бомбит об БЭМ, с другой стороны судя по аргументации, автор не понимает, что такое БЭМ, и считает, что это средство, чтоб не верстать таблицами.
Я понимаю, что Яндекс в последнее время можно журить, но это не значит, что на айти любой треш-пост, где ругают Яндекс, надо плюсовать. Печально.
Я понимаю, что Яндекс в последнее время можно журить, но это не значит, что на айти любой треш-пост, где ругают Яндекс, надо плюсовать. Печально.
Яндекс верстает таблицами, поэтому БЭМ это ужасно. Я все верно понял из этой статьи? :)
Не являюсь фанатом ни full bem stack, ни яндексовской реализации БЭМа. Но уже не хватает «хабразаряда», чтобы плюсовать все взвешенные ответы norlin. Технологию БЭМ-стека/методологию БЭМ можно использовать частично — необязательно писать на bemjson, необязательно использовать сборщик enb, можно позаимствовать какие-то идеи для CSS, можно использовать только js-фреймворк i-bem.js.
(Имею опыт работы с тремя проектами с большим количеством кода, как «красивого-вылизанного», так и не очень хорошего).
(Имею опыт работы с тремя проектами с большим количеством кода, как «красивого-вылизанного», так и не очень хорошего).
Хорошие вещи обычно не нуждаются в агрессивном маркетинге.
У меня от БЭМ сильное чувство, что ребята как-то недопоняли CSS, не осилели LESS и в итоге налепили велосипедов. Но вот удивляет, что тепреь набравшись опыта и знаний они вместо того чтобы забросить велосипед, они активно его продвигают сравнивая с говновёрсткой с глобальными классами и оправдывая некой скоростью, которая даже во времена ie 5.5 уже была неактуальна.
НЛО прилетело и опубликовало эту надпись здесь
Почему современные? CSS сто лет назад придумали умные люди и сделали его с большим запасом прочности. Создание модулей-компонентов уже заложено в CSS, а БЭМ это тоже но со своими костылями и ограничениями, этакий антивирус бабушкина.
И меня удивляет их агрессивное навязывание этой технологии, которая очень неудобная, требует своего инструментария и противоречит тому, чему ещё недавно учил яндекс — семантической разметке.
И меня удивляет их агрессивное навязывание этой технологии, которая очень неудобная, требует своего инструментария и противоречит тому, чему ещё недавно учил яндекс — семантической разметке.
НЛО прилетело и опубликовало эту надпись здесь
Добавляются новые эффекты и новые типы селектов, идея остаётся той же как и обратная совместимость. Именно гибкость селектов направлена на богатый UI, а БЭМ от него отказывается в сторону точных классов на конкретный элемент, это его очередной минус. Яндекс всё же не контора про красивые и динамичные UI.
CSS придумали чтобы буковки раскрашивать. В CSS нет ни одного признака что его создавали под масштабные задачи: нет никакой модульности, нет возможности хоть какой-то абстракции, ничего там нет про запас прочности.
Зато есть каскадинг, который опять же удобен на маленьких задачах, а на больших — ведет к аду.
Именно из-за ущербности CSS у нас есть LESS, БЭМ, и подобное.
Зато есть каскадинг, который опять же удобен на маленьких задачах, а на больших — ведет к аду.
Именно из-за ущербности CSS у нас есть LESS, БЭМ, и подобное.
Да, пожалуй я погорячился, без предпроцессоров css совсем плох на больших задачах. Но Бэм так же задачу не решает, он тащит за собой аналогичый инструментарий.
Ну как. БЭМ — это прежде всего модули для 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-препроцессоры.
Плюс БЭМ-а — легковесность. Фактически это просто 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-препроцессоры.
.block .element ничем не уступает block__element, а как вложенность растёт так и БЭМ преврашается в ужос. Чтобы прописывать это в шаблоны нужен ещё один предпроцессор или плагин как вы приводили для ангуляра. Чтобы эти классы запомнить и раставить нужны жирные мануалы. Плюс зачем-то выпячиваю наружу вроде детали оформления btn__color--grey. Никто не мешает без БЭМ договориться о правилах именования. Нормальный верстальщик затем практически любое оформление сделает не лазя в шаблоны, а только используя css+less.
БЭМ же не единственная методология, вроде мода с появлением препроцессоров на них прошла, а здесь яндекс выкатил свою погремушку с тяжёлым наслением от любви к xslt шаблонам. И школота потянулась на громкое имя, лепят свой БЭМ, а в реальности ляпают инлайн стили когда английские слова заканчиваются.
БЭМ же не единственная методология, вроде мода с появлением препроцессоров на них прошла, а здесь яндекс выкатил свою погремушку с тяжёлым наслением от любви к xslt шаблонам. И школота потянулась на громкое имя, лепят свой БЭМ, а в реальности ляпают инлайн стили когда английские слова заканчиваются.
.block .element уступает .block__element тем, что имя «element» становится занято. Т.е. имея ".header .icon" ты не можешь уже сделать просто ".icon".
В твоих рассуждениях неправильно одно — не всегда CSS пишет «нормальный верстальщик». Есть проекты где верстальщика нет совсем, а есть 20 человек разработчиков. И вот один пилит попап, который надо сдать вчера, и ему надо у кнопки добавить справа padding. И если ему не запретить делать .mypopup-footer-new .button.save { padding-right: 20px } — в CSS будет ад через месяц.
Если у тебя весь CSS делает один верстальщик — у тебя нет никаких таких проблем, которые решает БЭМ. Если он еще и хороший верстальщик — ему можно дать картинку, и пусть пишет CSS как ему хочется. Хоть по БЭМ, хоть каскадом, хоть инлайнами.
В твоих рассуждениях неправильно одно — не всегда CSS пишет «нормальный верстальщик». Есть проекты где верстальщика нет совсем, а есть 20 человек разработчиков. И вот один пилит попап, который надо сдать вчера, и ему надо у кнопки добавить справа padding. И если ему не запретить делать .mypopup-footer-new .button.save { padding-right: 20px } — в CSS будет ад через месяц.
Если у тебя весь CSS делает один верстальщик — у тебя нет никаких таких проблем, которые решает БЭМ. Если он еще и хороший верстальщик — ему можно дать картинку, и пусть пишет CSS как ему хочется. Хоть по БЭМ, хоть каскадом, хоть инлайнами.
Бум. Что-то мы друг друга не понимаем. Я как раз и говорю, что достаточно использовать вложенность стилей и они будут разнесены по нейспейсам, не пересекаясь. Нельзя делать глобальных классов. А вот
".block .element {}" и ".other-block .element {}" хотя и имеют совпадающий класс element, но они разные и стили не пересекаются. В тоже время, если их оформление совпадает, то можно использовать миксины, например
а в коде
а в случае BEM было бы что-то вроде block__element--color-red и block__element--color-blue, и в случае если нам подадобится поменять цвет, нужно править и стили и шаблоны.
".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, и в случае если нам подадобится поменять цвет, нужно править и стили и шаблоны.
Проблемы будут если у тебя где-то будет:
Т.е. кто-то использует имя для блока, совпадающее с именем элемента.
Но есть и другие проблемы. Блоки могут вкладываться. И например такое вот:
— будет уже зависеть от того, в каком порядке у тебя CSS склеился
.element {
font-family: "Comic Sans";
}
Т.е. кто-то использует имя для блока, совпадающее с именем элемента.
Но есть и другие проблемы. Блоки могут вкладываться. И например такое вот:
<div class="block">
<div class="element">Красный цвет</div>
<div class="other-block">
<div class="element">Синий цвет</div>
</div>
</div>
— будет уже зависеть от того, в каком порядке у тебя CSS склеился
По поводу первого кейса я писал
>>Нельзя делать глобальных классов.
БЭМ же тоже от такого не спасает, определит что-то стили для «div» и полчишь глобальные проблемы. Точно так же не спасет от каскадности, если есть правило для block, оно проникнет и в вложенные block__element.
Проблему вложенности решается через более стогие правила css вроде
.block > element {}
плюс можно использовать того же less и заинклудить в .block. element правила .other-block, тогда за счёт более весомых селекторов будут применяться нужные, плюс в качестве бонуса получим возможность стилизовать вложенные блоки.
Используешь ты БЭМ или нет, каскадность CSS у тебя остаётся и проблемы с ней те же.
>>Нельзя делать глобальных классов.
БЭМ же тоже от такого не спасает, определит что-то стили для «div» и полчишь глобальные проблемы. Точно так же не спасет от каскадности, если есть правило для block, оно проникнет и в вложенные block__element.
Проблему вложенности решается через более стогие правила css вроде
.block > element {}
плюс можно использовать того же less и заинклудить в .block. element правила .other-block, тогда за счёт более весомых селекторов будут применяться нужные, плюс в качестве бонуса получим возможность стилизовать вложенные блоки.
Используешь ты БЭМ или нет, каскадность CSS у тебя остаётся и проблемы с ней те же.
Ну как не спасает. По БЭМ как раз нельзя делать глобальные стили для div. И случайно сделать селекторы, которые проникают в чужие блоки — тоже не выйдет, только если сознательно нарушить правила.
Если решать проблему вложенности через более строгие селекторы — у тебя к CSS привязывается структура HTML. Что тоже неприятно. И там, вероятно, даже больше писать надо будет — особенно если элемент куда-то глубоко вложен.
Вообще, мне кажется что ты не против идеи изолировать CSS, тебе просто не нравится что классы получаются здоровенные. Но на практике, с тем же LESS и каким-нибудь angular-bem, оно будет как-то так:
и
Т.е. как по мне смысл БЭМ не в том, чтобы заставить бедных верстальщиков писать классы в пол страницы шириной. Смысл в том, чтобы простыми и относительно штатными средствами организовать себе в стилях модульность. И если нет возможности использовать тузлы, и надо писать на голом CSS — я вероятно выбрал бы code convention не заставляющие писать столько много букв. Но сам принцип БЭМ, по возможности, я бы оставил.
Если решать проблему вложенности через более строгие селекторы — у тебя к CSS привязывается структура HTML. Что тоже неприятно. И там, вероятно, даже больше писать надо будет — особенно если элемент куда-то глубоко вложен.
Вообще, мне кажется что ты не против идеи изолировать CSS, тебе просто не нравится что классы получаются здоровенные. Но на практике, с тем же LESS и каким-нибудь angular-bem, оно будет как-то так:
.message {
&--warning {
color: yellow;
}
}
и
<div block="message" mods="warning" />
Т.е. как по мне смысл БЭМ не в том, чтобы заставить бедных верстальщиков писать классы в пол страницы шириной. Смысл в том, чтобы простыми и относительно штатными средствами организовать себе в стилях модульность. И если нет возможности использовать тузлы, и надо писать на голом CSS — я вероятно выбрал бы code convention не заставляющие писать столько много букв. Но сам принцип БЭМ, по возможности, я бы оставил.
А вот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; }
Так ещё круче:
[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; }
[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; }
«Просто всё уже было»:
https://ru.bem.info/forum/-68/
https://ru.bem.info/forum/-68/
Никогда не разделял этого вашего стремления «минифицировать любой ценой» :-)
Повышая специфичность, вы лишаетесь возможности менять разметку и переносить блоки: delka.name/blog/2013/04/bem-otkroveniya-prinyavshih-veru
Я тоже раньше так писал, но таким блокам нужно создать (скопировать) контекст! Им нужно создать вокруг них, выше, те же самые блоки с такими же классами. Если тебе нужно перенести блок на другую страницу — тебе нужно создать такие же родительские блоки. Или нафигачить кучу бессистемных multiple classes :(
Я тоже раньше так писал, но таким блокам нужно создать (скопировать) контекст! Им нужно создать вокруг них, выше, те же самые блоки с такими же классами. Если тебе нужно перенести блок на другую страницу — тебе нужно создать такие же родительские блоки. Или нафигачить кучу бессистемных multiple classes :(
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
БЭМ — это 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.
Блок должен оставаться «черным ящиком», это главный принцип. Внутри — юзай что хочешь, это уже не суть важно.
Классический принцип «разделяй и властвуй», ничего более.
LESS и прочие препроцессоры — позволяют разнести код по файлам. Но сами по себе они ничего не делают для того, чтобы правила в этих файлах не влияли друг на друга.
БЭМ — это простые правила, которые гарантируют что селекторы из одного «модуля» не влияют на другие модули. И что единственный способ повлиять на селекторы внутри модуля — навесить модификаторы.
БЕМ и LESS — ортогональны. Мы используем и LESS, и БЭМ. Причем никто не запрещает пользоваться и другими инструментами инкапсуляции из LESS — всякими хелперами-миксинами, например. Главное принцип «модули не лезут внутрь друг к другу» соблюдать.
Например если есть .fancy-button, у которого внутри .fancy-button__label — не надо делать штуки типа ".my_panel .fancy-button__label { color: red }". Надо идти в fancy-button.css, и делать там модификатор fancy-button--important.
Блок должен оставаться «черным ящиком», это главный принцип. Внутри — юзай что хочешь, это уже не суть важно.
Классический принцип «разделяй и властвуй», ничего более.
Например если есть .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'.»
Я не очень понимаю миксы в БЭМ. Мне кажется они нарушают принципы, которые сам БЭМ и задает. Может быть они имеют смысл при верстке на чистом CSS, или в рамках тулчейна яндекса. Но тоже самое можно сделать миксинами CSS-препроцессора, и это будет более прямо и безопасно
Мы вообще используем БЭМ поверх React. У нас под каждый компонент есть блок в отдельном less-файле. И стили компонента может использовать только сам компонент. Единственный легальный способ поменять внешний компонента — передать ему другие props-ы. Как и какие модификаторы он вешает — его личное дело. В принципе, мы часто и inline-стили вешаем — например ширину колонки в таблице, там слишком много букв писать по классу каждой колонке.
Я думаю что это уже настоящий БЭМ, но идея та же — инкапсуляция компонентов.
Мы вообще используем БЭМ поверх React. У нас под каждый компонент есть блок в отдельном less-файле. И стили компонента может использовать только сам компонент. Единственный легальный способ поменять внешний компонента — передать ему другие props-ы. Как и какие модификаторы он вешает — его личное дело. В принципе, мы часто и inline-стили вешаем — например ширину колонки в таблице, там слишком много букв писать по классу каждой колонке.
Я думаю что это уже настоящий БЭМ, но идея та же — инкапсуляция компонентов.
БЭМ не противопоставляет себя семантической верстке.
БЭМ дополняет её, вносит ещё один уровень смысла (семантики) в документ.
Презентационная верстка: мы знаем что есть какая-то красная кнопка.
Семантическая верстка: мы знаем что это какая-то кнопка покупки товара.
Семантическая верстка + БЭМ: это кнопка оплаты в форме покупки со скидкой.
БЭМ дополняет её, вносит ещё один уровень смысла (семантики) в документ.
Презентационная верстка: мы знаем что есть какая-то красная кнопка.
<input class="big_red_button">
Семантическая верстка: мы знаем что это какая-то кнопка покупки товара.
<input class="order-button">
Семантическая верстка + БЭМ: это кнопка оплаты в форме покупки со скидкой.
<input class="order-button discount-checkout__submit">
И про то, кому БЭМ облегчает работу:
Например, если бы я попросил вас удалить все классы, относящиеся к пользователю, в этом куске кода, какие бы вы выбросили?
…а в этом?
Например, если бы я попросил вас удалить все классы, относящиеся к пользователю, в этом куске кода, какие бы вы выбросили?
<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>
Любая практическая методология, предполагает некий алгоритм успеха. Иными словами, если в заданных условиях делать все согласно методологии, то желаемый результат будет достигнут. В этом их польза методологий.
Многие покупаются на БЭМ-методологию в расчете, дескать, вот щаз как внедрим и все станет «зашибись», как Яндексе. Проблемы возникают из-за того, что многие так же забывают, что как и любая практическая методология, БЭМ имеет свою конкретную область применения — мало кто понимает насколько все «зашибись» в Яндексе, почему так, как устроена разработка и какова роль в этом БЭМ.
Эффективность решения задач повышается за счет использования подходящих технологий, накопления опыта, повторного использования кода и автоматизации. Методологии же нужны, чтобы создавать технологии. В Яндексе примерно так все и устроено: одни люди занимаются разработкой технологий следуя БЭМ и прочим методологиям — кодят инструментарий, компоненты, пишут документацию, рассказывают на конференциях как все круто, другие — решают с помощью них практические задачи.
Если вы не Яндекс, то у вас наверняка совершенно другие исходные условия, и и поэтому БЭМ-методология работать не будет. Но такой вывод следует из определения, поэтому является банальным и ни кому не интересным.
Многие покупаются на БЭМ-методологию в расчете, дескать, вот щаз как внедрим и все станет «зашибись», как Яндексе. Проблемы возникают из-за того, что многие так же забывают, что как и любая практическая методология, БЭМ имеет свою конкретную область применения — мало кто понимает насколько все «зашибись» в Яндексе, почему так, как устроена разработка и какова роль в этом БЭМ.
Эффективность решения задач повышается за счет использования подходящих технологий, накопления опыта, повторного использования кода и автоматизации. Методологии же нужны, чтобы создавать технологии. В Яндексе примерно так все и устроено: одни люди занимаются разработкой технологий следуя БЭМ и прочим методологиям — кодят инструментарий, компоненты, пишут документацию, рассказывают на конференциях как все круто, другие — решают с помощью них практические задачи.
Если вы не Яндекс, то у вас наверняка совершенно другие исходные условия, и и поэтому БЭМ-методология работать не будет. Но такой вывод следует из определения, поэтому является банальным и ни кому не интересным.
Приведу такой неслучайный список сайтов, сверстанных по БЭМ:
http://www.microsoft.com/ru-ru/azure/wizard/
http://mymail.my.com/ru/
http://sheben96.ru/
http://smartpack.pro/
Они ведь ничего общего с Яндексом не имеют. Скажите, почему БЭМ-методология для них сработала?
http://www.microsoft.com/ru-ru/azure/wizard/
http://mymail.my.com/ru/
http://sheben96.ru/
http://smartpack.pro/
Они ведь ничего общего с Яндексом не имеют. Скажите, почему БЭМ-методология для них сработала?
Отличные примеры, хочешь показать что такое плохой БЭМ, покажи их.
первый вовсе надстройка над bootstrap с его глобальными b-btn b-btn_green b-btn_block, ну и масса прочей лапши
второй получше, но це ужос footer-nav-list__foo dropdown__menu__item
два последних проекта вовсе напичканы инлайн стилями.
первый вовсе надстройка над bootstrap с его глобальными b-btn b-btn_green b-btn_block, ну и масса прочей лапши
второй получше, но це ужос footer-nav-list__foo dropdown__menu__item
два последних проекта вовсе напичканы инлайн стилями.
Если уж все люди на планете знакомы друг с другом через шесть рукопожатий максимум, то в рамках отдельно взятого города что-то общее с Яндексом имеют, наверное, через одного. По-видимому, кому-то очень хотелось чтобы так случилось.
Терпеть не могу БЭМ, но, к сожалению, не могу упрекнуть данный подход в том, что от него нет практической пользы. БЭМ инструмент созданный для вполне конкретной цели — независимая стилизация различных компонентов страницы. Иначе говоря, для того, чтобы сверстанный компонент отображался адекватно независимо от того, на какую страницу портала (или какого-либо внешнего ресурса), и в какую их областей этой страницы ты бы его не пихнул. БЭМ справляется с этой задачей.
Ругать или хвалить в БЭМе можно только средства которыми это было достигнуто. В данном случае это уход от классической методологии использования каскада в «каскадных таблицах стилей». С учетом того, что в исходниках css'а (sass, less и тд) каскадность никуда не девается, то проблема не такая уж и серьезная.
Проблемой же в БЭМе я считаю то, что при применении данного подхода, верстка становится делом слишком «машинным», теряется семантика элементов страницы. В случае огромных функционально связанных между собой порталов с разными командами разработчиков данных подход полностью оправдан, это тот случай когда много думать вредно. Другое дело, что редко кому приходится разрабатывать нечто настолько огромное.
В остальных же случаях достаточно более «мягких» методологий. Лично я предпочитаю smacss, так как на мой взгляд он не портит семантику и действительно позволяет масштабировать проект. Да, думать приходится много, но оно того стоит.
ЗЫ: Ну и… мне не нравятся стандартные рекомендации по именованию классов в БЭМ. Все эти "__" и "--" довольно омерзительны=)
Ругать или хвалить в БЭМе можно только средства которыми это было достигнуто. В данном случае это уход от классической методологии использования каскада в «каскадных таблицах стилей». С учетом того, что в исходниках css'а (sass, less и тд) каскадность никуда не девается, то проблема не такая уж и серьезная.
Проблемой же в БЭМе я считаю то, что при применении данного подхода, верстка становится делом слишком «машинным», теряется семантика элементов страницы. В случае огромных функционально связанных между собой порталов с разными командами разработчиков данных подход полностью оправдан, это тот случай когда много думать вредно. Другое дело, что редко кому приходится разрабатывать нечто настолько огромное.
В остальных же случаях достаточно более «мягких» методологий. Лично я предпочитаю smacss, так как на мой взгляд он не портит семантику и действительно позволяет масштабировать проект. Да, думать приходится много, но оно того стоит.
ЗЫ: Ну и… мне не нравятся стандартные рекомендации по именованию классов в БЭМ. Все эти "__" и "--" довольно омерзительны=)
Раскройте, пожалуйста, мысль — как именно БЭМ портит семантику?
Разберу приведенный выше пример
Из приведенного только 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 это его значение, в этом и есть семантическая проблема, этот класс говорит не о смысле элемента, а о его отображении)
- 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 это его значение, в этом и есть семантическая проблема, этот класс говорит не о смысле элемента, а о его отображении)
Как раз в этих классах семантики (смысла) сильно больше, чем в голых a, span и прочих div.
Про link_size_small:
То, как именованы конкретные переменные — не проблема методологии, а проблема конкретного именующего.
Про link_size_small:
There are only two hard things in computer science: cache invalidation and naming things.
То, как именованы конкретные переменные — не проблема методологии, а проблема конкретного именующего.
То, как именованы конкретные переменные — не проблема методологии, а проблема конкретного именующего.
Проблема правильного имени класса есть только в «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;
// что-то еще
}
А это уже не совсем классический подход к БЭМ-модификаторам
Нет, 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).
В этом примере menu-list__link это ссылка внутри блока menu-list и она смешивается с full-article-link. Блок menu-list это какое-то меню, которое ничего не знает, что в него вкладывают, его семантика — быть меню и показывать всё, что в него положат.
Ну и secondary лучше задавать для full-article-link: .full-article-link_secondary (хотя предполагаю, что абстрактное меню может иметь в себе ссылки разных размеров (оставим за скобками зачем это нужно) и _size_small указывает как раз на это, что может быть ещё normal).
Если вы заявляете, что «Класс 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 — цену товара.
Вы упускаете важный момент: БЭМ про компоненты (примерно как 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 — цену товара.
Не люблю отвечать на отдельные части комментариев (обычно это приводит только к разрастанию холивара), поэтому постараюсь кратко и по существу.
Почти готов согласится с Вами по поводу наличия семантики в классе menu-list__link, если в данном случае действительно имеется ввиду ссылка элемента меню. Снова спишем на неудачное имя класса и предположим что на самом деле имеется ввиду menu-list__menu-item-link. Но хотел бы заметить что далеко не факт что имелось ввиду именно это, к примеру могла бы быть примерно такая структура DOM:
По поводу абстракций… Мне как раз то чего всегда хочется избежать их на итоговой странице, ИМХО, абстракциям место только в исходниках, в своих проектах я с этой задачей справляюсь.
Честно говоря не понимаю о чем мы сейчас спорим, я согласен с тем что БЭМ выполняет свою задачу, я лишь говорю о том, что классический подход к применению данной методологии имеет свою цену, а неклассический подход идентичен по результату тому же smacss (отличие будет только в наличии в стилях " > ." вместо "__" и в количестве классов у элементов).
Почти готов согласится с Вами по поводу наличия семантики в классе 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 (отличие будет только в наличии в стилях " > ." вместо "__" и в количестве классов у элементов).
Я время от времени слышу, что Яндекс агрессивно продвигает БЭМ. В частности об этом сказал автор поста, zapolnoch и AmdY.
Расскажите, пожалуйста, что вы понимаете под агрессивным продвижением?
Я слежу за этой темой и за последний год слышал про пару докладов на яндексовых же Субботниках, еще пару на других конференциях от яндексоидов и, наверное, пяток докладов от людей не из Яндекса, пару статей на Хабре и, вроде, всё. Зато последнее время про БЭМ регулярно пишут западные разработчики: https://www.google.com/search?q=bem+methodology&lr=lang_en
Расскажите, пожалуйста, что вы понимаете под агрессивным продвижением?
Я слежу за этой темой и за последний год слышал про пару докладов на яндексовых же Субботниках, еще пару на других конференциях от яндексоидов и, наверное, пяток докладов от людей не из Яндекса, пару статей на Хабре и, вроде, всё. Зато последнее время про БЭМ регулярно пишут западные разработчики: https://www.google.com/search?q=bem+methodology&lr=lang_en
Создается ощущение, что БЭМ в версте стал сродни MVC в программировании, в том смысле, что каждый находит его во всем, что видит, но понимает по-своему. Когда я читаю github.com/google/material-design-lite/wiki/Understanding-BEM, в душу начинает закрадываться сомнение, что это тот же БЭМ, который у Яндекса.
Загляните в исходники mdl (какой-нибудь кнопки например, github.com/google/material-design-lite/blob/master/src/button/_button.scss). Они спокойно используют каскады между b-e-m в любых комбинациях, переопределяют стили других «блоков». По сути, это обычный CSS, как в boostrap, foundation и т.п., только с необыкновенно длинющими названиями классов.
Загляните в исходники bem-components: https://github.com/bem/bem-components/blob/v2/design/common.blocks/button/_theme/button_theme_islands.styl
Мы спокойно используем каскады и переопределяем стили других блоков, когда это обосновано.
Загляните, наконец, в описание методологии: https://ru.bem.info/faq/#Почему-нежелательно-использовать-вложенные-селекторы
Там явно написано, почему БЭМ не рекомендует вложенные селекторы и приводятся примеры, когда это оправдано.
В душу начинает закрадываться сомнение, что в Яндексе тот же БЭМ, который рисуют в своем воображении благодарные пользователи ;)
Мы спокойно используем каскады и переопределяем стили других блоков, когда это обосновано.
Загляните, наконец, в описание методологии: https://ru.bem.info/faq/#Почему-нежелательно-использовать-вложенные-селекторы
Там явно написано, почему БЭМ не рекомендует вложенные селекторы и приводятся примеры, когда это оправдано.
В душу начинает закрадываться сомнение, что в Яндексе тот же БЭМ, который рисуют в своем воображении благодарные пользователи ;)
Судя по написанному — ровно тот же.
НЛО прилетело и опубликовало эту надпись здесь
Так все-таки, какие проблемы возникают на этом обычном сайте с одним единственным шаблоном из-за подчеркиваний?
А то столько придурков убеждены, что БЭМ — норм (http://webstandardsdays.ru/2014/05/24/pres/bem-ok)…
А то столько придурков убеждены, что БЭМ — норм (http://webstandardsdays.ru/2014/05/24/pres/bem-ok)…
НЛО прилетело и опубликовало эту надпись здесь
«хум хау»
Мне использование БЭМ позволяет всё разложить по компонентам и иметь реализацию каждого компонента в одном месте:
https://github.com/vithar/bem.info/tree/master/common.blocks
Ну и что тут трудночитаемого?
https://github.com/vithar/bem.info/blob/master/common.blocks/nav/nav.css
Мне использование БЭМ позволяет всё разложить по компонентам и иметь реализацию каждого компонента в одном месте:
https://github.com/vithar/bem.info/tree/master/common.blocks
Ну и что тут трудночитаемого?
https://github.com/vithar/bem.info/blob/master/common.blocks/nav/nav.css
Про придурки и глупо я услышал. А вот какие проблемы возникнут на этом злополучном сайте, где кот наплакал и не планируется масштабируемости — нет. Расскажите?
Каскад был совершенно логичен на момент своего изобретения.
Сегодня же, когда веб-страницы и (о, ужас) веб-приложения условжнились на пару порядков — он показал своё несовершенство во всей красе.
Нет, я конечно же, не предлагаю отказаться от него совсем — в умеренных количествах он нужен.
Но решить полностью все задачи, стоящие перед верстальщиком в 2010-х годах он не в состоянии, это инфа 146%.
Конечно, в идеальном мире было бы намного круче, если бы на нас свалился некий более современный вариант CSS с обновленной архитектурой и устраненными недостатками. Но, как все мы понимаем, этого не случится ещё долго. В этом смысла да, БЭМ — отчасти костыль. Но это лучшее из имеющегося.
Сегодня же, когда веб-страницы и (о, ужас) веб-приложения условжнились на пару порядков — он показал своё несовершенство во всей красе.
Нет, я конечно же, не предлагаю отказаться от него совсем — в умеренных количествах он нужен.
Но решить полностью все задачи, стоящие перед верстальщиком в 2010-х годах он не в состоянии, это инфа 146%.
Конечно, в идеальном мире было бы намного круче, если бы на нас свалился некий более современный вариант CSS с обновленной архитектурой и устраненными недостатками. Но, как все мы понимаем, этого не случится ещё долго. В этом смысла да, БЭМ — отчасти костыль. Но это лучшее из имеющегося.
Посмотрите, например, на bemto. Это не круто, это просто удобно, понятно и совсем не сложно.
А многие ли, сочиняя аббревиатуру DHTML, думали о JS как языке серверной и тем более десктопной разработки?
И, да, каскад — это одна из букв в аббревиатуре CSS.
А многие ли, сочиняя аббревиатуру DHTML, думали о JS как языке серверной и тем более десктопной разработки?
А вот еще на что можно посмотреть. https://github.com/rajdee/posthtml-bem инструмент еще проще. И можно использовать с любым шаблонизатором
НЛО прилетело и опубликовало эту надпись здесь
Как-то, сильно уж противоречиво написали. Никто никого не заставляет, скорее рекомендуем. Кстати ваше корпоративная wiki и то, что сложилось в голове, ничем не лучше и не хуже что вам предлагают.
Да зачем мне на что-то смотреть? В моей предметной области в ближайшие несколько лет даже не предвидится проектов, которым нужны сборщики, модные шаблонизаторы и прочее…
Как минимум для того, чтобы знать, от чего отказываетесь. Вдруг понравится?
А код, картинки и прочее руками сжимаете? И все-все стили в одном файле?
Я же не ору на каждом углу что так, как я должен работать каждый, и как-то по-другому — это лажа и отстой.
Да я как бы тоже. Вообще, у меня сложилось впечатление, что вы пишете только «голый» HTML/CSS. Если так удобнее — что ж, каждому свое, но присмотреться к прогрессу никогда не вредно.
А если проекта на конкретной машине нет и работаешь из дома, а форму кровь из носа надо сверстать девочке до понедельника, потому что у нее KPI и всё такое?
А в чем проблема иметь все на домашней машине? Если же есть только чужая машина, то вряд ли вы будете в блокноте верстать. Скорее зайдете на тот же codepen, который уже даже PostCSS поддерживает — то есть там даже компилировать ничего не придется.
НЛО прилетело и опубликовало эту надпись здесь
Это как раз не люди пишут, а роботы. Люди пишут что-то вроде такого, если говорить конкретно о Яндексе.
НЛО прилетело и опубликовало эту надпись здесь
Вообще статья явный наброс на вентилятор, но отвечу на некоторые замечания на правах соавтора БЭМ (вместе с veged).
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 — соответствует БЭМ нотации.
Советую почитать описание методологии, мы его недавно переписали, на наш взгляд стало понятнее:
https://ru.bem.info/method/definitions/
Если есть вопросы — приходите на форум, обсудим/ответим/поможем:
https://ru.bem.info/forum/
Если сверстать страничку таблицами, как это было во времена 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/
А чем БЕМ лучше чем — github.com/rstacruz/rscss?
НЛО прилетело и опубликовало эту надпись здесь
Знаете, что я скажу вам, господа? Мир фронтенда — бегун на костылях в принципе, но бегун быстрый. У нас особая ситуация — наши программы выполняются в браузерах, возможности которых ограничены, конкретные браузеры выпускаются разными, никак не связанными командами, а версии обновляются неравномерно.
HTML изначально был предназначен для статей, связанных гиперссылками, но разработчики и пользователи захотели красивых страничек, и начали использовать таблицы для позиционирования и всякие атрибуты для украшательств. Это костыль или чистейший гений архитектуры? Конечно, костыль — таблица же для данных, а не для верстки страниц.
Версии обновляются медленно, а мы хотим новых возможностей JS или писать для браузера на совершенно другом языке. Появляются полифиллы, транспайлеры и компиляторы в JS. Так что же, разве не костылями являются Babel или TypeScript? Да конечно костылями — это же надо, компилировать высокоуровневый язык в JavaScript! А кое-кто ведь и низкоуровневые компилирует! Это вынужденная мера, но путем таких костылей мы получаем огромные возможности.
Так же, поскольку у нас нет иного выбора, кроме CSS, а возможности его ограничены, приходится на этих ограниченных возможностях строить методологии, которые оградят разработчиков от стрельбы по ногам и облегчают масштабируемость и поддерживаемость кода. Отсюда и появились БЭМ и другие его братья. Да, они ограничивают некоторые возможности CSS и привносят некоторые правила, которые можно назвать костылями с точки зрения академической архитектуры. К примеру, селекторы в БЭМ — классический пример борьбы с коллизиями при использовании глобальных переменных. Но это не от хорошей жизни — в современном CSS нет других возможностей создавать пространства имен.
Но что делать, отказаться от любых хаков, лишь бы не вылезать из калеи, в которую нас загоняют веб-технологии в чистом виде? Конечно нет, если бы мы так делали — веб не пришел бы туда, куда пришел.
Веб — богатейшая почва для набросов, можно сорвать покровы с любой актуальной технологии и методологии и потешить тем самым самолюбие, но стоит ли этим заниматься? Может быть, лучше было бы разработать достойную альтернативу или пойти и заняться улучшением какой-нибудь из текущих? Может быть, оно само по себе и не взлетит и не станет лучше, но свежая идея — тоже очень важная в мире веба штука.
HTML изначально был предназначен для статей, связанных гиперссылками, но разработчики и пользователи захотели красивых страничек, и начали использовать таблицы для позиционирования и всякие атрибуты для украшательств. Это костыль или чистейший гений архитектуры? Конечно, костыль — таблица же для данных, а не для верстки страниц.
Версии обновляются медленно, а мы хотим новых возможностей JS или писать для браузера на совершенно другом языке. Появляются полифиллы, транспайлеры и компиляторы в JS. Так что же, разве не костылями являются Babel или TypeScript? Да конечно костылями — это же надо, компилировать высокоуровневый язык в JavaScript! А кое-кто ведь и низкоуровневые компилирует! Это вынужденная мера, но путем таких костылей мы получаем огромные возможности.
Так же, поскольку у нас нет иного выбора, кроме CSS, а возможности его ограничены, приходится на этих ограниченных возможностях строить методологии, которые оградят разработчиков от стрельбы по ногам и облегчают масштабируемость и поддерживаемость кода. Отсюда и появились БЭМ и другие его братья. Да, они ограничивают некоторые возможности CSS и привносят некоторые правила, которые можно назвать костылями с точки зрения академической архитектуры. К примеру, селекторы в БЭМ — классический пример борьбы с коллизиями при использовании глобальных переменных. Но это не от хорошей жизни — в современном CSS нет других возможностей создавать пространства имен.
Но что делать, отказаться от любых хаков, лишь бы не вылезать из калеи, в которую нас загоняют веб-технологии в чистом виде? Конечно нет, если бы мы так делали — веб не пришел бы туда, куда пришел.
Веб — богатейшая почва для набросов, можно сорвать покровы с любой актуальной технологии и методологии и потешить тем самым самолюбие, но стоит ли этим заниматься? Может быть, лучше было бы разработать достойную альтернативу или пойти и заняться улучшением какой-нибудь из текущих? Может быть, оно само по себе и не взлетит и не станет лучше, но свежая идея — тоже очень важная в мире веба штука.
Резюмирую сказанное в комментариях:
Как правильно сказали в одном из комментариев, нет идеальной технологии для всех задач.
Картинка
Как правильно сказали в одном из комментариев, нет идеальной технологии для всех задач.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
БЭМ — методология развешивания костылей