Previous Entry Share Next Entry
Независимые блоки (БЭМ) и иже с ними
rawgift

Это был один из последних проектов, выполненных на фрилансе, и первый — на независимых блоках. Раньше я не понимал, что такое «БЭМ» и не хотел отказываться от привычных способов вёрстки, но сейчас дотумкал, что независимые блоки — штука классная. Ещё и проект попался такой, где меня попросили верстать с использованием БЭМ.

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


Сроки

Взявшись за работу, я пообещал уложиться в двухнедельный срок с запасом в 4—5 дней (почти дополнительная рабочая неделя). В итоге вышло, что на работу я потратил чуть меньше 70 часов, т.е. чуть меньше расчётного минимального срока, если работать по 40 часов в неделю. Я столько не работаю, поэтому задержался даже относительно «дедлайна» на несколько дней. Зато пару дополнительных страниц бесплатно сделал :)

В макетах была предусмотрена достаточно универсальная сетка, разработкой которой я занимался почти что 2 недели! Реальные 10 с лишним страниц я сделал за оставшиеся 5 дней. Если бы ковыряться с сеткой не так долго, то вышло бы совсем вовремя. Однако работа была кропотливая, плюс БЭМ, плюс новый для меня Sublime2.

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


Независимые блоки

Итак, независимые блоки. Идея уже несколько лет как не «новаторская», но для множества верстальщиков (для меня в том числе) — новая и немного диковатая. Например, писать селектор .b-link .b-link__underline для ссылки с вложенным спаном внутри кажется сущей глупостью.

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

  1. Несколько месяцев назад мне пришла в голову идея набивать сразу весь HTML-код, а только потом приниматься за стилизацию — прогрессивный джипег для верстальщика. Полноценное изучение макетов часто оказывалось достаточно скучным, и я забивал на него. В таком виде удобней: набивая сразу весь код, проще держать в голове уже существующие элементы.

    «Таблица существующих элементов» как поддерживающая бумажная сущность не прижилась, не удобно. А вот «таблица страниц» — очень даже подходящая штука.

  2. «Инструменты БЭМ» и правда очень важны: поддерживать вручную правильную структуру каталогов и файлов неудобно и сложно. IE действительно не понимает больше 32 @import в одном CSS-файле.

  3. Мы использовали следующий шаблон именования:

    1. b-block__element, к которому дописываются модифкаторы вида m-block__element__modifier. Это неудобно.

    2. Лучше использовать яндексовский (или чей он там) опыт и отделять имя элемента от блока двумя подчёркиваниями, а модификатора от элемента — одним: block__element_modifier. Так визуально понятней.

    3. В названиях стоит использовать венгерскуюНотацию (это не венгерская нотация, а почти CamelCase, только первая буква маленькая), а не подчёркивания или дефисы.

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

  5. Размеры для всех картинок, вставленных элементом IMG, лучше указывать в HTML-коде. Иногда это бывает избыточно, например, для повторяющихся картинок одникового размера в каком-нибудь каталоге, но зато делает код более наглядным.

  6. Использовать множественные бэкграунды в CSS пока что рановато: слишком неудачные результаты получаются в IE. Да и дополнительная разметка даже для 4—5 дополнительных обёрток не настолько «дорога́» с использованием независимых блоков.

  7. БЭМ сам по себе достаточно избыточен: мы часто пишем одни и те же правила для разных элементов и руки чешатся эти правила «вынести за скобки», набивать HTML-код руками тоже излишне и долго. Короче говоря, работу надо автоматизировать по-максимуму — теперь это понятно.

    Надо попробовать использовать LESS или SASS с компиляцией на сервере. Высказывания в духе «БЭМ противоречит принципу Don't Repeat Yourself» — чушь, потому что отсутствие повторения появляется на более высоком уровне.

    Нужно также отказаться от написания HTML вручную и как-то автоматизировать процесс. Как — покажет время, предложения и предположения уже есть.

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

Бизнес-процессы и метрики

По поводу «бизнес-процесса», его шагов и прочих метрик: ДеМарко и Листер в своей книге укзывают на то, что однообразная работа убивает энтузиазм. Что может быть однообразнее работы по расписанному заранее бизнес-процессу?

Но тут есть несколько моментов. Во-первых, изучать свою работу — интересное занятие само по себе. Реально любопытно, и я обязательно придумаю способ легко протоколировать происходящее. Во-вторых, далеко не на каждом проекте нужны крутые верстальщики и далеко не каждый является крутым. Если представить себе студента, который работает на опыт за мизерную зарплату, бизнес-процесс может даже помочь ему. Если, конечно, хватит ума осмыслить набор инструкций.

В-третьих, они действительно правы. Моя вовлечённость, а с ней и эффективность подпрыгнули вверх, как только я попробовал новые методы и инструменты. Верстать независимыми блоками интересно, использовать Sublime удобно. В следующем проекте обязательно попробую использовать какой-нибудь CSS-препроцессор.


P.S. Попробую опубликовать эту заметку по принципу «прогрессивного джипега», сразу. Исправления будут добавляться по ходу дела, если к заметке будет хоть какой-то интерес читателей.


  • 1
Интересно.
Для облегчения верстки по БЭМу я советую попробовать шаблонизатор JADE и миксин bemto для него.
БЭМ это полностью Яндекс.

Спасибо.
Пока я не понимаю, что такое «шаблонизатор JADE», но обязательно копну в эту сторону, как только займусь следующим проектом.

JADE - это шаблонизатор такой, мы в одном проекта на nodeJs юзаем, очень удобная штука.

Мы использовали следующий шаблон именования:
b-block__element, к которому дописываются модифкаторы вида m-block__element__modifier. Это неудобно.
Лучше использовать яндексовский (или чей он там) опыт и писать: block__element_modifier, так визуально понятней.
В названиях стоит использовать венгерскуюНотацию, а не подчёркивания или дефисы.


Не совсем понял к чему тут выделение жирным и курсивом.

Про первый способ добавления модификаторов, с префиксом m-, не слышал ни разу. Вопросы нотации в названиях — в определенной степени вкусовщина, можно как угодно разделять блоки, модификаторы et c., главное — чтобы структурно код делился на блоки и их элементы. Префиксы блоков, например, мне, как обычному версталю использующему bem vulgaris, не нужны. С модификаторами я позволяю себе вольность и использую не яндексовский _modifier_value, а просто _modifier, например, в случаях с active, diisabled и тому подобных.

Сделай что-нибудь со шрифтом, читать невозможно!

Edited at 2012-07-15 10:32 am (UTC)

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

Кажется, я понял, зачем нужен префикс b-: он используется внутри XML для именования узлов, транслируемых в «блоки» в терминологии БЭМ, чтобы отличить их от элементов. Это уже потом, в HTML, получаются классы b-block__element, а в XML не так.

Примеры есть тут: http://kovchiy.livejournal.com/70902.html

Плюс ещё одно важное умозаключение: независимые блоки, набиваемые руками — это очень долго и дорого. Если раньше мы точно так же набивали код для браузера, то могли хотя бы «сжульничать» и упростить себе жизнь, используя каскад. С независимыми блоками получается безумие: для упрощения жизни просто _необходимо_ использовать CSS-препроцессоры и сборку HTML из XML автоматизированными штуками.

Edited at 2012-07-16 07:20 am (UTC)

Отличная заметка :)

Я по-прежнему считаю, что префикс "m" очень полезен. Во-первых, для удобства чтения кода, а во-вторых, для того, чтобы не перепутать модификатор блока с элементом блока.

Пример:


Здесь icon__mail -- это модификатор или элемент? Если в ХТМЛ-коде мы это еще как-то можем понять, то в цсс будет совсем не понятно:

.icon__mail {}
.icon__inner {}


По поводу избыточности: в данном случае избыточность добавляет больше понятности коду (по аналогии с тем, как пишут код, где у каждой переменной свое грамотное имя, по которому легко ориентироваться даже без комментариев) и огромную гибкость, когда с помощью модификатора можно легко переделать отображение блока.

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

Edited at 2012-07-22 11:59 pm (UTC)

Re: Отличная заметка :)

Вадим, если модификатор отбивать от имени элемента/блока одним подчёркиванием, то всё понятно:

.icon — блок
.icon__inner — элемент
.icon_big и icon__inner_shift — модификаторы.

По поводу избыточности: я и не против :) Кстати, попробовал использовать LESS на новом проекте, чепуха. Почти ничего не даёт. Напишу об этом позже.

  • 1
?

Log in

No account? Create an account