Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 136
О-о-о, значит, не только я считаю, что БЭМ стоит поперек горла CSS?
Пока я занимаю осторожную позицию, может я чего-то не знаю о БЭМ. Но ситуация такова, что я его не понимаю, я не понимаю, из чего следуют его преимущества и, самое главное, я не вижу этих преимуществ и на сайтах того же Яндекса. Одно дело — прочитать, как это меняет весь мир к лучшему и совсем другое — воочию увидеть эти изменения. А вообще меня больше интересует не насколько БЭМ плохой, а насколько хорошими могут быть альтернативы. БЭМ уже выполнил важную роль, он заставил об этом задуматься и говорить.
БЭМ не так плох, как вам кажется. И суть этого подхода лежит не в плоскости CSS, а в плоскости XML. Единственное, чего не хватило БЭМ-у (а может и людям, которые его используют), так это эволюционный переход от визуально-ориентированных структур к функционально-ориентированным. Надо описывать не то, что видишь, а то, что является сутью того, что видишь. Например, все кнопки во всех проектах можно всегда запаковывать в .actionBox, а не вставлять ситуативно в контейнеры, как обычно делают кодеры.
И цель БЭМа не в особом способе написании стилей, а в
* сокращение затрат на тестирование
* универсальная точка обмена информацией в абстрактном XML между разработчиками
* реализация слабосвязанной архитектуры
И цель БЭМа не в особом способе написании стилей, а в
* сокращение затрат на тестирование
* универсальная точка обмена информацией в абстрактном XML между разработчиками
* реализация слабосвязанной архитектуры
> эволюционный переход от визуально-ориентированных структур к функционально-ориентированным
Согласен всей душой. Те «контракты», о которых я говорил — это не только способ взаимодействия между HTML и JS, но также тот единый диалект, на котором верстальщики могут говорить с программистами.
> И цель БЭМа не в особом способе написании стилей, а в
Декларированная цель — не эквивалентно цели достигнутой. Поэтому в статье я коснулся практически всего, что вы перечислили. И реализации слабосвязной архитектуры (это вообще одна из целей контрактного программирования), и обмена информацией между разработчиками (к слову о би-домике), и затраты на тестирование (я, правда, больше говорил о рефакторинге, но технически у них почти одинаковые требования). Я, например, понимаю, как можно осуществлять реюзинг селениум-тестов на том варианте, что предложил я, но с трудом вижу их для БЭМ.
Согласен всей душой. Те «контракты», о которых я говорил — это не только способ взаимодействия между HTML и JS, но также тот единый диалект, на котором верстальщики могут говорить с программистами.
> И цель БЭМа не в особом способе написании стилей, а в
Декларированная цель — не эквивалентно цели достигнутой. Поэтому в статье я коснулся практически всего, что вы перечислили. И реализации слабосвязной архитектуры (это вообще одна из целей контрактного программирования), и обмена информацией между разработчиками (к слову о би-домике), и затраты на тестирование (я, правда, больше говорил о рефакторинге, но технически у них почти одинаковые требования). Я, например, понимаю, как можно осуществлять реюзинг селениум-тестов на том варианте, что предложил я, но с трудом вижу их для БЭМ.
Соглашусь, БЭМ не так плох. Но я считаю что БЭМ — это внутре корпоративные правила больше, нежели какая-то отличная методология (или даже парадигма).
* сокращение затрат на тестирование — Не согласен, потому как не понимаю как ЭТО может мне помочь с тестированием кода?
* универсальная точка обмена информацией в абстрактном XML между разработчиками — Согласен.
* реализация слабосвязанной архитектуры — Согласен.
Но в целом тестирование тут не причем. Затраты на тестирование в html/css и сегодня, довольно увлекательный процесс.
* сокращение затрат на тестирование — Не согласен, потому как не понимаю как ЭТО может мне помочь с тестированием кода?
* универсальная точка обмена информацией в абстрактном XML между разработчиками — Согласен.
* реализация слабосвязанной архитектуры — Согласен.
Но в целом тестирование тут не причем. Затраты на тестирование в html/css и сегодня, довольно увлекательный процесс.
:) Сокращение затрат на тестирование — эффект от слабосвязанной архитектуры. Вы правите код в одном месте и в одном же месте проверяете его работоспособность без боязни что-то поломать в других местах.
Давайте разберемся, что же такое БЭМ? Это способ построить абстракцию более высокого уровня, чтобы иметь возможность потом превратить ее в конкретный код определенной технологии. Кому это полезно? Да всем. Люди перестают мыслить низменными категориями и выходят на более абстрактный уровень, который проще для восприятия и дешевле для изучения. Вместо разброда и шатаний мы получаем единообразие мышления команды, и она идет не на языке HTML, CSS или JS, а на XML.
Негатив БЭМа в том, что он в текущем виде визуально-ориентированный. Элементы описываются по визуальным признакам, а не по логическим. И по мере накопления визуальных различий качество самого XML будет падать.
Давайте разберемся, что же такое БЭМ? Это способ построить абстракцию более высокого уровня, чтобы иметь возможность потом превратить ее в конкретный код определенной технологии. Кому это полезно? Да всем. Люди перестают мыслить низменными категориями и выходят на более абстрактный уровень, который проще для восприятия и дешевле для изучения. Вместо разброда и шатаний мы получаем единообразие мышления команды, и она идет не на языке HTML, CSS или JS, а на XML.
Негатив БЭМа в том, что он в текущем виде визуально-ориентированный. Элементы описываются по визуальным признакам, а не по логическим. И по мере накопления визуальных различий качество самого XML будет падать.
Элементы описываются по визуальным признакам, а не по логическим.
Вот! Вы хорошо сформулировали, что у вызывало у меня дискомфорт при попытках освоения БЭМ без особой цели.
Сам по себе БЭМ не диктует визуально-ориентированность, просто больше всего примеров с визуальными блоками, т.к. это понятнее всего. А на деле мы во всю делаем всякие абстрактные блоки, которые даже не имеют никакого визуального представления. Но при этом они по прежнему реализуются в нескольких технологиях (например, клиентский js, тесты, документация, примеры).
Сам по себе конечно же не диктует. Но именно к нему скатываются разработчики
Возьмем простой пример.
К чему вообще такой элемент как <e:column>? Это же сугубо визуальное определение. Это один из модификаторов, но никак не елемент. Я понимаю, что это только пример, и что в реальной жизни все не так.
Научиться правильно именовать сущности, которые мы видим перед собой — вот ключ к успеху, и не только применительно к БЭМ
Возьмем простой пример.
К чему вообще такой элемент как <e:column>? Это же сугубо визуальное определение. Это один из модификаторов, но никак не елемент. Я понимаю, что это только пример, и что в реальной жизни все не так.
Научиться правильно именовать сущности, которые мы видим перед собой — вот ключ к успеху, и не только применительно к БЭМ
Вы естественной (и внезапной) личной эволюцией переросли CSS, и ваша дорога привела вас в XAML, который делали с похожим возмущением и идеологией. Велкам к UX-неграм нового поколения =)
Я уже был в доме под названием XAML, в портфолио немало Silverlight/WPF-проектов и оттуда я ушел, так что дорога в прямо противоположном направлении))
Вы не могли бы всем донести, чего вам в XAML не хватило, с акцентом на упомянутые в данной статье мысли? Это действительно интересно, видно, что вы глубоко копаете тему, и вообще в тренде.
Если ни CSS + HTML5 ни XAML не удовлетворяют некой нужной идее, то нам стоит ждать какое-то неожиданно-новое решение неизвестно от кого под интерес кодеров, либо развитие одного из существующих подходов.
Я прошу вас выступить в комментарии как аналитику, или отдельный пост сделать в целом об индустрии с упором на критику XAML против CSS, и оба против реальных потребностей кодеров.
Если ни CSS + HTML5 ни XAML не удовлетворяют некой нужной идее, то нам стоит ждать какое-то неожиданно-новое решение неизвестно от кого под интерес кодеров, либо развитие одного из существующих подходов.
Я прошу вас выступить в комментарии как аналитику, или отдельный пост сделать в целом об индустрии с упором на критику XAML против CSS, и оба против реальных потребностей кодеров.
Мне кажется, что верстальщики вообще не должны выдумывать имена классов. Обеспечение интерфейсов между HTML и JS должно осуществляться проектировщиками…
Верстальщики не должны, возможно, а если вспомнить что еще есть менеджмент и дизайнеры? Их бы вообще повыгонять, эти ребята больше всех портят хорошие архитектуры. БЭМ считает что технологии вторичны, да, это несет некоторые архитектурные проблемы, но и дает много возможностей, среди которых быстрый старт работы нового разработчика, а тут так оп, и все имена класов нужно согласовывать с… проектировщиком. Качество? А скорость? А согласованость проектировщиков?..
Поймите меня правильно, я утрирую, но все же.
Верстальщики не должны, возможно, а если вспомнить что еще есть менеджмент и дизайнеры? Их бы вообще повыгонять, эти ребята больше всех портят хорошие архитектуры. БЭМ считает что технологии вторичны, да, это несет некоторые архитектурные проблемы, но и дает много возможностей, среди которых быстрый старт работы нового разработчика, а тут так оп, и все имена класов нужно согласовывать с… проектировщиком. Качество? А скорость? А согласованость проектировщиков?..
Поймите меня правильно, я утрирую, но все же.
Задача нового разработчика — не создавать новые проблемы. И если каждый из них будет выдавать свое видение тех же логинов и форм, то это не сулит ничего хорошего. С точки зрения быстрого старта я вижу все предельно просто. Новый разработчик получает годами и многими умами выпестованные гайдлайны. С высокой степенью вероятности он может ими проникнуться и с легкостью ввинтится в слаженную работу. Можно вполне допустить, что он наворотит дел и не всегда будет следовать советам, но это опять же все легко контролируется и рефакторится. Появился класс с неизвестным именем — внимание. Это либо новая гениальная идея для внутренних стандартов, либо фейл.
Все что вы написали, сводится к тому, что одни классы используются для стилей (._tabs, .tab) а другие (.item, .container) для манипуляций с dom.
А почему БЭМ против контекстности? Наскольно я понимаю, она вполне возможна, другое дело, что верстка абсолютно независимыми блоками делает рендер очень быстрым, и в том же Яндексе ею начали активно пользоваться после того как долго мучались с производительностью новой почты (кажется – neo2).
Совершенно верно, никаких категоричных запретов на контекстную зависимость в БЭМ нет. Просто нужно понимать, что она даёт и что забирает.
Забирает:
— производительность
— устойчивость к модификациям вида «перенести это в _таком же_ виде в другое место»
Даёт:
— меньше писать, т.к. не надо в каждом месте повторять что-то точечно, а можно модифицировать контекст
Забирает:
— производительность
— устойчивость к модификациям вида «перенести это в _таком же_ виде в другое место»
Даёт:
— меньше писать, т.к. не надо в каждом месте повторять что-то точечно, а можно модифицировать контекст
нет никакой существенной разницы между .tabbed ._tabs .item {…} и .tabbed_tabs__item {…}Вы точно представляете как работает selector-engine?
Ведь весь тот код, который всегда хорошо работал с селектором ".item", для самых разных виджетов, перестал работатьЗачем вам выбирать итемы разных сущностей?
> Вы точно представляете как работает selector-engine?
Я в самом начале статьи обрисовал свой уровень претензий на звание эксперта. Если Вы меня поправите, то сильно тем самым обяжете.
> Зачем вам выбирать итемы разных сущностей?
Реюзинг. Большое количество различных сущностей обладает схожим поведением. Списки, дропдауны, гриды, табы, меню и т.п. помимо своей специфики имеют общее поведение — они являются контейнерами некоторых элементов. Есть масса типовых операций, которая может быть совершена с такими элементами. Скажем, удаление элемента с индексом X. Такой метод пишется единожды и замечательно работает для всех перечисленных контролов. Все это давно существует в большинстве языков программирования, почему это не должно сработать в данном случае?
Я в самом начале статьи обрисовал свой уровень претензий на звание эксперта. Если Вы меня поправите, то сильно тем самым обяжете.
> Зачем вам выбирать итемы разных сущностей?
Реюзинг. Большое количество различных сущностей обладает схожим поведением. Списки, дропдауны, гриды, табы, меню и т.п. помимо своей специфики имеют общее поведение — они являются контейнерами некоторых элементов. Есть масса типовых операций, которая может быть совершена с такими элементами. Скажем, удаление элемента с индексом X. Такой метод пишется единожды и замечательно работает для всех перечисленных контролов. Все это давно существует в большинстве языков программирования, почему это не должно сработать в данном случае?
Тут встает вопрос переопределения поведения методов. Например, я хочу, чтобы табы, работая как контейнер с элементами, добавляли новые элементы (табы) не в конец списка табов, как при стандартном поведении, а в начало списка табов. Для этого придется либо изменять изначальное поведение контейнеро-элементов, либо копипастить аналог. То есть ООП (в данном случае наследования) нету в должной степени. Или я что-то неправильно понял?
1) Предпочтение селекторам классов перед остальными — одна из основных рекомендаций БЭМ.
2) Модель БЭМ избыточна.
3) Можно группировать семантически близкие элементы, если используете их в CSS.
Пример из бутстрапа:
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;
}
К сожалению, пока БЭМа нет за пределами яндекса.
Я имею ввиду, что не смотря на подробное описание идей и наличия в ней здравого смысла, для большинства разработчиков вне яндекса БЭМ — это префикс b_, который добавляется вручную ко всем именам классов вне зависимости от от того есть ли на проекте другие сущности, кроме блока. При этом в коде во всю используются вложенные селекторы, селекторы тэгов и проч.
И да, к чему эта ссылка?
И да, к чему эта ссылка?
Я глубоко сомневаюсь, что во всех перечисленных проектах используется БЭМ-тулз. А без него это уже просто вёрстка независимыми блоками. Кроме того, интернет (или хотя бы рунет) не ограничивается указанными проектами. Тысячи БЭМ-подражателей жарят адовый код, не вникая в подробности методологии. Не надо меня убеждать, что БЭМ хорош. Это я знаю не хуже вас. Но факт остаётся фактом: на данный момент мало кто понимает суть метода.
Я глубоко сомневаюсь, что во всех перечисленных проектах используется БЭМ-тулз. А без него это уже просто вёрстка независимыми блоками.БЭМ — это методология, а не набор инструментов. Выросшая из и основанная на понятии независимых блоков.
Тысячи БЭМ-подражателей жарят адовый код, не вникая в подробности методологии. Не надо меня убеждать, что БЭМ хорош. Это я знаю не хуже вас. Но факт остаётся фактом: на данный момент мало кто понимает суть метода.Это уже, извините, проблемы негров. Для использования БЭМ в полную силу нужно обладать чуть большим набором компетенций, чем среднестатистический веб-мастер.
Это уже, извините, проблемы негров
Вот эти самые негры сейчас и говорят вам, что БЭМ никому не нужен. И именно этим неграм вы пытаетесь доказать все прелести метода.
Никому ничего не хотел доказывать. Я просто хотел сказать, что создатели БЭМ — очень неглупые люди с огромным опытом, решающие самые разнообразные по сложности и необычности задачи. Создание интерфейсов нуждается в системном подходе и команда БЭМ просто предлагает свой.
А нужна линеграм такая методология или нет — решать только неграм вам, и не нужно говорить что БЭМ не нужен никому.
А нужна ли
В Mail.ru есть bem-tools :-) Может быть как-нибудь расскажем!
Да, нет. Если смотреть в цифрах. Реально он пока держится на яндексе и патриотизме. Но замечу, сама методология хороша. Хотя как по мне oocss в разы лучше!
БЭМ в таком виде как его представляют в яндекс необходим только яндексу.
bem-tools — возможно. БЭМ как методология — точно нет.
Ваше утверждение немного конфликтует с тем, что к нам на конференциях подходят посторонние люди и говорят, что у них есть необходимость в подобной БЭМ методологии (а также в наборе инструментов и готовых блоков).
Абсурдно спорить с тем, что БЭМ появился как решение конкретных проблем в Яндексе (и продолжает нами развиваться тоже для этого же) — мы не спорим ;-) Вот только это не противоречит никак тому, что всё это применимо в других проектах — нужно всего лишь преодолеть порог входа!
Абсурдно спорить с тем, что БЭМ появился как решение конкретных проблем в Яндексе (и продолжает нами развиваться тоже для этого же) — мы не спорим ;-) Вот только это не противоречит никак тому, что всё это применимо в других проектах — нужно всего лишь преодолеть порог входа!
Применимо-то много что много где. Вопрос в том, оправдано ли преодоление порога входа и использование в проектах того или иного масштаба. Есть ли нижний предел масштабируемости? Бог с ним с порогом входа, но стоит ли использовать БЭМ при верстке шаблона какой-нибудь визитки? Зависит ли целесообразность использования от того будет этих визиток одна или сотня, с минимальными различиями в шаблонах?
Конечно нижний предел масштабируемости есть. Его тяжело сформулировать точно, т.к. у нас нет никаких едениц измерения для размера и сложности проекта. Если говорить примерно, то, безусловно, если вам сейчас нужно сделать один сайтик и больше их не делать никогда, то не надо тратить время на преодоление порога входа. Если же вы хотите остаться в профессии на долго, то скорее всего (если всё будет складываться) размер и сложность проектов со временем будут только расти (в идеале расти бесконечно ;-) ) — а это значит, что рано или поздно, вы преодолеете любой нижний предел. Так почему бы не начать сразу?! ;-)
Если отбросить вопрос порога входа и рассматривать только применимость, то у меня вот такие мысли. Есть два типа сложных инструментов (инструментов с высоким порогом входа):
1) узкоспециальные — например, какой-нубудь инструмент для обслуживания велосипеда — сложность там обусловлена предметной областью, т.е. как раз применимы они только для определённых задач
2) универсальные — например, швейцарский нож — сложность обусловлена тем как всё сложно понапихано в одну штуку, но применимость (после того как овладел) вполне универсальная (даже в велике можно будет что-то покрутить)
Мы всю дорогу проектировали БЭМ как раз как более универсальный инструмент и вот есть пример применения его для той же визитки: github.com/mishanga/bem-vcard + mishanga.pro
Но это конечно не означает, что он универсален до абсолюта — продолжая аналогию, для некоторых задач нужен не швейцарский нож, а бутылка воды.
1) узкоспециальные — например, какой-нубудь инструмент для обслуживания велосипеда — сложность там обусловлена предметной областью, т.е. как раз применимы они только для определённых задач
2) универсальные — например, швейцарский нож — сложность обусловлена тем как всё сложно понапихано в одну штуку, но применимость (после того как овладел) вполне универсальная (даже в велике можно будет что-то покрутить)
Мы всю дорогу проектировали БЭМ как раз как более универсальный инструмент и вот есть пример применения его для той же визитки: github.com/mishanga/bem-vcard + mishanga.pro
Но это конечно не означает, что он универсален до абсолюта — продолжая аналогию, для некоторых задач нужен не швейцарский нож, а бутылка воды.
> Вы точно представляете как работает selector-engine?
Я в самом начале статьи обрисовал свой уровень претензий на звание эксперта. Если Вы меня поправите, то сильно тем самым обяжете.
> Зачем вам выбирать итемы разных сущностей?
Реюзинг. Большое количество различных сущностей обладает схожим поведением. Списки, дропдауны, гриды, табы, меню и т.п. помимо своей специфики имеют общее поведение — они являются контейнерами некоторых элементов. Есть масса типовых операций, которая может быть совершена с такими элементами. Скажем, удаление элемента с индексом X. Такой метод пишется единожды и замечательно работает для всех перечисленных контролов. Все это давно существует в большинстве языков программирования, почему это не должно сработать в данном случае?
Я в самом начале статьи обрисовал свой уровень претензий на звание эксперта. Если Вы меня поправите, то сильно тем самым обяжете.
> Зачем вам выбирать итемы разных сущностей?
Реюзинг. Большое количество различных сущностей обладает схожим поведением. Списки, дропдауны, гриды, табы, меню и т.п. помимо своей специфики имеют общее поведение — они являются контейнерами некоторых элементов. Есть масса типовых операций, которая может быть совершена с такими элементами. Скажем, удаление элемента с индексом X. Такой метод пишется единожды и замечательно работает для всех перечисленных контролов. Все это давно существует в большинстве языков программирования, почему это не должно сработать в данном случае?
Ка-то внезапно статья оборвалась. Думал будет какое-то предложение обсуждения типовых интерфейсов, может фреймворк или библиотека.
А поскольку БЭМ-стиль в проектах у меня стал появляться все чаще, я почувствовал острую необходимость осмыслить, наконец, свое отношение к организации стилей.
А у вас появлялся бемтулс яндекса(или иное их программное обеспечение которое позволяет всем их сотрудникам работать вместе) если вы рассуждаете о ихней структуре блоков и о том как они их изменяют\добавляют\модифицируют.
В том-то и проблема, что нет. Я прекрасно понимаю, что Яндек вряд ли стал бы себе создавать проблемы. Но, как я обозначил в своем сомнении номер 1, меня настораживает то, что многие начинают использовать БЭМ бессистемно и бездумно. И поэтому в проектах возникает не система мер направленная на что-там, а просто одни только БЭМ-стили. Это, естественно, не проблема БЭМ.
Верстальщиков вы не сможете научить\образумить это придет к ним только с опытом… Вам нужно было посмотреть недавний матер-класс Юрия Артюха, и у вас бы стало намного меньше вопросов с тем кодом который вам присылают или наоборот много к верстальщику который делает не так как нужно:)
А про яндекс лучше писать после ознакомления с их bemtools.
А про яндекс лучше писать после ознакомления с их bemtools.
Добавлю, что настоящая мощь использования методологии приходит, когда вы начинаете писать js в BEM-терминах bem.github.com/bem-bl/sets/common-desktop/i-bem/i-bem.ru.html.
Добавлю, что ещё можно писать шаблоны с помощью 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
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
Вторая ссылка актуальнее этого: github.com/bem/bemhtml/blob/master/common.docs/reference/reference.ru.md?
Там просто в более человеко-ориентированном виде :)
Там просто в более человеко-ориентированном виде :)
Прикольно, но я уже как 5 лет двигаюсь в этом же направлении.
Структурно-ориентированное программирование + событийная модель = невероятно удобная разработка.
Структурно-ориентированное программирование + событийная модель = невероятно удобная разработка.
Я последнее время думаю над этим 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.
А пока набиваю руку на простых проектах. По мере возможности буду об этом писать :)
Шаблонизатор 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.
А пока набиваю руку на простых проектах. По мере возможности буду об этом писать :)
Guderian, мне очень нравится ваш системный подход — в своей работе с таким не сталкивался, но интуитивно хочется делать что-то подобное — подскажите — где набраться подобного опыта?
поскольку нет никакой существенной разницы между .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>
Думаю тут объяснять нечего.
>>>Предположим, я хочу, чтобы все кнопки на сайте у меня выглядели не так, как это хочется автору блока, а в соответствии с единым, продуманным стилем
Кто вам мешает объявить кнопку блоком, а потом дописывать ей модификаторы, чтобы где-то отрисовать кнопку побольше/поменьше. Разные блоки могут вкладываться в друг друга — А в Б, или Б в А, и это основа методологии. Ей богу, вы что-то не поняли.
Кто вам мешает объявить кнопку блоком, а потом дописывать ей модификаторы, чтобы где-то отрисовать кнопку побольше/поменьше. Разные блоки могут вкладываться в друг друга — А в Б, или Б в А, и это основа методологии. Ей богу, вы что-то не поняли.
Именно так. Идея «интерфейсов» или «контрактов» отлично выражается в БЭМ-терминах (мы этим сами пользуемся). Можно это делать не только с помощью модификаторов, но и с помощью дополнительных примиксованных блоков. При этом происходит явное отделение, когда нам нужно заводить интерфейс, а когда нет. Подробнее про миксы можно послушать в докладе events.yandex.ru/events/yasubbotnik/msk-sep-2012/talks/327/
БЭМ в первую очередь это верстка с использованием независимых блоков, а все остальное вторично. Если у вас огромный проект и на нем работает большой штат верстальщиков то будет оправдано использовать БЭМ в полной мере. Если вы одиночка или если делаете проекты для разных компаний то стоит осмыслить концепцию и на ее основе уже делать что то свое, удобное вам.
По своему опыту могу сказать что верстка с использованием независимых блоков это обязателньое условие хорошо сделанного проекта. Иначе любой средний по величине проект станет просто кашей не поддающейся модификациям и редизайну без отборного мата ))
По своему опыту могу сказать что верстка с использованием независимых блоков это обязателньое условие хорошо сделанного проекта. Иначе любой средний по величине проект станет просто кашей не поддающейся модификациям и редизайну без отборного мата ))
В основе БЭМ лежат независимые блоки. Вы можете использовать свою нотацию (с дефисами и шлюхами). Почитайте это: pokrovskii.com/obektno-orientirovannaya-verstka/. Максим в своё время хорошо описал то, что сейчас является сутью БЭМ.
Но ведь другого решения нет. Нельзя опираться на имена тэгов. Вложенные селекторы работают дольше. Одинаковых элементов на странице может быть много.
Это совсем не поперёк идеи классов. Ведь блоки по нескольку раз используются на странице. Однако вы чертовски правы. К этому просто никто не готов.
Это совсем не поперёк идеи классов. Ведь блоки по нескольку раз используются на странице. Однако вы чертовски правы. К этому просто никто не готов.
Не могу сказать за вложенные селекторы т.к. не видел тестов но вот за тэги есть тест Виталия Харисова. Разница колоссальна. Вот бы увидеть что-то и для вложенных селекторов.
Не боитесь, что к тому моменту, когда вы увидите причины не употреблять звёздочку, у вас на руках будет огромный проект с кучей кода и большим количеством элементов на странице? И его надо будет полностью переписать, т.к. на таких объёмах уже будут глазом видны тормоза (кстати, про измерения не «на глазок» можно посмотреть events.yandex.ru/events/yasubbotnik/kiev-may-2011/talks/232/ ).
Я понимаю, что аргумент звучит в духе «такие проблемы только у Яндекса» и «маленьким проектам это не нужно». Но я просто хочу намекнуть задуматься, а стоит ли проверять на своём опыте, наступите ли вы на эти же грабли.
Я понимаю, что аргумент звучит в духе «такие проблемы только у Яндекса» и «маленьким проектам это не нужно». Но я просто хочу намекнуть задуматься, а стоит ли проверять на своём опыте, наступите ли вы на эти же грабли.
В заметке написано:
Наглядный пример: 30 тысяч div'ов на странице, селекторы заканчиваются на .text (рефлоу 5 секунд) и на div (рефлоу 37 секунд, осторожно! браузер замерзает, а потом оттаивает).
И там же ссылки на примеры, можете замерить сами в разных браузерах.
Наглядный пример: 30 тысяч div'ов на странице, селекторы заканчиваются на .text (рефлоу 5 секунд) и на div (рефлоу 37 секунд, осторожно! браузер замерзает, а потом оттаивает).
И там же ссылки на примеры, можете замерить сами в разных браузерах.
Консорциум не был готов к такому быстрому развитию технологии, и даже представить себе не мог, что сейчас разработчики делают с помощью HTML/CSS/JS, поэтому приходится по своему решать проблемы, и пересматривать работу с теми же селекторами.
ID обязаны быть уникальными в пределах документа. В основе же БЭМ, одним из принципов, всегда лежала идея о произвольном повторении произвольных блоков на странице. Скорее можно сказать, что БЭМ стоит поперёк горла идее каскадных селекторов, т.к. классы то используются как раз по назначению. Но это тоже не совсем так, про контекстную зависимость уже писал тут выше по треду — habrahabr.ru/post/171437/#comment_5951255 — у неё есть особенности, но БЭМ её никак не запрещает (просто мы подробно рассказываем в чём минусы и получается так, что в реальных проектах она мало используется).
Отдельно немного в тему Консорциума — habrahabr.ru/company/yandex/blog/156389/
Отдельно немного в тему Консорциума — habrahabr.ru/company/yandex/blog/156389/
Я скорее на стороне тех людей, которые считают, что веб-разработчики это не дети и вполне могут иногда подумать. Но если нужны строгие правила, то легко — пельмени можно никогда не солить, каскад можно никогда не применять. А тот, кто почувствует, что ему эти правила жмут, тому и строгая инструкция не нужна.
Бардак, это то что «никто ни с кем ни о чём не договаривается». В основе БЭМ-методологии как раз одной из идей лежит коллективное владение кодом и обсуждение архитектуры людьми разной специализации (т.к. одни и теже БЭМ-сущности существуют в разных технологиях). А когда люди, работая над общим проектом, начинают больше общаться, то там и побочных ещё бонусов куча всплывает!
P.S. Я предлагаю сократить до Бардак Элемент Модификатор ;-) а то такая смешная шутка, а никто повторить не может.
P.S. Я предлагаю сократить до Бардак Элемент Модификатор ;-) а то такая смешная шутка, а никто повторить не может.
Позвольте не согласиться (хотя там «не» затесалось и я может не правильно понял). Если код писал человек со стороны, то наличие любых соглашений (например, БЭМ) будет положительно сказываться на принятии этого кода (хоть что-то знакомое будет, хотя бы общие принципы). Если же никаких соглашений нет (пишем как хотим или как наиболее коротко и элегантно), то вероятность не понять такой код от стороннего человека только возрастает.
+1, при генеративном подходе запросто можно заменять те участки, где раньше был БЭМ на код, упакованный в base64, например. И вместо длинного БЭМ-спича будет «x3c», например. И их можно генерировать из привычных глазу селекторов точно также, как из них можно генерировать БЭМ.
А в каком тогда смысле вы упоминали обфуксацию и сжатие? Имхо, читаемые пользователем селекторы при генеративном подходе не нужны в принципе. Если только это не контракты.
Ключевой я предполагал не обфускацию, а генеративность. Есть осмысленное, человеколюбивое, каскадное описание стиля и есть продуцирующие правила. Одно генерит бэм или супер-бэм имена стилей и работает для отладочных сборок, другая — результат обфускации для релизных. Пишешь так, как нравится, получаешь то, что хочешь в данный момент времени.
Яндекс. Почему то, что подходит крупной компании с гигантским штатом и небольшим количеством однотипных проектов должно так же хорошо работатьЭто по-вашему, «небольшое количество однотипных проектов» www.yandex.ru/all? В «Яндексе», кроме того, ещё и интранет существует, очень развитый.
Мне одному кажется, что «техника априори верна всегда и везде, поскольку за ней стоит Яндекс» — это очень странное предположение и что естественно предполагать как раз обратное?
Я рад что не у одного меня такие мысли. Хотя методология БЭМ хороша. Как инструмент он имеет довольно узкую нисшу применения. И еще… поддержу:
<div class=«menu__item menu__item_position_first menu__item_state_current»>Но так же действительно проще, нет?
Так короче писать. Но так нужно учитывать набор допущений. Например, что первый пункт меню действительно первый в DOM-е, а не второй, потому, что первый скрыт JS-ом или используется под какой-нибудь бордер-разделитель. Или, что вы не поддерживаете IE6, в котором не работают селекторы вида .item.current и :first-child.
Всегда можно вручную собрать элегантное решение под узкую конкретную задачу, но БЭМ он про то, что:
— задачи с течением времени меняются прямо под ногами и решение должно выдерживать это с минимальным переписыванием
— задач много и их надо делать на потоке, срезая углы на придумывании для каждой заковыристых элегантных короткостей (хотя я и сам их так люблю!)
Всегда можно вручную собрать элегантное решение под узкую конкретную задачу, но БЭМ он про то, что:
— задачи с течением времени меняются прямо под ногами и решение должно выдерживать это с минимальным переписыванием
— задач много и их надо делать на потоке, срезая углы на придумывании для каждой заковыристых элегантных короткостей (хотя я и сам их так люблю!)
От воторго БЭМ ну ни как не спасет.
а вы пробовали? ;-) нас немного спасает, но конечно не серебряная пуля вовсе
Да. Суть в том, что я всегда акцентировал внимание на ПРОЕКТАХ. И то что работает для x числа людей, не обязательно будет работать для y числа людей.
А как вы пробовали и что не получилось? Интересно узнать, может мы что-то сможем посоветовать.
Сарказм?
Почему? У нас давно действует практика индивидуальных советов и ответов на вопросы — clubs.ya.ru/bem/replies.xml?item_no=1273 — мы в разной форме (текстом, по скайпу, лично) и с разными компаниями практикуем такое.
Не так вас понял. Нет на самом деле, не однократно пытался испольовать бэм на потоке, и в средних проектах. Но это для меня тупиковый вариант. Главная причина — не просто. Мне проще руководствоваться принципами oocss и использовать при этом sass или stylus.
Что касается не зависимости блоков и прочее… тут я, склонен любить методологию, но в большом проекте свод правил дает больше приимуществ нежели инструменты. Вот я и говорю, что мой личный опыт, говорит мне, бэм не удобен. И так же я говорил, что бэм хорош как внутрикорпоративная этика.
Прямо сейчас я работаю над сложнейшим интерфейсом, где одни и те же элементы выглядят по разному, и много не значительных на первый взгляд элементов. Приложение на JS фактически, там использование БЭМа было бы во вред как раз по времени. Тестирование и отладка… вопрос очень спорный.
Что касается не зависимости блоков и прочее… тут я, склонен любить методологию, но в большом проекте свод правил дает больше приимуществ нежели инструменты. Вот я и говорю, что мой личный опыт, говорит мне, бэм не удобен. И так же я говорил, что бэм хорош как внутрикорпоративная этика.
Прямо сейчас я работаю над сложнейшим интерфейсом, где одни и те же элементы выглядят по разному, и много не значительных на первый взгляд элементов. Приложение на JS фактически, там использование БЭМа было бы во вред как раз по времени. Тестирование и отладка… вопрос очень спорный.
Можно нескромный вопрос, а для вас БЭМ это css?
«Не просто», это уже вывод из каких-то более низкоуровневых причин и проблем. Вот мне как раз они интереснее. Что не просто, создавать файлы, или писать длинные селекторы, или разделять всё на блоки, элементы, модификаторы? Если есть возможность показать код проектов (хотя бы лично) было бы вообще круто, тогда более предметно можно разговаривать.
Чем для вас принципы 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/.
Чем для вас принципы 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/.
«пи с домиком и пи с душечкой»С «дужечкой» (от слова «дужка», «дуга», а не «душка»).
Думаю о такой штуке уже три года
не хочется писать велосипед.
не хочется писать велосипед.
Тема обсуждений в комментариях скатилось в сторону BEM/не-BEM…
Однако, на сколько я смог понять суть идеи, она сильно сходится с тем, что было предложено в Maxmertkit.
Однако, на сколько я смог понять суть идеи, она сильно сходится с тем, что было предложено в Maxmertkit.
в посте теги все слиплись в один
Предположим, я хочу, чтобы все кнопки на сайте у меня выглядели не так, как это хочется автору блока, а в соответствии с единым, продуманным стилем.
В этом случае вы делаете блок «кнопка-которая-должна-выглядеть-примерно-одинаково-везде» и вставляете её в любой блок где она вам нужна.
В том же bembl есть блок b-link, который навешивается на большинство ссылок.
Так же я искренне не понимаю зачем используя БЭМ:
1. Использовать префиксы в названиях блоков;
2. Отказываться от контекстной зависимости внутри блока;
3. Отказываться от селекторов по псевдоклассам и псевдоэлементам.
Методология она потому и методология, что является набором принципов, а не догм и синтаксических правил.
В этом случае вы делаете блок «кнопка-которая-должна-выглядеть-примерно-одинаково-везде»
Вставляем (вернее заменяем) авторскую кнопку в авторском блоке на свою и получаем проблему поддержки своего форка авторского блока?
Если кнопка должна быть одинаковой везде (или хотя бы в 2-3 разных блоках) — делаем отдельный блок для кнопки.
Если какая-то кнопка должна быть в авторском стиле — оставляем авторский стиль не примешивая к нему собственный.
Что касается поддержки внешнего (к кнопке) блока, то тут важно понять следующее: блок это не ветка DOM дерева, а лишь её часть. Поддерживаться должна только она, причём из расчёта, что на неё можно приклеить хоть хвойные иголки, хоть листы дуба.
О возможности смены листиков разработчика блока должны предупредить заранее, конечно.
Если какая-то кнопка должна быть в авторском стиле — оставляем авторский стиль не примешивая к нему собственный.
Что касается поддержки внешнего (к кнопке) блока, то тут важно понять следующее: блок это не ветка DOM дерева, а лишь её часть. Поддерживаться должна только она, причём из расчёта, что на неё можно приклеить хоть хвойные иголки, хоть листы дуба.
О возможности смены листиков разработчика блока должны предупредить заранее, конечно.
Если вы, скажем, захотите добавить возможность перетаскивать табы drag'n'drop-ом, то просто добавите контракты drag/drop, что позволит сразу задействовать все те типовые функции, которые были для этой цели уже подготовлены.
В БЭМ это делается смешиванием нескольких блоков/элементов на одной DOM-ноде. Делаете отдельный блок draggable и примешиваете его к любому другому блоку, который можно таскать.
В этом случае отдельный блок отвечает за определённую функциональность и его можно использовать где угодно. Фактически, то, что вы описываете в статье про контракты, есть в БЭМ в виде миксов.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Объектно-ориентированный дизайн… в CSS