Комментарий

[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 для того, чтобы вложить один блок в другой.

[jmas]

@kizu Хорошо, что мешает изначально писать:

<div class="something-list">
<div class="item of-something"></div>
</div>

Подчеркиваю, изначально.

Я понял, что суть БЭМ - просто заставить людей писать изначально длинные имена, описывающие контекст, но сама запись получается совсем не-элегантная, ИМХО.

[tadatuta]

@jmas Немного из рубрики «Срываем покровы». На самом деле БЭМ полне может обходится вообще без классов. Например, опираясь на кастомные теги.
Основные идеи БЭМа в том, что:

1. Блоки не зависят друг от друга
2. Блоки реализуют некую объектную модель, а-ля ООП, с наследованием, миксинами, до- и переопределением свойств (эти свойства блоков проявляются консистентно как для css, так и для js, шаблонов и серверного кода)
3. Блоки первичны, технологии вторичны (css, js, шаблоны, документация, картинки и пр. лежат в одной папке, при реиспользовании блока не нужно собирать его потраха по всей файловой системе)
4. Реализация блоков в любой технологии позволяет общаться в общих терминах. js-разработчик, говоря о блоке my-awesome-block будет говорить именно о том самом блоке, о котором знает и верстальщик и бекендер

Про шаблоны в БЭМ-терминах можно подробно прочитать тут: http://ru.bem.info/articles/bemhtml-rationale/

[kizu]

@jmas Во-первых, я не вижу чем item of-something элегантнее something__item. Если же эта сущность может существовать и без something, то это должен быть блок, но если эта часть каким-то образом модифицируется от something, то железобетоннее смиксовать это дело так: item something__item.

Мультиклассы типа .b.of-c имеют несколько проблем:

1. Не работают в IE6, но это не существенно для большинства сайтов, конечно же.
2. В нормальных браузерах работают медленнее, чем селектор по одному классу, это не так существенно для маленьких сайтов, но всё же.
3. Самое главное — это мешает миксованию. Что, если мы захотим сделать один блок-микс из a и c, а элементом будет микс из b и d? Тут без явного прописывания зависимости конкретного элемента от конкретного блока не получится. Я сходу сейчас конкретный пример такого конфликта не приведу, но на моей практике подобные случаи были частенько.

[jmas]

Да, я понимаю, что на больших проектах часто люди бывают с различным уровнем, и как мне кажется БЭМ появился именно как что то помогающее привести весь общий опыт под один знаменатель. Так сказать чтобы и браузеры работали, блоки не конфликтовали, и люди понимали.

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

Не подскажите почему было принято взваливать проблему на плечи программистов (верстальщиков) (учить дополнительный синтаксис, отслеживать зависимости, прописывать контекст), а не на плечи программе (программа самостоятельно разруливала и перегоняла в БЭМ-синтаксис определенные блоки)?

[kizu]

Less и ему подобные не решают эту проблему (хотя я бы тут поспорил с тем, что это проблема — написание длинных классов может быть упрощено тысячей способов, начиная от фильтра в Emmet, который там есть из коробки, заканчивая любыми кастомными рещениями).

Независимые компоненты будут в любом случае перекликаться, потому надо в имя элемента закладывать имя блока.

Использование вложенности для препроцессоров часто добавляют лишних проблем — как с читаемостью кода, так и с его нахождением. Частично эту проблему решают source maps, но не целиком (поиском и грепом сложнее будет найти нужный селектор).

Ещё раз: я не вижу проблемы в длинных именах классов и даже работая над промо-страницами и «домашними сайтами для котиков» я всегда видел только плюсы от БЭМ-нотации и АНБ-подхода. Все отступления от них сразу же вызывали те или иные проблемы с поддержкой. Да, они могут быть незначительны, вроде переименования классов или изменения структуры CSS, но они будут. К длинным классам легко привыкнуть, при этом если не нравятся конкретный синтаксис, то его легко подогнать под себя — хотя использовать кемелкейс для названий блоков, а элементы писать через дефис, это не важно.

[slaffko1]

Я так понимаю использование препроцессоров при с БЭМ теряет эффективность. Т.е. нельзя использовать вложенные классы

[iamstarkov]

Суть препроцессоров не в вложенных селекторах, а в облегчении рутины и тут они выполняют свою миссию вполне хорошо, и также они вполне отлично уживаются с БЭМ.

PS. Каскад не следует использовать безотносительно БЭМ и препроцессоров в любом случае

[panych]

Почему нельзя использовать data атрибуты для модификаторов: <h1 class="title" data-color="grey">? Есть же доступ как из js, так из css.

[iamstarkov]

кто сказал, что нельзя? можно.

почему это не предложено в концепции, это уже другая история, имеющая некоторые причины:

1. на момент создания методологии не существовало дата-аттрибутов;
2. селектор дата-аттрибута вкупе с исходным классом (.block__elem[data-modName=modVal]) приведут к большей специфичности чем селектор по одному классу-модификатору (.block__elem_modName_modVal), что может вызвать проблемы.

[Yvelious]

А что там со скоростью рендеринга дата-атрибутов относительно классов?

[MrFranke]

Не думаю это самая актуальная проблема для современных браузеров.

18 декабря 2013 г., 14:22 пользователь Stas Levyshev <
[email protected]> написал:

А что там со скоростью рендеринга дата-атрибутов относительно классов?

Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-30830675
.

Отправлено с Dendy

[panych]

@matmuchrapna вторая причина не критична: обычно модификатор и так должен перекрывать дефолтные стили. Зато доступ в js из коробки есть (jQuery тут помогает). Пока вижу только плюсы.

[iamstarkov]

обычно модификатор и так должен перекрывать дефолтные стили

всё верно, покуда у тебя не возникнет потребность перекрыть модификатор селектором из одного класса на другом уровне переопределения. Допустим, ты подключил библиотеку блоков со всеми их модификаторами в начало таблицы стилей, а затем хочешь переопределить этот блок на какой-то определённой странице — в этом случае ты не сможешь использовать в переопределении селектор из одного класса, так как специфичность селектора модификаторов будет ставить тебе палки в колёса.

В итоге, специфичность — зло и предложенная модель для модификаторов это бомба замедленного действия для самого себя

[panych]

В голову пока пришло два примера:

1. <button class="btn">Click me! <i class="btn__ic lib-ic" data-icon="info"></i></button>

Здесь вроде все не так плохо. Все, что будет в .lib-ic[data-icon="info"] в теории не должно пересекаться с .btn__ic.
1.

<div class="gal">
  <div class="gal__col lib-col" data-pos="left"></div>
  <div class="gal__col lib-col" data-pos="right"></div>
</div>

Тут уже в разы хуже: скорее всего нужно будет перекрывать стили.

Так же всплыла другая проблема - конфликт модификаторов. Непонятно к какому блоку отноститься data-pos. Можно, конечно, писать как-то так: data-lib-col-pos, но тогда выигрыша сравнительно "классической" записи почти нет.

Еще одна проблема с этим подходом - меньшая производительность селекторов.

[iamstarkov]

Здесь вроде все не так плохо. Все, что будет в .lib-ic[data-icon="info"] в теории не должно пересекаться с .btn__ic.

увеличилась специфичность — что-нибудь взорвётся

а второй аргумент я не понял

[iamstarkov]

Зато доступ в js из коробки есть (jQuery тут помогает). Пока вижу только плюсы.

Попробуй i-bem, ещё захочешь =)

[nikbelikov]

Поставьте, пожалуйста, точку в конце предложения.
"но если для этого есть веская причина, то стоит все взвесить, прежде чем от него отказываться"

[OlegZavrazhin]

Удобство БЭМ (на русский манер) очевидно. Но есть вопрос, именно в контексте данного решения: может ли блок содержать в себе другие блоки, но относящиеся к своему родительскому? Если да, так им присваивать названия?

[mistakster]

Блоки, в общем случае, должны быть независимыми. Их названия выбираются исключительно исходя логической структуры.

Например, есть список.

<ul class="products">
  <li class="products__item">
    <div class="product">...</div>
  </li>
</ul>

Элементы, которые относятся к блоку products, задают расположение блоков product, но не их оформление. Так товары могут в одном месте располагаться плитками, в другом — в одну колонку. А вот само оформление товара уже описывается в product. Прелесть БЭМ в том, что я могу блок поместить куда угодно (в разумных пределах, конечно) и он не должен ломаться от этого.

Я не исключаю вариант, когда products__item и product можно разместить на одном DOM-узле. Сам так делаю регулярно. Но, как показывает практика, удобнее в поддержке оказываются решения, где элементы и блоки разнесены по разным DOM-узлам. Мы в компании начали активно использовать CSS-свойство all: initial для обнуления стилей блока. Из-за этого, совместное использование становится очень затруднительным — блок обнуляет стили элемента, приходится поднимать специфичность селектора элемента и т.п.

[OlegZavrazhin]

Я немного не так выразился наверное, сейчас на примере.

<header class="header">
  <div class="header-top">
    <div class="header-top__logo"></div>
    <ul class="header-top__menu"></ul>
  </div>
  <div class="header-bottom">
    <div class="header-bottom__phone"></div>
    <ul class="header-bottom__menu"></ul>
  </div>
</header>

Вот header-top и header-bottom - это блоки внутри блока или элементы этого блока?

[mistakster]

Чтобы ответить на этот вопрос, нужно ещё посмотреть на дизайн. Скорее всего, блоки уже не будут повторяться на странице. Поэтому можно их разметить как элементы. А вот менюшки явно просятся быть блоками.

[panych]

Вот header-top и header-bottom - это блоки внутри блока или элементы этого блока?

По вашей записи получается, что отдельные блоки.

В данном примере, чтобы не плодить лишние сущности, я все привязывал бы к хедеру. А менюшки, действительно, если сложны, то для удобства делаются отдельными блоками.

// jade
header.header
  div.header__top
    div.header__logo
    div.header__top-menu
      ul.top-menu // или ul.header-top-menu если хочется логически привязать к хедеру

  div.header__bottom
    div.header__phone
    div.header__bottom-menu
      ul.navigation

[mydack]

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