0,0
рейтинг
3 марта 2013 в 20:39

Разработка → Объектно-ориентированный дизайн… в CSS

Предупрежу заранее, что я совершенно не считаю себя экспертом HTML/CSS/JS. Но, как архитектору, мне всегда была интересна организация и систематизация кода в самых разных его проявлениях, в том числе и представленных в виде CSS. Особенно сильно этот интерес был подогрет БЭМом, при первом знакомстве с которым подсознание отреагировало когнитивным дискомфортом. А поскольку БЭМ-стиль в проектах у меня стал появляться все чаще, я почувствовал острую необходимость осмыслить, наконец, свое отношение к организации стилей. Таким образом и появился данный топик-размышление, топик-дискуссия. Я понимаю, что взялся за пограничную задачу, поскольку далеко не всем верстальщикам знакомы тонкости объектно-ориентированного дизайна, а большинство архитекторов не написали ни одного CSS-стиля. И, как результат, мне пришлось неуклюже балансировать, чтобы было понятно всем. Но 'этот риск еще больше подогрел мой интерес к теме :)

Вопросы к БЭМ


Начать я решил с того, что мне было не совсем понятно в БЭМ:

1. Многие считают, что техника априори верна всегда и везде, поскольку за ней стоит Яндекс. Почему то, что подходит крупной компании с гигантским штатом и небольшим количеством однотипных проектов должно так же хорошо работать, скажем, в небольшой команде, которая осуществляет заказную разработку самых разнообразных сайтов? Возьмем в качестве примера подходы из jQueryUI, KendoUI и т.п. Они растиражированы на сотни тысяч проектов и в этом плане имеют гораздо большую зрелость. Причем сам Яндекс на сайте bem.info ясно обрисовывает условия применения, но многие даже не доходят до этого параграфа, ограничиваясь первыми строками и успокоительным: «это же придумали в Яндексе».

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

Чтобы проиллюстрировать свои сомнения я взял первые попавшиеся формы ввода с сайта Яндекса: создание почтового ящика, регистрация и фидбека.



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

Яндекс на сайте bem.info пишет: «Каждый новый проект или элемент интерфейса не должны писаться с нуля. Если где-то внутри компании уже выполнялась похожая задача, нужно максимально повторно использовать полученный в результате код. У кода не должно быть контекстной зависимости, его нужно уметь легко переносить в другое место». Давайте посмотрим на пример такого реюзинга.



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

3. Почему отсутствие лаконичности в названиях классов считать преимуществом? И как может нравится это — <div class=«menu__item menu__item_position_first menu__item_state_current»>? В последней верстке, которую я лишил БЭМ объем страницы упал в два раза. Я в данном случае не говорю, что это достаточная причина отказаться от БЭМ и смысл появления этого оверхеда понятен. Просто констатирую, что за такой раздутый синтаксис с низкой энтропией я бы снял балл.

4. Почему нужно отказывать от многих возможностей CSS? Будь то селекторы с использованием идентификаторов, контекстов и т.п.

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

Design by contract


Начал я системной роли классов. Частное, как правило, является менее важным, чем целое, поскольку последнее — суть их сумма. Так и здесь, участие CSS-классов во взаимодействии с остальной частью системы может быть гораздо важней, чем любые улучшения в области одной только верстки. А участие их здесь весьма серьезное. По сути, названия классов — это единственная крепкая связь между HTML и JS. Основная роль JS, так или иначе, иметь дело с DOM-моделью. А какой самый лучший способ добраться до нужных узлов? Селекторы с участием имен классов. Все остальные варианты не масштабируются. В обходите childNodes/parentNode? Завтра там может оказаться враппер и код перестанет работать. Используете названия тегов? Завтра <input> станет <textarea>, <i> станет <em>, <pre> заменят на <code> и скрипты перестанут работать. Имя класса — это тот фундаментальный интерфейс взаимодействия, который мы можем поставить в HTML и использовать в JS не боясь за дальнейшую эволюцию системы.

Я здесь намеренно употребил слово «интерфейс», поскольку хотел провести аналогию с объектно-ориентированными практиками. Надо же как-то отрабатывать заголовок. В свое время Бертран Мейер в рамках разработки языка Eiffel озвучил парадигму проектирования Design by contract. Я не буду сильно углубляться в ее детали, ограничусь только ключевой концепцией. Объекты несут бремя «контрактных» обязательств и взаимодействуют между собой через эти самые контракты. Например, есть некий виджет, который может принимать другие объекты drag'n'drop-ом. Он всем сообщает: «я могу это, для этой цели у меня есть, скажем, функция CanDrop, которой вы передаете в качестве аргумента объект, а я возвращаю логическое значение, принимаю такого типа объекты или нет». Таким образом в его контракте прописано наличие этой функции, ее сигнатура и суть. Системе абсолютно не важно, взял на себя этот контракт виджет для аплоада файлов, дерево с возможностью перетаскивать узлы или это такая продвинутая корзина товаров, куда их можно переносить из каталога мышкой. При операции drag'n'drop-а ей достаточно только знать о том, что некий виджет несет эти контрактные обязательства. И когда вы потащите файл в корзину товаров, она вызовет метод CanDrop корзины получит фейл и просигнализирует вам о невозможности данной операции.

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

Попробую теперь переложить эту идею на HTML+CSS+JS. Представим себе для начала два простых контракта — container и item, они же имена CSS-классов. Первый говорит нам, что он берет на себя обязательства по работе с item. Ему абсолютно все равно, какой за ним стоит тег или DOM-узел. Это может быть элемент списка, пункт меню, закладка на таб-контроле. Он может работать с кем угодно, если этот кто-то готов исполнять контракт item. Таким образом мы укрощаем задачу по принципу «разделяй и властвуй», разбивая на отдельные функциональные области. Работая, например, с меню мы разделяем всё его многообразие функций на те, что отвечают за организацию пунктов меню по принципу container+item, и все остальные.

Для контракта item можем определить некоторую функцию getParent() { return $(this.dom).closest(".container"); }. Для контейнера целую россыпь функций вроде remoteItem, upItem, downItem и т.п. Используя в селекторах только .container и .item вы знаете, что одни и те же функции вы можете использовать для списков, меню, закладок и любых других видов коллекций. Или, другими словами, вы пишите функции по работе со списками и контейнерами один раз, в дальнейшем их просто используете. Если вы добавили новую функцию в свою библиотеку, то она автоматически может быть использована везде, где контейнеры были организованы таким образом. Это замечательно работает в программировании, так почему бы этому принципу не сработать и здесь?

Пример


Давайте попробуем экстраполируем этот пример, скажем, на табы.

<div class="tabbed">
	<ul class="_tabs container selectable">
		<li class="tab item selected">…</li>
		<li class="tab item">…</li>
		…
	</ul>
	<div class="_pages container selectable">
		<div class="panel item selected">…</div>
		<div class="panel item">…</div>
		…
	</div>
</div>

Интерфейс tabbed берет на себя обязательства предоставить доступ к контейнерам _tabs и _pages. Это значит, что если у вас на руках есть объект, реализующий этот контракт, то вы вправе вызвать методы getTabs и getPages, чтобы получить доступ к соответствующим контейнерам. Про последние мы знаем, что они реализуют контракт container, а значит имеют на руках все необходимые функции для работы с коллекцией закладок, в том числе обрабатывать first/last/odd/even и прочие типовые стили для списков. То есть изобретать заново функцию для удаления таба будет не нужно.

К контейнерам добавился еще один контракт — selectable. Он может брать на себя обязательства по предоставлению функции для определения текущего выбранного элемента, менять выбранный элемент и т.п. Например, функции:

getSelected: function() {
	return $(this.dom).find(".item.selected").first();
},

deselect: function() {
	$(this.dom).getSelected().removeClass("selected") ;
},

select: function (item) {
	this.deselect(); $(item.dom).addClass("selected");
}

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

Если вы, скажем, захотите добавить возможность перетаскивать табы drag'n'drop-ом, то просто добавите контракты drag/drop, что позволит сразу задействовать все те типовые функции, которые были для этой цели уже подготовлены.

Но стоит только написать в БЭМ-стиле tabbed_tabs__item, как краски сразу потускнеют. Ведь весь тот код, который всегда хорошо работал с селектором ".item", для самых разных виджетов, перестал работать. У вас были скины, с самыми различными отображениями табов, но они теперь тоже не работают. Мне могут возразить, что имеют место специальные расширения для того же jQuery, которые помогут разобраться со всем этим синтаксическим мусором. Но мне пока не понятно, зачем создавать проблемы, а потом их решать.

Стандарты


Естественно, все эти «контракты», как и интерфейсы в объектно-ориентированном дизайне, должны быть систематизированы и разложены по полочкам. В программировании это зачастую решается за счет использования пространств имен. Но делается это один раз, а потом используется сколь угодно долго и на любом количестве проектов.

На базе таких контрактов гораздо проще ввести внутренние стандарты и реализовать валидаторы, которые будут держать качество кода на постоянном контроле. Это позволит всем участникам процесса, в том числе и вновь подключившимся, мыслить в одном ключе. В начале — императивно, а потом уже по привычке. Ведь как в объектно-ориентированном дизайне контракты не вводятся просто так, а являются следствием продуманного акта, так и в CSS имена классов не должны возникать спонтанно, необдуманно. Ведь БЭМ хоть и пытается контролировать структурный аспект разработки, но совершенно упускает системный. Кто-то табы назовет tabs, кто-то tab-control, иной tab-widget. Например, форма логина у Яндекса из примера в начале статьи называется «b-domik». Это же так мило, назвать ее не login, signup или еще как-нибудь осмысленно, а «би-домик». Вспоминается старое институтское «пи с домиком и пи с душечкой». Верх креатива, но ад для валидации и рефакторинга. Если вы внезапно захотите найти все формы логина и добавить туда новые опции (скажем, идентификацию через какой-нибудь новый социальный сервис), то вам предстоит отловить этот би-домик, узнать, что в почте яндекса он уже зовется b-mail-domik, ссылка «Войти в почту» c титульной страницы уже содержит форму логина с классом b-popupa__wrap. А сколько вам еще подготовлено «открытий чудных»…

Мне кажется, что верстальщики вообще не должны выдумывать имена классов. Обеспечение интерфейсов между HTML и JS должно осуществляться проектировщиками. Они разрабатывают контракты, систематизируют и доносят эту информацию до тружеников HTML/CSS. Это дает и масштабируемость JS-кода, и реюзинг, и рефакторинг, и валидацию в соответствии с корпоративными стандартами, а значит — качество. Мне кажется этого вполне достаточно для того, чтобы был повод поразмышлять.

CSS-препроцессоры


Под конец замечу, что такие стили достаточно легко и органично описываются в духе LESS/SASS/Stylus-препроцессоров:

.tabbed {
	…
	._tabs {
		….
		.item {
			….
			.selected {
				…
			}
		}
	}
	…
}



Таким образом можно легко собирать и повторно использовать различные скины. Причем, при компиляции все это породит семантически похожие на БЭМ селекторы, поскольку нет никакой существенной разницы между .tabbed ._tabs .item {…} и .tabbed_tabs__item {…}.
Станислав Ярмонов @Guderian
карма
120,0
рейтинг 0,0
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (136)

  • +46
    О-о-о, значит, не только я считаю, что БЭМ стоит поперек горла CSS?
    • +9
      Пока я занимаю осторожную позицию, может я чего-то не знаю о БЭМ. Но ситуация такова, что я его не понимаю, я не понимаю, из чего следуют его преимущества и, самое главное, я не вижу этих преимуществ и на сайтах того же Яндекса. Одно дело — прочитать, как это меняет весь мир к лучшему и совсем другое — воочию увидеть эти изменения. А вообще меня больше интересует не насколько БЭМ плохой, а насколько хорошими могут быть альтернативы. БЭМ уже выполнил важную роль, он заставил об этом задуматься и говорить.
      • +3
        БЭМ не так плох, как вам кажется. И суть этого подхода лежит не в плоскости CSS, а в плоскости XML. Единственное, чего не хватило БЭМ-у (а может и людям, которые его используют), так это эволюционный переход от визуально-ориентированных структур к функционально-ориентированным. Надо описывать не то, что видишь, а то, что является сутью того, что видишь. Например, все кнопки во всех проектах можно всегда запаковывать в .actionBox, а не вставлять ситуативно в контейнеры, как обычно делают кодеры.

        И цель БЭМа не в особом способе написании стилей, а в
        * сокращение затрат на тестирование
        * универсальная точка обмена информацией в абстрактном XML между разработчиками
        * реализация слабосвязанной архитектуры
        • +1
          > эволюционный переход от визуально-ориентированных структур к функционально-ориентированным

          Согласен всей душой. Те «контракты», о которых я говорил — это не только способ взаимодействия между HTML и JS, но также тот единый диалект, на котором верстальщики могут говорить с программистами.

          > И цель БЭМа не в особом способе написании стилей, а в

          Декларированная цель — не эквивалентно цели достигнутой. Поэтому в статье я коснулся практически всего, что вы перечислили. И реализации слабосвязной архитектуры (это вообще одна из целей контрактного программирования), и обмена информацией между разработчиками (к слову о би-домике), и затраты на тестирование (я, правда, больше говорил о рефакторинге, но технически у них почти одинаковые требования). Я, например, понимаю, как можно осуществлять реюзинг селениум-тестов на том варианте, что предложил я, но с трудом вижу их для БЭМ.
          • +1
            Если абстрагироваться от конечной реализации, ваш подход ничем не отличается от БЭМ.
            Но проигрывает ему в том, что у вас единая точка обменом информации — CSS. Это не самая удачная технология для этой цели
        • 0
          Соглашусь, БЭМ не так плох. Но я считаю что БЭМ — это внутре корпоративные правила больше, нежели какая-то отличная методология (или даже парадигма).

          * сокращение затрат на тестирование — Не согласен, потому как не понимаю как ЭТО может мне помочь с тестированием кода?
          * универсальная точка обмена информацией в абстрактном XML между разработчиками — Согласен.
          * реализация слабосвязанной архитектуры — Согласен.

          Но в целом тестирование тут не причем. Затраты на тестирование в html/css и сегодня, довольно увлекательный процесс.
          • 0
            :) Сокращение затрат на тестирование — эффект от слабосвязанной архитектуры. Вы правите код в одном месте и в одном же месте проверяете его работоспособность без боязни что-то поломать в других местах.

            Давайте разберемся, что же такое БЭМ? Это способ построить абстракцию более высокого уровня, чтобы иметь возможность потом превратить ее в конкретный код определенной технологии. Кому это полезно? Да всем. Люди перестают мыслить низменными категориями и выходят на более абстрактный уровень, который проще для восприятия и дешевле для изучения. Вместо разброда и шатаний мы получаем единообразие мышления команды, и она идет не на языке HTML, CSS или JS, а на XML.

            Негатив БЭМа в том, что он в текущем виде визуально-ориентированный. Элементы описываются по визуальным признакам, а не по логическим. И по мере накопления визуальных различий качество самого XML будет падать.
            • 0
              Элементы описываются по визуальным признакам, а не по логическим.

              Вот! Вы хорошо сформулировали, что у вызывало у меня дискомфорт при попытках освоения БЭМ без особой цели.
            • +2
              Сам по себе БЭМ не диктует визуально-ориентированность, просто больше всего примеров с визуальными блоками, т.к. это понятнее всего. А на деле мы во всю делаем всякие абстрактные блоки, которые даже не имеют никакого визуального представления. Но при этом они по прежнему реализуются в нескольких технологиях (например, клиентский js, тесты, документация, примеры).
              • 0
                Сам по себе конечно же не диктует. Но именно к нему скатываются разработчики

                Возьмем простой пример.
                К чему вообще такой элемент как <e:column>? Это же сугубо визуальное определение. Это один из модификаторов, но никак не елемент. Я понимаю, что это только пример, и что в реальной жизни все не так.

                Научиться правильно именовать сущности, которые мы видим перед собой — вот ключ к успеху, и не только применительно к БЭМ
                • 0
                  Колонка — модификатор таблицы?
                  • 0
                    Колонка — контейнер, который имеет различные визуальные характеристики, и может отображаться как обычный блок потока, как колонка, как скрытый элемент. Как именно будет отображаться — задача модификатора.
  • 0
    Вы естественной (и внезапной) личной эволюцией переросли CSS, и ваша дорога привела вас в XAML, который делали с похожим возмущением и идеологией. Велкам к UX-неграм нового поколения =)
    • 0
      Я уже был в доме под названием XAML, в портфолио немало Silverlight/WPF-проектов и оттуда я ушел, так что дорога в прямо противоположном направлении))
      • +2
        Вы не могли бы всем донести, чего вам в XAML не хватило, с акцентом на упомянутые в данной статье мысли? Это действительно интересно, видно, что вы глубоко копаете тему, и вообще в тренде.
        Если ни CSS + HTML5 ни XAML не удовлетворяют некой нужной идее, то нам стоит ждать какое-то неожиданно-новое решение неизвестно от кого под интерес кодеров, либо развитие одного из существующих подходов.
        Я прошу вас выступить в комментарии как аналитику, или отдельный пост сделать в целом об индустрии с упором на критику XAML против CSS, и оба против реальных потребностей кодеров.
  • 0
    Мне кажется, что верстальщики вообще не должны выдумывать имена классов. Обеспечение интерфейсов между HTML и JS должно осуществляться проектировщиками…

    Верстальщики не должны, возможно, а если вспомнить что еще есть менеджмент и дизайнеры? Их бы вообще повыгонять, эти ребята больше всех портят хорошие архитектуры. БЭМ считает что технологии вторичны, да, это несет некоторые архитектурные проблемы, но и дает много возможностей, среди которых быстрый старт работы нового разработчика, а тут так оп, и все имена класов нужно согласовывать с… проектировщиком. Качество? А скорость? А согласованость проектировщиков?..
    Поймите меня правильно, я утрирую, но все же.
    • +1
      Задача нового разработчика — не создавать новые проблемы. И если каждый из них будет выдавать свое видение тех же логинов и форм, то это не сулит ничего хорошего. С точки зрения быстрого старта я вижу все предельно просто. Новый разработчик получает годами и многими умами выпестованные гайдлайны. С высокой степенью вероятности он может ими проникнуться и с легкостью ввинтится в слаженную работу. Можно вполне допустить, что он наворотит дел и не всегда будет следовать советам, но это опять же все легко контролируется и рефакторится. Появился класс с неизвестным именем — внимание. Это либо новая гениальная идея для внутренних стандартов, либо фейл.
  • +1
    Все что вы написали, сводится к тому, что одни классы используются для стилей (._tabs, .tab) а другие (.item, .container) для манипуляций с dom.
  • +1
    А почему БЭМ против контекстности? Наскольно я понимаю, она вполне возможна, другое дело, что верстка абсолютно независимыми блоками делает рендер очень быстрым, и в том же Яндексе ею начали активно пользоваться после того как долго мучались с производительностью новой почты (кажется – neo2).
    • +2
      Совершенно верно, никаких категоричных запретов на контекстную зависимость в БЭМ нет. Просто нужно понимать, что она даёт и что забирает.

      Забирает:
      — производительность
      — устойчивость к модификациям вида «перенести это в _таком же_ виде в другое место»

      Даёт:
      — меньше писать, т.к. не надо в каждом месте повторять что-то точечно, а можно модифицировать контекст
  • +3
    нет никакой существенной разницы между .tabbed ._tabs .item {…} и .tabbed_tabs__item {…}
    Вы точно представляете как работает selector-engine?
    Ведь весь тот код, который всегда хорошо работал с селектором ".item", для самых разных виджетов, перестал работать
    Зачем вам выбирать итемы разных сущностей?
    • 0
      > Вы точно представляете как работает selector-engine?

      Я в самом начале статьи обрисовал свой уровень претензий на звание эксперта. Если Вы меня поправите, то сильно тем самым обяжете.

      > Зачем вам выбирать итемы разных сущностей?

      Реюзинг. Большое количество различных сущностей обладает схожим поведением. Списки, дропдауны, гриды, табы, меню и т.п. помимо своей специфики имеют общее поведение — они являются контейнерами некоторых элементов. Есть масса типовых операций, которая может быть совершена с такими элементами. Скажем, удаление элемента с индексом X. Такой метод пишется единожды и замечательно работает для всех перечисленных контролов. Все это давно существует в большинстве языков программирования, почему это не должно сработать в данном случае?
      • 0
        Тут встает вопрос переопределения поведения методов. Например, я хочу, чтобы табы, работая как контейнер с элементами, добавляли новые элементы (табы) не в конец списка табов, как при стандартном поведении, а в начало списка табов. Для этого придется либо изменять изначальное поведение контейнеро-элементов, либо копипастить аналог. То есть ООП (в данном случае наследования) нету в должной степени. Или я что-то неправильно понял?
        • 0
          Нет никаких проблем с перегрузкой метода добавления элемента только для табов.
  • 0
    1) Предпочтение селекторам классов перед остальными — одна из основных рекомендаций БЭМ.
    2) Модель БЭМ избыточна.
    3) Можно группировать семантически близкие элементы, если используете их в CSS.
    Пример из бутстрапа:

    select,
    textarea,
    input[type="text"],
    input[type="password"],
    input[type="datetime"],
    input[type="datetime-local"],
    input[type="date"],
    input[type="month"],
    input[type="time"],
    input[type="week"],
    input[type="number"],
    input[type="email"],
    input[type="url"],
    input[type="search"],
    input[type="tel"],
    input[type="color"],
    .uneditable-input {
      display: inline-block;
      height: 20px;
      padding: 4px 6px;
      margin-bottom: 10px;
      font-size: 14px;
      line-height: 20px;
      color: #555555;
      -webkit-border-radius: 4px;
      -moz-border-radius: 4px;
      border-radius: 4px;
      vertical-align: middle;
    }
    
    • +2
      Какой хороший селектор на инпуты
  • +5
    Вы просто не понимаете БЭМ.
    1. Многие считают, что техника априори верна всегда и везде…
    Методику БЭМ можно не использовать на простых страницах (простых интерфейсах), хоть, просто именами тегов пользуйтесь, но как начинается усложнение, сразу обнаруживается, что код в стиле БЭМ гораздо легче поддерживать и дописывать.

    2. Почему считается что принудительная контекстная независимость — это хорошо и тут же вводится эта самая зависимость элемента от блока, если пользоваться терминологией БЭМ?
    Вот тут уже обнаруживается ваше неумение готовить БЭМ. Во-первых, БЭМ не вводит зависимость от блока. Он говорит, что блок представляет собой единое целое, причём сущность должна быть настолько минимальной, насколько это возможно. То есть кнопка из вашего примера будет отдельным блоком, таким образом, пример совершенно не в кассу.

    Пёстрость же Яндекса объясняется тем, что он очень крупный проект. Главную могли переделать совсем недавно, а всплывающая форма логина осталась старой. Возможно, недосмотрели, возможно не было времени или не хватило ресурсов. Уверен, что в Яндексе огромное число таких зависимостей в разных местах, и они могут рваться при изменениях. При том всё работает, и это несомненная заслуга БЭМ — блоки независимы и могут работать в разных контекстах.

    3. Почему отсутствие лаконичности в названиях классов считать преимуществом?
    И опять мы видим ваше неумение готовить БЭМ. Кто вам сказал, что это считается преимуществом? Наоборот, приветствуются лаконичные названия. Если у вас много длинных имён классов, скорее всего, вы что-то не так сделали. То же правило что каждый блок должен быть настолько лаконичен, насколько это возможно.

    4. Почему нужно отказывать от многих возможностей CSS? Будь то селекторы с использованием идентификаторов, контекстов и т.п.
    Селекторы по идентификаторам имеют очевидные проблемы со специфичностью, невозможностью повторного использования на той же странице и т.п. Контексты же в БЭМ используются, но по минимуму, только там где надо: при описании модификаторов. Это даёт заметные преимущества за счёт сокращения проблем со специфичностью и зависимостью от контекста, что и является одним из основным преимуществ БЭМ.

    Что касается идеи разделении имён классов для отображения и поведения (то есть скриптов), то по мне она очевидна и совершенна перпендикулярна БЭМ.

    Вообще ожидал увидеть здесь что-то вроде OOCSS, а обнаружил лишь недостаток понимания методологии.
    • –1
      К сожалению, пока БЭМа нет за пределами яндекса.
      • –2
        • +1
          Я имею ввиду, что не смотря на подробное описание идей и наличия в ней здравого смысла, для большинства разработчиков вне яндекса БЭМ — это префикс b_, который добавляется вручную ко всем именам классов вне зависимости от от того есть ли на проекте другие сущности, кроме блока. При этом в коде во всю используются вложенные селекторы, селекторы тэгов и проч.

          И да, к чему эта ссылка?
          • 0
            К тому что:
            Другие российские порталы также используют БЭМ.

            Например, сервисы Mail.ru частично реализованы с применением БЭМ. Это касается CSS реализации страниц, а также собственного C++ шаблонизатора компании.

            Другие примеры:

            Рамблер.Новости
            HeadHunter
            TNK Racing Team
            Сайты, разработанные на основе библиотеки bem-bl:

            Форма с JZ валидацией
            Mikhail Troshev vCard
            Код проекта на GitHub: github.com/mishanga/bem-vcard

            А чтобы понять БЭМ надо иметь опыт работы над крупными проектами, где всё постоянно меняется и что угодно может оказаться где угодно, и нельзя верить словам: «нет, так никогда не будет», потому что назавтра будет именно так. Конечно, это понимают в первую очередь крупные проекты.
            • +2
              Я глубоко сомневаюсь, что во всех перечисленных проектах используется БЭМ-тулз. А без него это уже просто вёрстка независимыми блоками. Кроме того, интернет (или хотя бы рунет) не ограничивается указанными проектами. Тысячи БЭМ-подражателей жарят адовый код, не вникая в подробности методологии. Не надо меня убеждать, что БЭМ хорош. Это я знаю не хуже вас. Но факт остаётся фактом: на данный момент мало кто понимает суть метода.
              • –1
                Сначала вы говорили «никто», теперь «мало кто», прогресс, однако. А мой начальный комментарий и есть про непонимание БЭМ.
                • 0
                  Дано: всего 10 000 сайтов с префиксом b_. Из них по методологии свёрстано — 10 сайтов. Вопрос: можно ли сказать, что никто не использует БЭМ?

                  Не придирайтесь к словам.
                  • –2
                    Префикс b_ не имеет отношения к БЭМ, хотя и выбран логотипом. Его использовали в Яндексе и до внедрения БЭМ совсем для других целей, и признали нецелесообразных, хотя и используют по традиции.
                    • 0
                      Спасибо, капитан! Однако для большинства разработчиков, БЭМ это именно префикс.
                      • 0
                        Вы не поняли, я и пишу про непонимание БЭМ.
                        • 0
                          Мда. Очевидно, мы об одном и том же. Расходимся.
              • +1
                Я глубоко сомневаюсь, что во всех перечисленных проектах используется БЭМ-тулз. А без него это уже просто вёрстка независимыми блоками.
                БЭМ — это методология, а не набор инструментов. Выросшая из и основанная на понятии независимых блоков.

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


                  Вот эти самые негры сейчас и говорят вам, что БЭМ никому не нужен. И именно этим неграм вы пытаетесь доказать все прелести метода.
                  • –2
                    Никому ничего не хотел доказывать. Я просто хотел сказать, что создатели БЭМ — очень неглупые люди с огромным опытом, решающие самые разнообразные по сложности и необычности задачи. Создание интерфейсов нуждается в системном подходе и команда БЭМ просто предлагает свой.
                    А нужна ли неграм такая методология или нет — решать только неграм вам, и не нужно говорить что БЭМ не нужен никому.
              • +2
                В Mail.ru есть bem-tools :-) Может быть как-нибудь расскажем!
                • 0
                  Очень ждем! :)
        • 0
          Да, нет. Если смотреть в цифрах. Реально он пока держится на яндексе и патриотизме. Но замечу, сама методология хороша. Хотя как по мне oocss в разы лучше!
  • +14
    БЭМ в таком виде как его представляют в яндекс необходим только яндексу.
    • –2
      bem-tools — возможно. БЭМ как методология — точно нет.
    • +2
      Ваше утверждение немного конфликтует с тем, что к нам на конференциях подходят посторонние люди и говорят, что у них есть необходимость в подобной БЭМ методологии (а также в наборе инструментов и готовых блоков).

      Абсурдно спорить с тем, что БЭМ появился как решение конкретных проблем в Яндексе (и продолжает нами развиваться тоже для этого же) — мы не спорим ;-) Вот только это не противоречит никак тому, что всё это применимо в других проектах — нужно всего лишь преодолеть порог входа!
      • 0
        Применимо-то много что много где. Вопрос в том, оправдано ли преодоление порога входа и использование в проектах того или иного масштаба. Есть ли нижний предел масштабируемости? Бог с ним с порогом входа, но стоит ли использовать БЭМ при верстке шаблона какой-нибудь визитки? Зависит ли целесообразность использования от того будет этих визиток одна или сотня, с минимальными различиями в шаблонах?
        • 0
          Конечно нижний предел масштабируемости есть. Его тяжело сформулировать точно, т.к. у нас нет никаких едениц измерения для размера и сложности проекта. Если говорить примерно, то, безусловно, если вам сейчас нужно сделать один сайтик и больше их не делать никогда, то не надо тратить время на преодоление порога входа. Если же вы хотите остаться в профессии на долго, то скорее всего (если всё будет складываться) размер и сложность проектов со временем будут только расти (в идеале расти бесконечно ;-) ) — а это значит, что рано или поздно, вы преодолеете любой нижний предел. Так почему бы не начать сразу?! ;-)
          • +1
            Я же сказал, бог с ним с порогом входа. Я про «оверхид» при работе над небольшими и несложными проектами. При беглом знакомстве мне он показался значительным, по крайней мере в приложении к одному проекту. Может на десятке или сотне условно однотипных сайтов плюсы всплывут?
            • +2
              Если вы уже преодолели порог входа (важное условие!), то делать даже простые сайты (ну где есть больше одного блока, а не просто текст в body) проще с БЭМ. Лично я все личные мелкие штуки быстро тяпляпаю с bem-tools/bemhtml/i-bem.js.
        • +2
          Если отбросить вопрос порога входа и рассматривать только применимость, то у меня вот такие мысли. Есть два типа сложных инструментов (инструментов с высоким порогом входа):
          1) узкоспециальные — например, какой-нубудь инструмент для обслуживания велосипеда — сложность там обусловлена предметной областью, т.е. как раз применимы они только для определённых задач
          2) универсальные — например, швейцарский нож — сложность обусловлена тем как всё сложно понапихано в одну штуку, но применимость (после того как овладел) вполне универсальная (даже в велике можно будет что-то покрутить)

          Мы всю дорогу проектировали БЭМ как раз как более универсальный инструмент и вот есть пример применения его для той же визитки: github.com/mishanga/bem-vcard + mishanga.pro

          Но это конечно не означает, что он универсален до абсолюта — продолжая аналогию, для некоторых задач нужен не швейцарский нож, а бутылка воды.
          • +1
            А дает ли выигрыш ваш универсальный инструмент при простых операциях или проще пальцами гайку затянуть, зубами провод оголить, ногой втулку забить и т. п.? :)
            • +1
              я думаю на этом можно считать тред исчерпанным ;-) — ваши аналогии вполне хороши, а дальше каждый сам для себя решает, зубами он провод оголяет или швейцарским ножом
  • 0
    > Вы точно представляете как работает selector-engine?

    Я в самом начале статьи обрисовал свой уровень претензий на звание эксперта. Если Вы меня поправите, то сильно тем самым обяжете.

    > Зачем вам выбирать итемы разных сущностей?

    Реюзинг. Большое количество различных сущностей обладает схожим поведением. Списки, дропдауны, гриды, табы, меню и т.п. помимо своей специфики имеют общее поведение — они являются контейнерами некоторых элементов. Есть масса типовых операций, которая может быть совершена с такими элементами. Скажем, удаление элемента с индексом X. Такой метод пишется единожды и замечательно работает для всех перечисленных контролов. Все это давно существует в большинстве языков программирования, почему это не должно сработать в данном случае?
  • +3
    Ка-то внезапно статья оборвалась. Думал будет какое-то предложение обсуждения типовых интерфейсов, может фреймворк или библиотека.
    • +1
      Был такой план, но для начала я хотел собрать фидбека и знаний, чтобы понять правильность выбранного направления.
  • +1
    А поскольку БЭМ-стиль в проектах у меня стал появляться все чаще, я почувствовал острую необходимость осмыслить, наконец, свое отношение к организации стилей.

    А у вас появлялся бемтулс яндекса(или иное их программное обеспечение которое позволяет всем их сотрудникам работать вместе) если вы рассуждаете о ихней структуре блоков и о том как они их изменяют\добавляют\модифицируют.
    • 0
      В том-то и проблема, что нет. Я прекрасно понимаю, что Яндек вряд ли стал бы себе создавать проблемы. Но, как я обозначил в своем сомнении номер 1, меня настораживает то, что многие начинают использовать БЭМ бессистемно и бездумно. И поэтому в проектах возникает не система мер направленная на что-там, а просто одни только БЭМ-стили. Это, естественно, не проблема БЭМ.
      • +1
        Верстальщиков вы не сможете научить\образумить это придет к ним только с опытом… Вам нужно было посмотреть недавний матер-класс Юрия Артюха, и у вас бы стало намного меньше вопросов с тем кодом который вам присылают или наоборот много к верстальщику который делает не так как нужно:)
        А про яндекс лучше писать после ознакомления с их bemtools.
        • +1
          Добавлю, что настоящая мощь использования методологии приходит, когда вы начинаете писать js в BEM-терминах bem.github.com/bem-bl/sets/common-desktop/i-bem/i-bem.ru.html.
          • +2
            Добавлю, что ещё можно писать шаблоны с помощью BEMHTML:
            events.yandex.ru/events/yasubbotnik/msk-sep-2012/talks/329/
            raw.github.com/bem/bem-bl/master/blocks-common/i-bem/__html/i-bem__html.wiki
          • 0
            Прикольно, но я уже как 5 лет двигаюсь в этом же направлении.
            Структурно-ориентированное программирование + событийная модель = невероятно удобная разработка.
            • 0
              Я последнее время думаю над этим clubs.ya.ru/bem/replies.xml?item_no=2144. Одностраничное приложение в BEM.

              Шаблонизатор bemhtml работает на клиенте, у BEM-блоков есть методы обновления/замены и прочее DOM-ноды github.com/bem/bem-bl/blob/master/blocks-common/i-bem/__dom/i-bem__dom.js#L1061. Есть i-system, i-request и i-location.

              А пока набиваю руку на простых проектах. По мере возможности буду об этом писать :)
              • +1
                Спрашивайте если что, я последние 5 лет только и делаю, что создаю одностраничные приложения.
                Там необходима несколько другая логика, чем в обычных приложениях, но особо ничего сложного нет.
  • +1
    Я тоже немного поковырял тему в своё время. В принципе, можно начать с того, что Яндекс нигде не утверждает, что это решение единственно верное, скорее даже наоборот — везде чётко указывается, что эта методология призвана решать проблемы, которые возникают у Яндекса в их работе, с их организацией труда, с их рабочими процессами и т. д. и т. п. Также, вполне очевидно, что в РФ (да и вообще в мире) команд, которые обладают схожими задачами и условиями, прямо скажем, немного. Я для себя пришёл к выводу, что мне было полезно ознакомиться, чтобы знать что «бывает и вот так», но я тоже не смог придумать, где бы я мог в своих задачах это применить.
    • 0
      Совершенно верно. Поэтому я даже сослался в тексте статьи на «Условия использования», которые декларированы на bem,info. К сожалению, их мало кто читает.
  • 0
    Guderian, мне очень нравится ваш системный подход — в своей работе с таким не сталкивался, но интуитивно хочется делать что-то подобное — подскажите — где набраться подобного опыта?
  • +2
    поскольку нет никакой существенной разницы между .tabbed ._tabs .item {…} и .tabbed_tabs__item {…}.

    Я или не так понял, или вы заблуждаетесь. Если вы писали о 2 селекторах, то разница огромная, вот вам код:

           <div class="tabbed">
                <div class="__tabs">
                    <div class="item">
    
                        <div class="someblock">
                            <div class="__list">
                                <div class="item">
    
                                </div>
                            </div>
                        </div>
    
                    </div>
                </div>
            </div>
    


    и этот код:
    
    
    <div class="tabbed">
        <div class="tabbed__tabs">
            <div class="tabbed__tabs__item">
    
                <div class="someblock">
                    <div class="someblock__list">
                        <div class="someblock__list__item">
    
                        </div>
                    </div>
                </div>
    
            </div>
        </div>
    </div>
    


    Думаю тут объяснять нечего.
    • +1
      походу я и вас не понял и вы имели ввиду код препроцессоров.
  • +2
    >>>Предположим, я хочу, чтобы все кнопки на сайте у меня выглядели не так, как это хочется автору блока, а в соответствии с единым, продуманным стилем

    Кто вам мешает объявить кнопку блоком, а потом дописывать ей модификаторы, чтобы где-то отрисовать кнопку побольше/поменьше. Разные блоки могут вкладываться в друг друга — А в Б, или Б в А, и это основа методологии. Ей богу, вы что-то не поняли.
  • +2
    Подход «Design by contract» так же можно реализовать на основе понятия «модификатор» из БЭМ. И вообще БЭМ, по моему мнению, сильно напоминает концепцию модульного программирования, т.е. мы оперируем абстракциями более высокого порядка чем в ОПП.
    • +3
      Именно так. Идея «интерфейсов» или «контрактов» отлично выражается в БЭМ-терминах (мы этим сами пользуемся). Можно это делать не только с помощью модификаторов, но и с помощью дополнительных примиксованных блоков. При этом происходит явное отделение, когда нам нужно заводить интерфейс, а когда нет. Подробнее про миксы можно послушать в докладе events.yandex.ru/events/yasubbotnik/msk-sep-2012/talks/327/
  • +4
    БЭМ в первую очередь это верстка с использованием независимых блоков, а все остальное вторично. Если у вас огромный проект и на нем работает большой штат верстальщиков то будет оправдано использовать БЭМ в полной мере. Если вы одиночка или если делаете проекты для разных компаний то стоит осмыслить концепцию и на ее основе уже делать что то свое, удобное вам.

    По своему опыту могу сказать что верстка с использованием независимых блоков это обязателньое условие хорошо сделанного проекта. Иначе любой средний по величине проект станет просто кашей не поддающейся модификациям и редизайну без отборного мата ))
  • +5
    Давайте ненавидеть БЭМ вместе!
    Он плох как минимум прочерками. Как же ненавижу прочерки! А в БЭМ они двойные! Ух, как их ненавижу!
    • +2
      В основе БЭМ лежат независимые блоки. Вы можете использовать свою нотацию (с дефисами и шлюхами). Почитайте это: pokrovskii.com/obektno-orientirovannaya-verstka/. Максим в своё время хорошо описал то, что сейчас является сутью БЭМ.
      • +2
        Вы сломали весь посыл.
        Я понимаю, что есть БЭМ, но отказался от него сразу же после чтения вступительной документации. Моё мнение таково: он стоит поперёк горла самой идеи классов, используя их почти как ID, только в какой-то своей, извращённой форме. Это не то чтобы плохо, нет. К этому никто не готов, включая Консорциум. Очень жаль, что идея стала бездумно воплощаться.
        • 0
          Но ведь другого решения нет. Нельзя опираться на имена тэгов. Вложенные селекторы работают дольше. Одинаковых элементов на странице может быть много.

          Это совсем не поперёк идеи классов. Ведь блоки по нескольку раз используются на странице. Однако вы чертовски правы. К этому просто никто не готов.
          • +1
            Мне всё больше кажется, что верстальщики пытаются оптимизировать время чтения селекторов себе во вред. Ну не настолько оно всё медленно, чтобы прилагать какие-то ручные старания для оптимизации. Моё мнение таково, что это должна делать автоматика. Обфускация, все дела. Но не на рабочем месте разработчика, а на сервере. Чтобы ничто не мешало читать код.
            • 0
              Не могу сказать за вложенные селекторы т.к. не видел тестов но вот за тэги есть тест Виталия Харисова. Разница колоссальна. Вот бы увидеть что-то и для вложенных селекторов.
              • 0
                Там нет ни слова про время выполнения. Где доказательства? Я вот пока не вижу причины не употреблять звёздочку. От неё вёрстка не начинает ужасно тормозить.
                • +1
                  Не боитесь, что к тому моменту, когда вы увидите причины не употреблять звёздочку, у вас на руках будет огромный проект с кучей кода и большим количеством элементов на странице? И его надо будет полностью переписать, т.к. на таких объёмах уже будут глазом видны тормоза (кстати, про измерения не «на глазок» можно посмотреть events.yandex.ru/events/yasubbotnik/kiev-may-2011/talks/232/ ).

                  Я понимаю, что аргумент звучит в духе «такие проблемы только у Яндекса» и «маленьким проектам это не нужно». Но я просто хочу намекнуть задуматься, а стоит ли проверять на своём опыте, наступите ли вы на эти же грабли.
                  • 0
                    Понял. Посмотрю время отрисовки своих последних вёрстк. Но даже если решу “да, надо ускорять селекторы”, то буду искать более элегантные способы, чем портить всё тысячами повторений.
                    • 0
                      не забудьте поделиться более элегантным решением, мы бы тоже его с удовольствием заиспользовали!
                      • 0
                        Ну вот, например, написал про автоматизацию БЭМ.
                        • +2
                          я имел ввиду «решение», а не «идею решения» — идей мы и сами отсыпать можем ;-)
                          • 0
                            решение пока простое — не ввязываться в постройку громоздких браузерных приложений, пусть этим занимаются крупные корпорации.
                • 0
                  В заметке написано:

                  Наглядный пример: 30 тысяч div'ов на странице, селекторы заканчиваются на .text (рефлоу 5 секунд) и на div (рефлоу 37 секунд, осторожно! браузер замерзает, а потом оттаивает).

                  И там же ссылки на примеры, можете замерить сами в разных браузерах.
          • 0
            > Вложенные селекторы работают дольше.

            А давайте удалим всю разметку из страницы. Так она отработает с нулевым временем.
            • 0
              Количество тэгов и вложенные селекторы — не одно и тоже.
        • +2
          Консорциум не был готов к такому быстрому развитию технологии, и даже представить себе не мог, что сейчас разработчики делают с помощью HTML/CSS/JS, поэтому приходится по своему решать проблемы, и пересматривать работу с теми же селекторами.
          • 0
            Они-то, думаю, готовы. Это IE никогда ни к чему не был готов, тормозя весь караван. Оттого и такое мнение, что W3C пишут спецификации для Википедии.
            В действительности там настолько безумные идеи в черновиках, что одно только понимание их использования порой вызывает шок. Читали про новые блочные модели, про круговые цветовые растяжки? Они прекрасны своей сложностью и ладностью.
            А весь мир пока ещё даже CSS2.1 не полностью осилил. Вспомните глупые вопросы про vertical-align или пробелы в inline-block.
        • 0
          ID обязаны быть уникальными в пределах документа. В основе же БЭМ, одним из принципов, всегда лежала идея о произвольном повторении произвольных блоков на странице. Скорее можно сказать, что БЭМ стоит поперёк горла идее каскадных селекторов, т.к. классы то используются как раз по назначению. Но это тоже не совсем так, про контекстную зависимость уже писал тут выше по треду — habrahabr.ru/post/171437/#comment_5951255 — у неё есть особенности, но БЭМ её никак не запрещает (просто мы подробно рассказываем в чём минусы и получается так, что в реальных проектах она мало используется).

          Отдельно немного в тему Консорциума — habrahabr.ru/company/yandex/blog/156389/
          • +1
            Скорее можно сказать, что БЭМ стоит поперёк горла идее каскадных селекторов, т.к. классы то используются как раз по назначению.

            Бинго! Как раз эта мысль крутилась на языке на кончиках пальцев весь день.
            Каскадность.
            Эта прекрасная изящность кода.
            А порчей кода пусть занимается автоматика, всячески обфусцируя его и сжимая. Нет, правда, можно же сделать программу, которая будет превращать каскад в БЭМ. Да, она будет предъявлять некие требования, но это уже будет полезно. Нельзя полагаться на человеческий фактор, когда правила имеют рекомендательный характер — они начнут хаотично смешиваться по вкусу и получится плохо, как от рецепта “соли по вкусу” для ребёнка с пельменями. У него нет своего выбора, ему нужна точная инструкция. Строгая.
            • +3
              Я скорее на стороне тех людей, которые считают, что веб-разработчики это не дети и вполне могут иногда подумать. Но если нужны строгие правила, то легко — пельмени можно никогда не солить, каскад можно никогда не применять. А тот, кто почувствует, что ему эти правила жмут, тому и строгая инструкция не нужна.
              • 0
                Тогда бардак. Бардак Эвентуальный Метастазирующий. Потому что никто ни с кем ни о чём не договаривается и при чтении кода Я не понимаю, что значит .b-gT-SEf-item, например.
                • 0
                  Бардак, это то что «никто ни с кем ни о чём не договаривается». В основе БЭМ-методологии как раз одной из идей лежит коллективное владение кодом и обсуждение архитектуры людьми разной специализации (т.к. одни и теже БЭМ-сущности существуют в разных технологиях). А когда люди, работая над общим проектом, начинают больше общаться, то там и побочных ещё бонусов куча всплывает!

                  P.S. Я предлагаю сократить до Бардак Элемент Модификатор ;-) а то такая смешная шутка, а никто повторить не может.
                  • 0
                    Когда люди договариваются, проблем возникать вообще не должно. Это командная работа, она другой быть не может. БЭМ не усложняет проблему понимания кода. Вот ещё одна причина избегать его: когда этот код писал человек со стороны, а это: фрилансер, сайд-разработчик, человек из другого отдела, в общем — все, с кем не плечом к плечу.
                    • 0
                      Позвольте не согласиться (хотя там «не» затесалось и я может не правильно понял). Если код писал человек со стороны, то наличие любых соглашений (например, БЭМ) будет положительно сказываться на принятии этого кода (хоть что-то знакомое будет, хотя бы общие принципы). Если же никаких соглашений нет (пишем как хотим или как наиболее коротко и элегантно), то вероятность не понять такой код от стороннего человека только возрастает.
                      • 0
                        В действительности получается такая вилка: либо все плечом к плечу, либо все стараются хорошо. В остальных случаях получаются проблемы.
            • 0
              +1, при генеративном подходе запросто можно заменять те участки, где раньше был БЭМ на код, упакованный в base64, например. И вместо длинного БЭМ-спича будет «x3c», например. И их можно генерировать из привычных глазу селекторов точно также, как из них можно генерировать БЭМ.
              • 0
                Вы перегибаете палку. Достаточно будет склеивать селекторы.
                • 0
                  А в каком тогда смысле вы упоминали обфуксацию и сжатие? Имхо, читаемые пользователем селекторы при генеративном подходе не нужны в принципе. Если только это не контракты.
                  • 0
                    Обфускация и сжатие нужны только в production, в разработке всё-таки нужно ещё и в Web Inspector смотреть.
                    • +1
                      Ключевой я предполагал не обфускацию, а генеративность. Есть осмысленное, человеколюбивое, каскадное описание стиля и есть продуцирующие правила. Одно генерит бэм или супер-бэм имена стилей и работает для отладочных сборок, другая — результат обфускации для релизных. Пишешь так, как нравится, получаешь то, что хочешь в данный момент времени.
  • +5
    Яндекс. Почему то, что подходит крупной компании с гигантским штатом и небольшим количеством однотипных проектов должно так же хорошо работать
    Это по-вашему, «небольшое количество однотипных проектов» www.yandex.ru/all? В «Яндексе», кроме того, ещё и интранет существует, очень развитый.
  • +1
    Мне одному кажется, что «техника априори верна всегда и везде, поскольку за ней стоит Яндекс» — это очень странное предположение и что естественно предполагать как раз обратное?
  • 0
    Я рад что не у одного меня такие мысли. Хотя методология БЭМ хороша. Как инструмент он имеет довольно узкую нисшу применения. И еще… поддержу:

    <div class=«menu__item menu__item_position_first menu__item_state_current»>
    • +1
      То ли дело написать в Jade/Slim .item.current, а .first отбросить и использовать :first-child.
      • 0
        Но так же действительно проще, нет?
        • +1
          Фразой “то ли дело” имел в виду именно “вот так же проще”.
        • +3
          Так короче писать. Но так нужно учитывать набор допущений. Например, что первый пункт меню действительно первый в DOM-е, а не второй, потому, что первый скрыт JS-ом или используется под какой-нибудь бордер-разделитель. Или, что вы не поддерживаете IE6, в котором не работают селекторы вида .item.current и :first-child.

          Всегда можно вручную собрать элегантное решение под узкую конкретную задачу, но БЭМ он про то, что:
          — задачи с течением времени меняются прямо под ногами и решение должно выдерживать это с минимальным переписыванием
          — задач много и их надо делать на потоке, срезая углы на придумывании для каждой заковыристых элегантных короткостей (хотя я и сам их так люблю!)
          • 0
            От воторго БЭМ ну ни как не спасет.
            • 0
              а вы пробовали? ;-) нас немного спасает, но конечно не серебряная пуля вовсе
              • 0
                Да. Суть в том, что я всегда акцентировал внимание на ПРОЕКТАХ. И то что работает для x числа людей, не обязательно будет работать для y числа людей.
                • +1
                  А как вы пробовали и что не получилось? Интересно узнать, может мы что-то сможем посоветовать.
                  • 0
                    Сарказм?
                    • 0
                      Почему? У нас давно действует практика индивидуальных советов и ответов на вопросы — clubs.ya.ru/bem/replies.xml?item_no=1273 — мы в разной форме (текстом, по скайпу, лично) и с разными компаниями практикуем такое.
                      • +1
                        И это очень правильно — распространять понимание этой идеи.
                      • 0
                        Не так вас понял. Нет на самом деле, не однократно пытался испольовать бэм на потоке, и в средних проектах. Но это для меня тупиковый вариант. Главная причина — не просто. Мне проще руководствоваться принципами oocss и использовать при этом sass или stylus.

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

                        Прямо сейчас я работаю над сложнейшим интерфейсом, где одни и те же элементы выглядят по разному, и много не значительных на первый взгляд элементов. Приложение на JS фактически, там использование БЭМа было бы во вред как раз по времени. Тестирование и отладка… вопрос очень спорный.
                        • 0
                          Можно нескромный вопрос, а для вас БЭМ это css?
                          • 0
                            Нет.
                            • 0
                              Тогда я не понимаю, почему БЭМ будет мешать. Можете проблематику описать?
                        • +2
                          «Не просто», это уже вывод из каких-то более низкоуровневых причин и проблем. Вот мне как раз они интереснее. Что не просто, создавать файлы, или писать длинные селекторы, или разделять всё на блоки, элементы, модификаторы? Если есть возможность показать код проектов (хотя бы лично) было бы вообще круто, тогда более предметно можно разговаривать.

                          Чем для вас принципы OOCSS отличаются от БЭМ?

                          Использовать SASS или Stylus можно и с БЭМ: сама методология подразумевает возможность любых технологий реализации блоков (про это не плохо было в недавнем докладе для WebConf в Риге vimeo.com/53219242 + bem.info/articles/yandex-frontend-dev/), а в bem-tools есть поддержка и sass, и styl, и less.

                          Про свод правил и инструменты я не очень понял противопоставления. Почему или свод правил или инструменты? У нас есть и то и то — вместе только лучше работает.

                          Если приложение в большей степени на JS, то БЭМ вполне может помочь. У нас часть про клиентский JS не плохо проработана на практике (например, при создании n.maps.yandex.ru — тоже не простой интерфейс). Про это есть несколько докладов: events.yandex.ru/events/yasubbotnik/msk-jul-2012/talks/302/, events.yandex.ru/events/yasubbotnik/msk-sep-2012/talks/323/, events.yandex.ru/events/yasubbotnik/msk-sep-2012/talks/324/.
  • 0
    «пи с домиком и пи с душечкой»
    С «дужечкой» (от слова «дужка», «дуга», а не «душка»).
  • 0
    Думаю о такой штуке уже три года

    не хочется писать велосипед.
  • +1
    Тема обсуждений в комментариях скатилось в сторону BEM/не-BEM…

    Однако, на сколько я смог понять суть идеи, она сильно сходится с тем, что было предложено в Maxmertkit.
  • 0
    в посте теги все слиплись в один
  • 0
    Предположим, я хочу, чтобы все кнопки на сайте у меня выглядели не так, как это хочется автору блока, а в соответствии с единым, продуманным стилем.

    В этом случае вы делаете блок «кнопка-которая-должна-выглядеть-примерно-одинаково-везде» и вставляете её в любой блок где она вам нужна.
    В том же bembl есть блок b-link, который навешивается на большинство ссылок.

    Так же я искренне не понимаю зачем используя БЭМ:

    1. Использовать префиксы в названиях блоков;
    2. Отказываться от контекстной зависимости внутри блока;
    3. Отказываться от селекторов по псевдоклассам и псевдоэлементам.

    Методология она потому и методология, что является набором принципов, а не догм и синтаксических правил.
    • 0
      В этом случае вы делаете блок «кнопка-которая-должна-выглядеть-примерно-одинаково-везде»


      Вставляем (вернее заменяем) авторскую кнопку в авторском блоке на свою и получаем проблему поддержки своего форка авторского блока?
      • 0
        Если кнопка должна быть одинаковой везде (или хотя бы в 2-3 разных блоках) — делаем отдельный блок для кнопки.

        Если какая-то кнопка должна быть в авторском стиле — оставляем авторский стиль не примешивая к нему собственный.

        Что касается поддержки внешнего (к кнопке) блока, то тут важно понять следующее: блок это не ветка DOM дерева, а лишь её часть. Поддерживаться должна только она, причём из расчёта, что на неё можно приклеить хоть хвойные иголки, хоть листы дуба.
        О возможности смены листиков разработчика блока должны предупредить заранее, конечно.
  • 0
    Если вы, скажем, захотите добавить возможность перетаскивать табы drag'n'drop-ом, то просто добавите контракты drag/drop, что позволит сразу задействовать все те типовые функции, которые были для этой цели уже подготовлены.


    В БЭМ это делается смешиванием нескольких блоков/элементов на одной DOM-ноде. Делаете отдельный блок draggable и примешиваете его к любому другому блоку, который можно таскать.

    В этом случае отдельный блок отвечает за определённую функциональность и его можно использовать где угодно. Фактически, то, что вы описываете в статье про контракты, есть в БЭМ в виде миксов.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.