Комментарий

[SilentImp]

Бем — дитя яндекс. Он хорош для больших проектов и не нужен для малых. Как вы думаете?

[mistakster]

Оригинальный синтаксис .block__element_mod-type_mod-value мне нравится больше. Знаки подчёркивания хорошо выглядят. Их проблема только в выделении по даблклику на слове. Я не видел ни одного редактора или IDE, который бы правильно установил выделения.

Поделюсь ссылкой ещё на одну статью про вёрстку независимыми блоками. БЭМ — это совсем не страшно. Да, больше букв, но зато меньше проблем с обслуживанием.

Кстати, в таких статьях, чаще всего, вообще не затрагивается вопрос БЭМ-ификации пользовательского контента. Мне нравится, когда и контент, написанный пользователем, оформляется с помощью простых селекторов. Тут без автоматических фильтров не обойтись. Но это совсем не проблема, я считаю. После WYSIWYG-редакторов разметку всё равно нужно валидировать. Markdown, Wiki, BBCode и другие разметки и так проходят пост-обработку. В этот цикл можно встроить добавление простых селекторов тегам. И нейминг у них можно организовать в стиле БЭМ.

[omgovich]

Допустимо ли использование подобных селекторов: «.person--female__hand»? Я не встречал ни в одной статье про концепцию незвисимых блоков. На сколько я знаю используются подобные каскадные конструкции: «.person--female .person__hand»

[omgovich]

P.S. Отдельное спасибо вашему редактору разметки у комментариев, который хотел превратить двойное подчеркивание в начало полужирного текста, но потом передумал.

[SilentImp]

Мои извинения. Разные интерпретаторы разметки на сервере и клиенте. Исправим и сведем поведение к единообразному.

[Yvelious]

Оригинальная BEM-методология нравится больше. Насколько я помню, модификатор не может отдельно существовать от модифицируемого блока или элемента. А в этих примерах может class="media__img--rev".

[rohozhnikoff]

Тогда это не модификатор. Это абстрактный класс (g-, i- префиксы в БЭМе).

[tadatuta]

У оригинального формата модификаторов есть несколько плюсов:

1. Можно выразить модификаторы в терминах что модифицируем и в какое значение. Скажем, у нас есть логотип, который бывает разных размеров и с разной темой (новогодний, к 8 марта и т.д.): logo_size_big, logo_size_small и logo_theme_new-year, logo_theme_8march.
2. Модификаторы можно передать с помощью xml или json (например, и { block: 'blockName', mods: { modName: 'modVal' }}).
3. Отсюда вытекает и дополнительное удобство при работе с модификаторами из js: мы можем получить текущее значение нужного модификатора вместо того, чтобы проверять начилие из списка (да и не всегда этот список есть заранее).
4. При разнесении файлов по файловой системе, разные значения одного и того же модификатора удобно класть в общую папку.
5. Если когда-нибудь вы захотите применить у себя на проекте bem tools (http://ru.bem.info/tools/bem/), такая нотация будет работать из коробки.

[LostSenSS]

mistakster, да с выделением в редакторах проблема :/ Вебшторм, например, разбивает слово по дефисам.

Omgovich, Yvelious, да, тоже очень удивили эти моменты. Противоречат же самой сути системы.

[MrFranke]

А если добавить немного LESS-a в эту систему, то писать стили будет очень удобно:

.header{
&__logo{}
}

[jmas]

Сам метод БЭМ достаточно противоречив.

Авторы, которые восхваляют данный стиль именования CSS классов зачастую оперируют такими абстрактными понятиями, как изящный, прозрачный и так далее. Понять какой код изящней, а какой нет - пожалуй можно только увидев код, на порядок изящней текущего. И что я скажу: мне кажется, что код записанный традиционными классами + оперируя традиционным наследованием выглядит гораздо изящней, чем код написанный с применением БЭМ.

Конечно же это мое субъективное мнение.

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

Хорошо, но это не проблема лежит не в плоскости классов - это проблема лежит в плоскости понимания программистом контекста.

Да и допустим, чем не понятна следующая конструкция:

.person .hand {}

.person .female{}

.person .female-hand{}

.person .left-hand{}

Собственно главный аргумент, что обычный CSS не передает контекст - здесь просто не уместен.

Я склоняюсь к использованию lessCss, который призван решать подобные проблемы, а не пробовать заставить программистов тащить контекст в каждом селекторе.

[kizu]

@jmas БЭМ решает в том числе (или, может, и в первую очередь) и проблему независимости стилей — если вложить руку мужчины в руку женщины, то при написании стилей каскадом обе руки станут женскими — так как и к мужской руке применятся соответствующие стили.

[jmas]

<div class="a">
<div class="b"></div>
</div>

<div class="c">
<div class="b"></div>
</div>

.a .b { }
.c .b { }

<div class="a">
<div class="b of-a"></div>
<div class="c">
<div class="b of-c"></div>
</div>
</div>

.a .b.of-a { }
.c .b.of-c { }

Почему нельзя разруливать таким образом?

[tadatuta]

@jmas еще важный момент — БЭМ не только про CSS, он весь проект целиком: js, шаблоны и даже серверный код.

[jmas]

@tadatuta Я готов поддержать дискуссию, так как хочу вывести истину. Привязываться к классам в JS? А как насчет привязки к [data-param], так мы вообще избавляемся в JS от CSS-зависимостей.

Насчет шаблонов ничего не слышал - подскажите в чем суть.

[kizu]

Почему нельзя разруливать таким образом?

Потому что в этом случае вы и получаете лишние классы, только вместо одного длинного вы получаете два класса: и короткий и длинный :)

БЭМ рассчитан на высокую поддерживаемость стилей, проименовав класс один раз в последствии не нужно будет ни править html, ни править css для того, чтобы вложить один блок в другой.