Если вы, скажем, захотите добавить возможность перетаскивать табы drag'n'drop-ом, то просто добавите контракты drag/drop, что позволит сразу задействовать все те типовые функции, которые были для этой цели уже подготовлены.
В БЭМ это делается смешиванием нескольких блоков/элементов на одной DOM-ноде. Делаете отдельный блок draggable и примешиваете его к любому другому блоку, который можно таскать.
В этом случае отдельный блок отвечает за определённую функциональность и его можно использовать где угодно. Фактически, то, что вы описываете в статье про контракты, есть в БЭМ в виде миксов.
Наглядный пример: 30 тысяч div'ов на странице, селекторы заканчиваются на .text (рефлоу 5 секунд) и на div (рефлоу 37 секунд, осторожно! браузер замерзает, а потом оттаивает).
И там же ссылки на примеры, можете замерить сами в разных браузерах.
Почему вы думаете, что without-padding это padding: 0? И theme_ffffff вполне может быть с градиентами и фоновыми картинками.
Отличие класса от inline стиля состоит в том, что ему может соответствовать разный CSS как в пределах разных страниц одного проекта, так и в пределах разных проектов.
Ну и названия without-padding и theme_ffffff хотя и говорящие, но не самые лучшие.
В случае с БЭМ мы упремся в бесконечное число классов которые придется навешивать на каждый элемент.
Нет, не упрёмся.
В статье было неверное утверждение ро невозможность использования каскада в БЭМ, от которого пошло непонимание. Я ответил на это тут: habrahabr.ru/post/151931/#comment_5165248
Я правильно понимаю, что придется при смене схемы кроме добавления одного класса для body еще и переписывать классы у всех элементов?
Нет, не правильно. Можно реализовать цветовые схемы через модификатор theme у корневого блока page, задав для body классы page и page_theme_bear и указав изменения внешнего вида вложенных блоков отталкиваясь от этого модификатора.
Пытаясь весь этот цирк форсировать силами своих специалистов на различных конференциях яндекс заставляет выглядеть их просто глупо, искренне сочувствую.
БЭМ в Яндексе занимается группа энтузиастов, которые его развивают и по мере своих сил распространяют вне Яндекса.
В Яндексе никто никого не заставляет выступать на конференциях, наоборот сложно оторвать людей от работы и уговорить сделать доклад, вместо того, чтобы код писать.
Если вёрстка делается один раз и больше никогда не меняется — можно верстать и через .search_bar >…
Но если в любой момент структура блока может измениться (в один блок сложиться другой; добавятся дополнительные обёртки или наоборот уберутся; etc), то вам придётся каждый раз переписывать эти дочерние селекторы, которые сильно завязаны на конечную структуру HTML.
БЭМ позволяет отвязать CSS от структуры HTML и управлять ими независимо. Это с одной стороны даёт гибкость в поддержке, а с другой стороны усложняет как HTML, так и CSS. За всё надо платить.
Вставили что-то в старый блок. Задеплоили. QA вернул — белый текст на белом фоне! Прописали класс ссылке. Перебивается. Нашли, добавили веса именами родителей. Не хватило. Импортант. Уже вверху есть. Какой дебил… А, это я полгода назад — фичу сдавали. Попробовал убрать этот верхний импортант — ого, он вообще в инлйне. Я что через телефон фиксил, что ли…
Яндекс и его верстальщики работают с горой сервисов, как следствие им требуется безболезненно тягать 100500 блоков из одного проекта в другой с минимальными напрягами (желательно — копипастой).
Copypasters will burn in Hell.
Копипастить код с проекта на проект — обрекать себя на муки обновления кода при изменении HTML. Мы выделяем общие блоки в библиотеку и подключаем её на все проекты.
К примеру, у нас на проекте мы с коллегами отказались от всяческих предлагаемых яндексом префиксов, но добавили свой — префикс «w-», который мы добавляем к элементам-оберткам (так называемые wrappers, отсюда и название префикса).
У нас был префикс h- (holster) ровно для этого, но потом мы от него отказались. Вообще отказались от всех префиксов, кроме b- и i- и то, используем их сейчас из-за большого количества кода с ними. Нельзя просто так взять и отказаться от префиксов :)
Если бы я сейчас проектировал всё с нуля, я бы не использовал префиксы.
но время разработки увеличивается в разы и читабельность html кода падает катастрофически
Можете описать, как у вас организован процесс разработки, что время разработки увеличивается в разы? Может быть смогу что-то подсказать для ускорения работы.
Я ставлю разделитель "__элемент-блока", вложенный в "__другой-элемент-блока", так как в данном случае они неотделимы.
В том-то и дело, что отделимы и в любой момент между ними может встать другой элемент. Лучше делать набор независимых, не цепляющихся друг за друга элементов и делать их них финальный сендвич только в HTML, а не при написании кода.
news — блок, list — элемент блока, а item — элемент блока, вложенный в другой элемент блока.
Да, элементы вкладываются один в другой при использовании, но при описании этих элементов проще использовать плоский список, не вкладывая их в коде и на файловой системе один в другой. Это позволяет не менять код, когда между list и item появится ещё один элемент.
В БЭМ это делается смешиванием нескольких блоков/элементов на одной DOM-ноде. Делаете отдельный блок draggable и примешиваете его к любому другому блоку, который можно таскать.
В этом случае отдельный блок отвечает за определённую функциональность и его можно использовать где угодно. Фактически, то, что вы описываете в статье про контракты, есть в БЭМ в виде миксов.
clubs.ya.ru/bem/replies.xml?item_no=712
clubs.ya.ru/bem/replies.xml?item_no=746
Наглядный пример: 30 тысяч div'ов на странице, селекторы заканчиваются на .text (рефлоу 5 секунд) и на div (рефлоу 37 секунд, осторожно! браузер замерзает, а потом оттаивает).
И там же ссылки на примеры, можете замерить сами в разных браузерах.
Чтобы вызвать перерисовку надо заставить браузер пересчитать размеры, например, вызвав offsetHeight
Отличие класса от inline стиля состоит в том, что ему может соответствовать разный CSS как в пределах разных страниц одного проекта, так и в пределах разных проектов.
Ну и названия without-padding и theme_ffffff хотя и говорящие, но не самые лучшие.
«Программировании есть две проблемы — инвалидация кешей и именование переменных» ©
В статье было неверное утверждение ро невозможность использования каскада в БЭМ, от которого пошло непонимание. Я ответил на это тут: habrahabr.ru/post/151931/#comment_5165248
В Яндексе никто никого не заставляет выступать на конференциях, наоборот сложно оторвать людей от работы и уговорить сделать доклад, вместо того, чтобы код писать.
Но если в любой момент структура блока может измениться (в один блок сложиться другой; добавятся дополнительные обёртки или наоборот уберутся; etc), то вам придётся каждый раз переписывать эти дочерние селекторы, которые сильно завязаны на конечную структуру HTML.
БЭМ позволяет отвязать CSS от структуры HTML и управлять ими независимо. Это с одной стороны даёт гибкость в поддержке, а с другой стороны усложняет как HTML, так и CSS. За всё надо платить.
Хотя соглашусь, что управлять модификаторами из скрипта во многих случаях удобнее, чем полагаться на механизм браузера.
Например, если надо выставить состояние hover не при наведении мышью, а при фокусе с клавиатуры или ещё как.
Копипастить код с проекта на проект — обрекать себя на муки обновления кода при изменении HTML. Мы выделяем общие блоки в библиотеку и подключаем её на все проекты.
Если бы я сейчас проектировал всё с нуля, я бы не использовал префиксы.